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 17:16:47 -0700
One other thing that Bill just mentioned to me is that if you want to
use the client IO buffer size as part of the calculation for your
device's safety offset (aka sample offset in the family API), you
have to be darn careful that you don't change the safety offset while
there are clients currently registered. The reason why is that if you
increase the safety offset after a client already is playing, you
will cause that client to glitch when the HAL starts using the new
safety offset. Given that a new client can start playing at any time
with any buffer size, it makes such an optimization a little less
attractive.
Note that you can put a limit on the upper bound of the buffer size
the HAL will allow with the size of the device's ring buffer. The HAL
will only allow clients to use a maximum buffer size of 3/8 the size
of the ring buffer. This can at least allow you to plan for the worst
case scenario and prevent glitching when new clients start.
Finally, changing the safety offset currently requires a major engine
change to be sent before the HAL will notice the new value. This
necessarily makes changing the safety offset a fairly disruptive
procedure that should be avoided except in the course of doing other
configuration changes if possible.
On Oct 19, 2005, at 4:50 PM, Jeff Moore wrote:
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
--
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