Re: buffer size magical reduction
Re: buffer size magical reduction
- Subject: Re: buffer size magical reduction
- From: Paul Davis <email@hidden>
- Date: Sun, 28 Nov 2010 15:43:10 -0500
On Sun, Nov 28, 2010 at 3:27 PM, David Plans <email@hidden> wrote:
> Hello
>
> I have the following code that asks Puredata (puredata.info) for its blocksize, which is alway 64, and then creates an AudioSession. I establish bufferSize by multiplying by number of ticks (set by app delegate, in this case 64 again), then bufferDuration by dividing by sampleRate (44100) to get buffer duration in seconds (which is then 64*64/44100 = 0.092879818594104)
>
> Problem is, setting that with kAudioSessionProperty_PreferredHardwareIOBufferDuration works fine, but when I try to get kAudioSessionProperty_CurrentHardwareIOBufferDuration, it invariably comes back as half of what I asked for, i.e. 0.046...
>
> I see in the docs that:
>
> "The actual I/O buffer duration may be different from the value that you request, and can be obtained from thekAudioSessionProperty_CurrentHardwareIOBufferDuration property."
>
> But if we don’t ‘necessarily get what we ask for’, what do we get?
you get something supported by the h/w and other layers of the
CoreAudio API; you can find out its value as described by the quoted
sentence you mentioned.
btw, PureData doesn't "have" a blocksize per-se that matters in this
sense.. Its quite happy to adapt to the blocksize imposed by outside
factors, like the audio h/w, OS audio API etc. etc.
_______________________________________________
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