Re: kAudioDevicePropertyBufferSize reported to IOAudioEngine?
Re: kAudioDevicePropertyBufferSize reported to IOAudioEngine?
- Subject: Re: kAudioDevicePropertyBufferSize reported to IOAudioEngine?
- From: Jeff Moore <email@hidden>
- Date: Wed, 19 Oct 2005 16:50:03 -0700
What Bill said is true and important. Drivers are the rendezvous
point for mixing audio for all the processes in the system. As such,
each process is allowed (encouraged even) to use the buffer size that
best works for the application. So you can see many processes using
several different buffer sizes.
That said, you can find out what buffer sizes are used for each user
client object via the client buffer sets. You can override the
IOAudioStream methods, addClient() and removeClient(), to observe the
buffers as they get registered/unregistered for usage with each
stream. You can infer the number of frames in the IO cycle for each
client based on the buffer sizes.
On Oct 18, 2005, at 12:36 PM, William Stewart wrote:
On 18/10/2005, at 11:35 AM, Daniel Mack wrote:
Hi list,
My today's question is about the interaction between the coreaudio
code in userspace
and kernelspace.
In my IOAudioEngine implementation, I act on some asumptions
regarding the system
speed the driver is running on. The closer I get to a minimum in
the queuing
logic, the higher is the chance that the output starts crackling
on higher system
loads (or with slower machines, of course).
In userspace, it is possible to set an audio device's property by
calling
AudioDeviceSetProperty(..., kAudioDevicePropertyBufferSize,
size, ...);
The information about the amount of data beeing written 'in a row'
could also
be very useful to my kernel extension to take into account whether
lowest audio
latency or lowest system performance usage is more important.
So, long story short, my question is - is there any way to catch
the change
of the buffer size from within a kernel driver?
No - in fact you can have two or more clients simultaneously that
are running at different I/O sizes - for eg, one client is doing 64
sample I/Os, the other 512. This is why it isn't propagated to the
driver.
Bill
I neigther got any hint by grep'ing through the IOAudioEngine,
IOAudioDevice
and IOAudioStream class headers nor by having a look to Apple's
own audio
driver implementations.
--
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