| Summary: | Got AudioQueueObject Error with SDL 2.05 but not with SDL 2.04 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Soberka <richard> |
| Component: | audio | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | blocker | ||
| Priority: | P2 | ||
| Version: | 2.0.5 | ||
| Hardware: | x86 | ||
| OS: | Mac OS X 10.6 | ||
|
Description
Soberka
2017-01-11 13:52:35 UTC
> the only cure is to go back to SDL 2.04 instead SL 2.05
Is there a build of the game you can send me that reproduces this problem?
--ryan.
Hello, I've find an empirical way to solve the problem !!! ...I've reduced the Chunk Size ! When initializing the Mixer, under SDL 2.04, or 2.03 , I've always setting the chunks Size to 1024, like that : Mix_OpenAudio(44100, MIX_DEFAULT_FORMAT, MIX_DEFAULT_CHANNELS, 1024) I still, can't figure why with SDl 2.05, when quitting, I am gettingthe following message : "AudioQueueObject::FreeBuffer: AQBuffer * 0x10150b270 has enqueue count of 1" But, i've just discovered that, if i reduce chunk size to 512 , like : Mix_OpenAudio(44100, MIX_DEFAULT_FORMAT, MIX_DEFAULT_CHANNELS, 512) ...No more error with SDL 2.05 when quitting ! ? Crazy , isn't it ? (maybe due to some shorter OSX internal delay when AudioQueueFreeBuffer is called ?) If you have an better idea to avoid the error message , with larger buffer, I'm still interested ;-) Best reagards Richard We wait for the CoreAudio-specific audio thread to shut down, but we don't actually have an SDL_Delay() to wait until playback is definitely complete before freeing the buffers, like we do for the standard SDL audio thread. I bet that's the problem. --ryan. (In reply to Ryan C. Gordon from comment #3) > We wait for the CoreAudio-specific audio thread to shut down, but we don't > actually have an SDL_Delay() to wait until playback is definitely complete > before freeing the buffers, like we do for the standard SDL audio thread. I > bet that's the problem. Actually, we _do_ try to delay before the thread ends, and we wait on that thread, but I wonder if we should forcibly dequeue any buffers right before freeing, since our callback re-adds them, and and we use the runloop to wait which might call our callback, and maybe that causes a race...? --ryan. This should be fixed in https://hg.libsdl.org/SDL/rev/24b2d63e8310 along with a few other corner cases...the CoreAudio manual says we shouldn't free the buffers ourselves, but let AudioQueueDispose() deal with it, so we do that now; I assume this will stop the warning message. --ryan. |