Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
- Subject: Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
- From: Dale Curtis via Coreaudio-api <email@hidden>
- Date: Fri, 15 May 2020 12:00:52 -0700
On Fri, May 15, 2020 at 11:47 AM Ed Wynne <email@hidden> wrote:
> 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> wrote:
>
>> On May 14, 2020, at 3:21 PM, Dale Curtis via Coreaudio-api <
>> 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.
>
Our callbacks already handle changes in the buffer size properly. The issue
is instead that CoreAudio itself is crashing unfortunately.
- dale
_______________________________________________
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