Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
- Subject: Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
- From: Ed Wynne via Coreaudio-api <email@hidden>
- Date: Fri, 15 May 2020 14:46:49 -0400
> On May 15, 2020, at 2:26 PM, Dale Curtis <email@hidden> wrote:
> On Thu, May 14, 2020 at 1:31 PM Ed Wynne <email@hidden
> <mailto:email@hidden>> wrote:
>> On May 14, 2020, at 3:21 PM, Dale Curtis via Coreaudio-api
>> <email@hidden <mailto:email@hidden>> wrote:
>> Can someone from the CoreAudio team clarify when it's safe to call
>> AudioUnitSetProperty() on kAudioDevicePropertyBufferFrameSize? Specifically
>> we have these questions:
>> - Is this just an unexpected bug and this should be safe to call at any time?
>> - Should we first call AudioOutputUnitStop() on all units for the target
>> device that have kAudioOutputUnitProperty_IsRunning == true?
>> - Should we instead call
>> AudioUnitUninitialize()+AudioComponentInstanceDispose() to destroy the units
>> before changing buffer sizes?
>
> TL;DR; It is almost never safe to change the IO context properties whenever
> any IO context is running.
>
> Thanks for the detailed reply Ed. You seem to be advocating for the second
> bullet point then. I.e., that we stop all running units before making any
> buffer size change. This is about what I was expecting, but wanted to make
> sure we didn't need to do something more drastic like destroy the units
> before changing sizes (bullet three).
2 is definitely the easiest way to be safe.
Another alternative is to insert a layer between the IOProc callback and your
audio processing graph. You can run your graph at some low multiple, like 128
frames, and make multiple calls as necessary per CoreAudio buffer. Then you can
adjust the device buffer size up and down, so long as it’s always evenly
divisible by the graph processing size. Depending on your architecture that
might not be easy to pull off though. It also reduces efficiency a little.
-Ed
_______________________________________________
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