What thread do these requests come in on?
The callbacks are on a thread implicitly created by the OS.
Does OS X mandate how long you have to honor the request for
more data before it might underflow?
The callback informs me of the current audio device time and the time of
the output that I'm currently supplying. So I can figure this stuff out if
necessary. Also there are notifications for underflowing audio.
But the documentation for CoreAudio is ... suboptimal. Churning through a
few tests, it seems that the callbacks happen 11 or 12 milliseconds before
the output time of the data. That's cutting it pretty fine. (The delay
differs when I use different audio output devices too. Sweet eh?)
Is it a synchronous request
for data or asynchronous?
Asynchronous.
Do we have a minimum or maximum amount of data we can send
it?
Yeah, the callback supplies a buffer and tells us how big it is. Then we
have to fill up that buffer. So we are pretty much blocked from pushing
extra data to CoreAudio.
At 11:19 AM 7/25/2006, Greg Wright wrote:
Bob Clark wrote:
Is there an official place to put audio device sods? Unless there's a more
appropriate place, I will link to the list archive of this message when I
need
to refer to it.
we sometimes put them into the www directory under devdocs.
helix-client/www/2006/devdocs
for example. For something like this, I think the list archive
is OK.
more below....
Information
* SOD: CoreAudio -- modern sound API for OS X
* author: [EMAIL PROTECTED]
Problem Statement
The current audio device implementation for OS X uses the
deprecated Sound Manager APIs. Among other drawbacks, the
Sound Manager only allows two channels, so multichannel
audio is not possible. Furthermore, although one can rarely
tell what Apple will do, it's dangerous to be relying solely
on a deprecated set of APIs.
Solution Overview
The CoreAudio APIs are the approved OS X sound APIs. These
are supported and approved by Apple. Among the strengths of
CoreAudio: it supplies APIs to detect when a multichannel
(e.g. Dolby 5.1) output device is connected and adds the
ability to play multichannel audio.
Solution Details
* Rely on the system's current default output audio device.
(Instead of adding internal preferences.) This is
standard Mac practice, but one could concoct scenarios
where it would be convenient to specify an audio output
device that's not the default output audio device.
* The CoreAudio APIs differ from other audio device APIs.
With other audio device APIs, we can just push audio data
at the device and it will then play it. CoreAudio instead
polls via a callback function, asking for more audio data.
Helix DNA expects to treat the audio device as something
to push data at, so to accommodate Helix's "expectation" I
need to set up a ring buffer so Helix has something to
push data at... then when CoreAudio wants to suck data I
have it there to supply to the OS.
What thread do these requests come in on?
Does OS X mandate how long you have to honor the request for
more data before it might underflow? Is it a synchronous request
for data or asynchronous?
Do we have a minimum or maximum amount of data we can send
it?
--greg.
* Add code to dynamically check the default audio output
device's characteristics (number of channels, etc.)
instead of just assuming (like the Sound Manager
implementation) that I can shove two-channel data at it.
* Helix pushes data in UINT16 (two-byte integer) format,
while CoreAudio expects data in double (four-byte float)
format. This conversion is not noticeably CPU intensive,
but it will be worth watching for performance problems.
* Of note: the audio device implementation seems to require
that the implementation's Resume() function calls
OnTimeSync().
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
