In my application there is need to play multiple wav files sequentially. The sequence can not be predicted and depends on the input from external sources during runtime.
The question I have is:
Should audio device be opened and closed for each wav file that application plays? Or can it be opened just once at the start and be used to play all wav files?
My current understanding is that if all wav files have identical SDL_AudioSpec data then they can be played sequentially without calling SDL_CloseAudioDevice / SDL_OpenAudioDevice for each new file.
And if SDL_AudioSpec differ - the audio device should be closed and reopened with the new SDL_AudioSpec data.
It would be very inefficient to open and close a device for every file you want to play, just leave it open. You can use SDL_PauseAudioDevice if you have nothing to play and want to save some resources.
Note that opening a device may take quite a few milliseconds (to seconds even) depending on the system and driver. The audio device can also choose to not support the SDL_AudioSpec you are giving to it. If the time between the input signal and the first vibration of the speaker has to be as small as possible, you would always keep it open and do the resampling yourself.
My experience is the same as the OP’s: if the files do not share the same AudioSpec, leaving it open simply does not work. To play multiple files sequentially, if they have different sampling formats, it appears to be necessary to close and re-open the device for each file (or to re-sample them oneself so they all have the same format, which is hard).
Is that not how it is intended to work? Is there some other way, that I have not discovered, of playing multiple files with different formats that allows the audio device to be kept open?
The SDL audio API sits relatively close to the backend and just tries to pump data into the driver. All work before that (mixing, type conversion, up- and downsampling) has to be done by some other code. Although that has changed with the recent versions (we got automatic resampling and a resampling API*), the question was asked about 2.0.5. To my knowledge, 2.0.5 didn’t have that.
With libraries like libsamplerate being available, it’s really not fair to call this task hard. Annoying yes, but not hard.
* There were some quality issues with the resampler. I don’t know if those have been resolved.
I have considerable experience of sample-rate-changing (it was a subject in which I specialised during my career with BBC R&D) so I feel qualified in saying it is ‘hard’ - to do it well anyway! If closing-and-reopening the audio device for each file allows you to configure it to different formats - thus offloading the issue to the OS or the hardware - that might well be preferable to sample-rate-changing in my app (whether using a library or an SDL API).
Should anybody be interested, I developed my own tool for synthesising sample-rate-changing filters because I was dissatisfied with the performance of others I could find. It’s at sourceforge.
Well, yeah. The whole theory behind it is something else. I was talking about getting the job done that is good enough for some people. If it’s not important that tearing down the device and setting it up again takes some time, sure, go ahead.