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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
