• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: 64bit processing possible?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64bit processing possible?


  • Subject: Re: 64bit processing possible?
  • From: Jeff Moore <email@hidden>
  • Date: Thu, 30 Jul 2009 15:08:19 -0700

FWIW, the HAL and the driver model are the source of the usage of 32 bit floats as the canonical sample format, not AUHAL. So, dropping down to the HAL doesn't really help you any. You will still be using 32 bit floats to hold the data.

On Jul 30, 2009, at 2:56 PM, Brian Willoughby wrote:

There is an inevitable tradeoff between convenient, wide-based compatibility versus optimization for a particular interface. If AUHAL is seen as a roadblock for double precision, then there is always the option of skipping past the AUHAL layer to directly access the HAL. This does put extra responsibility on the host developer. As Ross pointed out: anyone interested in high-quality output should probably be handling the conversion [to HAL format] in their own code, rather than expecting the system to use any particular algorithm.

AUHAL is certainly very convenient to use, and it allows host developers to support all audio hardware variations with minimal effort. The HAL, though, should allow access to any feature that a given piece of audio hardware supports. Thus, nothing seems missing from CoreAudio. In fact, again echoing Ross, there must always be a data format conversion at some point before the final digital to analog, so there will be room for host applications which micromanage this step. That said, it seems doubtful that there will ever be any advantage to passing doubles to the driver instead of single-precision, unless hardware developers decide to focus on dithering or other aspects which would require a custom driver.

To pick a nit, though, there are plenty of audio hardware devices which can use all 24 bits of precision. 32-bit float actually has 25 bits of precision when you include the implied "1" bit in the mantissa, and thus it's true to say that no audio hardware can make use of all 25 bits of available precision. I'll assume this was just a typo below.


On Jul 30, 2009, at 12:49, William Stewart wrote:
ok - but I don't see why this is such an issue.

AUHAL is interfacing through the HAL to the audio driver. No audio hardware that I know of can even use all of the 24bits of resolution that can be represented in a 32bit float.

If you keep your whole signal processing chain as doubles (which you can easily do with audio units if you build your own) - and I am sure that there would be some 3rd party interest to add to this - you have at some point to go down to 24bit output (or come from 24 bit input).

So, exactly why is AUHAL a problem (or even a roadblock) here?

On Jul 29, 2009, at 12:27 PM, Evan Olcott wrote:
On Jul 29, 2009, at 2:04 PM, email@hidden wrote:
The best next step here is for some industrious developer to create a
double-precision AU host and go from there. It's a bit of a chicken-
and-egg situation, but it would seem to start the ball rolling.

Coming from the host-development side (which we do with a small handful of our products, Rax in particular), I can tell you that we HAVE tried this and researched it, and our roadblock in the end is the AUHAL drivers. Even if we WERE able to make the entirety of the stream double precision, not only would we lose access to almost every commercial AU, it seems to be brought down to (at least) single-precision internally the AUHAL. We have yet to come across an AUHAL driver that supports a 64-bit AudioBasicStreamDescription as the input format. The drivers we've analyzed seem to convert their data streams to 24-bit integer on the outgoing side, so they take the single precision and convert that to a more efficient data stream. 64-bits with multiple channels is a pretty hot data stream - takes a wide pipe to push that all through.


That said, it's not like we've seen every driver out there. If there IS a double-precision clean AUHAL driver out there (that can be used by third-party developers like us), please let us know - we'd look forward to working with it. We'll be the guinea pig if it gets double-precision AUs written.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


--

Jeff Moore
Core Audio
Apple



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: 64bit processing possible?
      • From: Brian Willoughby <email@hidden>
References: 
 >Re: 64bit processing possible? (From: Evan Olcott <email@hidden>)
 >Re: 64bit processing possible? (From: William Stewart <email@hidden>)
 >Re: 64bit processing possible? (From: Brian Willoughby <email@hidden>)

  • Prev by Date: Re: 64bit processing possible?
  • Next by Date: Re: 64bit processing possible?
  • Previous by thread: Re: 64bit processing - Why?
  • Next by thread: Re: 64bit processing possible?
  • Index(es):
    • Date
    • Thread