# Must audio device be opened/closed for each new wav file?

**URL:** <https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007>\
**Category:** SDL Development\
**Created:** [March 8, 2018, 2:47pm UTC](https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007 "2018-03-08T14:47:58Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![nc-pv](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/n/47e85d/32.png) [@nc-pv](https://discourse.libsdl.org/u/nc-pv)\
**Post date:** [March 8, 2018, 2:47pm UTC](https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007/1 "2018-03-08T14:47:58Z")

</div>

I am using SDL 2.0.5 on Linux.

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.

Is this correct?

---

<div class="post-metadata">

**Author:** ![ChliHug](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/chlihug/32/2863_2.png) [@ChliHug](https://discourse.libsdl.org/u/ChliHug)\
**Post date:** [March 10, 2018, 8:35pm UTC](https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007/2 "2018-03-10T20:35:39Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rtrussell](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/rtrussell/32/4768_2.png) [@rtrussell](https://discourse.libsdl.org/u/rtrussell)\
**Post date:** [March 11, 2018, 11:13am UTC](https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007/3 "2018-03-11T11:13:48Z")

</div>

> [@ChliHug](#):
>
> It would be very inefficient to open and close a device for every file you want to play, just leave it open.

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?

---

<div class="post-metadata">

**Author:** ![ChliHug](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/chlihug/32/2863_2.png) [@ChliHug](https://discourse.libsdl.org/u/ChliHug)\
**Post date:** [March 11, 2018, 1:07pm UTC](https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007/4 "2018-03-11T13:07:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rtrussell](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/rtrussell/32/4768_2.png) [@rtrussell](https://discourse.libsdl.org/u/rtrussell)\
**Post date:** [March 11, 2018, 1:57pm UTC](https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007/5 "2018-03-11T13:57:05Z")

</div>

> [@ChliHug](#):
>
> With libraries like libsamplerate being available, it’s really not fair to call this task hard.

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](https://sourceforge.net/projects/firbbc/).

---

<div class="post-metadata">

**Author:** ![ChliHug](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/chlihug/32/2863_2.png) [@ChliHug](https://discourse.libsdl.org/u/ChliHug)\
**Post date:** [March 11, 2018, 2:44pm UTC](https://discourse.libsdl.org/t/must-audio-device-be-opened-closed-for-each-new-wav-file/24007/6 "2018-03-11T14:44:16Z")

</div>

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.