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:31:00 -0700
On Fri, May 15, 2020 at 12:15 PM Ed Wynne <email@hidden> wrote:
>
> On May 15, 2020, at 3:00 PM, Dale Curtis <email@hidden> wrote:
> Our callbacks already handle changes in the buffer size properly. The
> issue is instead that CoreAudio itself is crashing unfortunately.
>
>
> Right, I was talking about this:
>
> Thread 12 (id: 0x002ce095) CRASHED [EXC_BAD_ACCESS /
> KERN_PROTECTION_FAILURE @ 0x00001a0fadf3c000 ]
> 0x00007fff6bea41d0 (libAudioToolboxUtility.dylib + 0x0002c1d0 )
> CrashIfClientProvidedBogusAudioBufferList
> 0x00007fff4c59298e (AudioToolboxCore + 0x000d198e )
> AudioConverterFillComplexBuffer
> 0x000000010d5a89a6 (CoreAudio + 0x000099a6 ) DefaultOutputAUFactory
> 0x000000010d5caa12 (CoreAudio + 0x0002ba12 ) AUPeakLimiterFactory
> 0x000000010d5aba9d (CoreAudio + 0x0000ca9d ) AUGenericOutputFactory
>
>
> This is an instance similar to my Example B. The code below here is using
> one set of IO context settings, whereas the code above here is using
> different IO context settings. That’s why it implodes with
> CrashIfClientProvidedBogusAudioBufferList. My alternative suggestion was
> to insert your own mapping layer here so that the buffers from below always
> get mapped into the buffers from above, without the buffers from above ever
> needing to change.
>
> 0x00007fff3771c00e (CoreAudio + 0x0011800e )
> ___ZN19HALC_ProxyIOContextC2Ejj_block_invoke
> 0x00007fff3785161b (CoreAudio + 0x0024d61b ) HALB_IOThread::Entry(void*)
> 0x00007fff6f825e64 (libsystem_pthread.dylib + 0x00005e64 ) _pthread_start
> 0x00007fff6f82183a (libsystem_pthread.dylib + 0x0000183a ) thread_start
> 0x00007fff378515d3 (CoreAudio + 0x0024d5d3 )
> HALB_IOThread::StartAndWaitForState(unsigned int)
>
>
> This can be difficult to retrofit though, as it requires managing your own
> audio graph. You can't just let the standard CoreAudio output unit do it’s
> thing for you.
>
I see. Yes, hopefully just stopping the units between size changes is
sufficient.
- 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