Re: getting 'kAudioDevicePropertyBufferFrameSize' may reflect invalid values
Re: getting 'kAudioDevicePropertyBufferFrameSize' may reflect invalid values
- Subject: Re: getting 'kAudioDevicePropertyBufferFrameSize' may reflect invalid values
- From: Jeff Moore <email@hidden>
- Date: Wed, 12 Mar 2008 11:45:42 -0700
After I sent off my reply, it occurred to me that even though your
ring buffer size is really small, the HAL should still be doing the
right thing with the default buffer size. I'd appreciate it if you
could file a bug about your initial findings.
More stuff inline below.
On Mar 12, 2008, at 4:02 AM, David Zimmermann wrote:
thanks for your reply.
That's way too small. The HAL determines the upper bound of the ring
buffer size as 3/8ths the size of your ring buffer. So, you have to
have a ring buffer that is at least 1365 to support the base line 512
sample frame IO buffer size.
Good to know. Is that spec published anywhere and I just missed it ?
It's not really published anywhere, so you didn't miss it.
It would be nice to get a state code in return to
setNumSampleFramesPerBuffer that indicated invalid DMA ring buffer
sizes ?!
I wonder why HAL publishes a buffer range limeted to
the 3/8ths spec and the drivers ring buffer size (max 60 frames @
160 frames DMA buffersize)
- but the default buffer size does not meet that spec (512 frames
vs. 160 frames DMA buffersize)
The reason for the limitation has to do with having enough elbow room
so that the buffering doesn't trip on itself through the caches and
what not.
In other words:
This is how I understand it: HAL publishes two properties to the
user mode applications. One of them being
'kAudioDevicePropertyBufferFrameSize' the other being
'kAudioDevicePropertyBufferFrameSizeRange'. The first returns
currently used buffer size. The second one returns the range of
possible buffer sizes.
This is what happens: If, like in my case, the driver uses a buffer
that is too small, the range that the HAL provides goes according to
size of the published value of the driver (logically like the 3/8th
convention) BUT the 'kAudioDevicePropertyBufferFrameSize' function
is NOT being updated thus completely invalid.
So again, I wonder why is that, or rather: what do I need to do to
get 'kAudioDevicePropertyBufferFrameSize' carrying the correct
buffer size value?
The behavior you witnessed before is a bug in the HAL for not ranging
the default buffer size against the ring buffer size appropriately.
Lots of apps are going to just fail
outright because of this. If your device supports rates higher rates,
you'll want to have a bigger ring buffer as the default buffer size
for devices with sample rates above 64K is 1024.
The hardware is designed to support rates up to 192k (plus pitch).
Which maximal default buffer size
has to be assumed ?
You probably don't want to have to re-allocate the ring buffer on the
fly, so you should go with the largest size you are going to need.
--
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