• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 15:14:10 -0400

> 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.

In an ideal world, this would all just work correctly.

-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

  • Follow-Ups:
    • Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
      • From: Dale Curtis via Coreaudio-api <email@hidden>
References: 
 >Thread safety around setting kAudioDevicePropertyBufferFrameSize? (From: Dale Curtis via Coreaudio-api <email@hidden>)
 >Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize? (From: Ed Wynne via Coreaudio-api <email@hidden>)
 >Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize? (From: Dale Curtis via Coreaudio-api <email@hidden>)
 >Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize? (From: Ed Wynne via Coreaudio-api <email@hidden>)
 >Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize? (From: Dale Curtis via Coreaudio-api <email@hidden>)

  • Prev by Date: Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
  • Next by Date: Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
  • Previous by thread: Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
  • Next by thread: Re: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
  • Index(es):
    • Date
    • Thread