On Fri, May 15, 2020 at 11:47 AM Ed Wynne <ar...@phasic.com> wrote: > On May 15, 2020, at 2:26 PM, Dale Curtis <dalecur...@chromium.org> wrote: > On Thu, May 14, 2020 at 1:31 PM Ed Wynne <ar...@phasic.com> wrote: > >> On May 14, 2020, at 3:21 PM, Dale Curtis via Coreaudio-api < >> coreaudio-api@lists.apple.com> 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 (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
