Thread safety around setting kAudioDevicePropertyBufferFrameSize?
Thread safety around setting kAudioDevicePropertyBufferFrameSize?
- Subject: Thread safety around setting kAudioDevicePropertyBufferFrameSize?
- From: Dale Curtis via Coreaudio-api <email@hidden>
- Date: Thu, 14 May 2020 12:21:50 -0700
In Chromium, we may have a variety of audio streams running with different
buffering size needs (e.g., normal audio playback vs WebRTC vs WebAudio).
Since buffer sizes are shared among all active audio units for the same
device, we try to ensure we lower and raise as needed to save as much power
as possible.
We're running into some in-the-field crashes in CoreAudio during this
process:
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
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)
GWP-ASan Free Stack Trace (id: 0x00179f00)
0x0000000114b1f1c9 (Google Chrome Framework -safe_conversions.h )
base::debug::CollectStackTrace(void**, unsigned long)
0x00000001165e0200 (Google Chrome Framework -guarded_page_allocator.cc:398
) gwp_asan::internal::GuardedPageAllocator::Deallocate(void*)
0x00000001165e13cd (Google Chrome Framework -sampling_malloc_shims.cc:111 )
gwp_asan::internal::(anonymous
namespace)::ReallocFn(base::allocator::AllocatorDispatch const*, void*,
unsigned long, void*)
0x0000000114b38993 (Google Chrome Framework -allocator_shim.cc:216 )
base::allocator::MallocZoneFunctionsToReplaceDefault()::$_6::__invoke(_malloc_zone_t*,
void*, unsigned long)
0x00007fff6f7da481 (libsystem_malloc.dylib + 0x00004481 )
malloc_zone_realloc
0x00007fff6f7d9239 (libsystem_malloc.dylib + 0x00003239 ) realloc
0x00007fff6f6cea16 (libsystem_c.dylib + 0x0005ea16 ) reallocf
0x000000010d5a76d9 (CoreAudio + 0x000086d9 ) DefaultOutputAUFactory
0x000000010d5a75aa (CoreAudio + 0x000085aa ) DefaultOutputAUFactory
0x000000010d5a0396 (CoreAudio + 0x00001396 ) DefaultOutputAUFactory
0x000000010d5a3241 (CoreAudio + 0x00004241 ) DefaultOutputAUFactory
0x000000010d5aa0de (CoreAudio + 0x0000b0de ) AUGenericOutputFactory
0x000000010d5a535b (CoreAudio + 0x0000635b ) DefaultOutputAUFactory
0x000000010d5a4af6 (CoreAudio + 0x00005af6 ) DefaultOutputAUFactory
0x00000001125615a0 (Google Chrome Framework -audio_manager_mac.cc:1047 )
media::AudioManagerMac::MaybeChangeBufferSize(unsigned int,
ComponentInstanceRecord*, unsigned int, unsigned long, bool*, unsigned
long*)
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?
Thanks in advance!
- 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