The SDL3 Audio Subsystem!
Вставка
- Опубліковано 11 жов 2024
- Here's a quick rundown of the new SDL3 Audio Subsystem!
Want you name in lights? Or at least in my UA-cam videos?
/ icculus or github.com/spo...
Icons created by AlexAngry: linktr.ee/Alex...
Sounds in this video:
splash.wav:
SPLASH.wav by petenice
Original: freesound.org/...
License: creativecommon...
spring.wav:
Game Over Arcade.wav by myfox14
(We converted this to mono output.)
Original: freesound.org/...
License: creativecommon...
Music in today's video is from Kevin Hartnell, of Overlook Hotel Records, under a CC BY-SA 4.0 license. I got it from Bandcamp, but his main website with all the links is www.kevinhartn...
Creative Commons is a force for good and lets this music show up in this video, but you should still throw a few bucks at Kevin, because publishing under the CC should be rewarded.
Kevin Hartnell - "CC BY-SA 4.0"
Overlook Hotel Records R237-0CC
That's amazing! It would be very interesting to see how you built this demo app too, I'm so curious about it
This is testaudio.c, which I wrote as a test app for the new subsystem!
Current code:
github.com/libsdl-org/SDL/blob/2de9253b6c1e67281c4c4ef2a5e89d54a61d8e34/test/testaudio.c
It'll just be in the "test" directory once we merge the new audio subsystem, shortly.
@@RyanGordon Nice!!! thanks a lot
Great stuff! Can't wait for the release. :)
I cannot express how much I love this. This is awesome!!!
SDL3, huh? I've been living under a rock.
It's still work in progress, but we've been building it for all of 2023 so far. :)
This is SO MUCH BETTER! Very excited for SDL3!
This is amazing!
I have a small WIP engine being made currently with SDL2 and had an issue when trying it with a GhostBSD laptop where, regardless of system setting, the audio always ended up being played on the speakers. It's good that I won't need to put audio settings in a .conf file anymore lol
Nice work, man!
Please feel free to roll into our bug tracker, in case that's something we can fix in SDL2, too!
Thinking out loud.
Hi Gordon, a separate callback for each source is great, but you need another common callback after SDL3 does the mixing, for example, if you need to add one common effect (for example, an echo for the entire sound from all the sounds already mixed at once) if you do an echo for each individual sound source through a callback, then it will be expensive.
In any case, everything looks great, we just bind the source to the playback and that's it! I don’t know if it’s worth it to do it out of the box, but there are still queues when we set a sequence of sources that play one after another, this is necessary, for example, to receive buffered audio over the network and queue samples for playback. Although perhaps this is already redundant, but if this is really superfluous, you need to somehow know that the playback of a particular source has been completed in order to make the playback queues on your own.
Thank you ::)
P.S. I have bad English sorry (I use a translator)
We're discussing adding a postmix callback, since global effects, visualization tools (and the SDL_mixer library!) will want these things.
As a followup, this landed in SDL3 awhile ago: wiki.libsdl.org/SDL3/SDL_SetAudioPostmixCallback
@@RyanGordon Great, thank you very much for this work.
This will allow you to manipulate sound very flexibly, for example, we can have an application for adjusting the sound of a game in the form of an effects mixer, two panels, one on the left, the other on the other, they contain the same effects, but on one we adjust them for each sound separately, and on another for everyone once. This is a very, very flexible approach and, due to the fact that the general pass is based on one final data, it is also fast and simplifies the logic, if we wanted to do the same thing, but always with each byte stream separately, we would have to make additional states when mixing effects on each of them, but like this, with the final post-processing we can do it quickly, it’s easier to organize the code and ask for its logic. Thank you very much, I guarantee this post-processing challenge will be the most popular.
I use a translator; if anything in the text seems strange, don’t pay attention. Thanks again for your work.
Awesome man, love it.
I've sorta lazily leaned on the callback informing me that it wants more audio data. What's a good strategy for filling an audio stream on my own terms? On each frame, insert 1/60 of a second worth of audio? How do game engines typically tackle this?
That is one option; see it's been X milliseconds since you last provided audio, so fill in a few milliseconds more, etc. Another is to just have a single audio stream and use its callback as you go along, like you already do in SDL2, which make changes to existing code extremely minimal.
@@RyanGordon I've experimented in the past with doing push-based sample generation for game audio but the latency vs reliability trade-off (in terms of avoiding audio glitches or gaps) meant that it wasn't really workable for cases like sound effects where you want minimum latency to enhance the player experience. When you generate samples directly on an audio thread in response to higher-level game events you get glitch resistance since delaying a game event (e.g. the game thread hitches or even hangs entirely) doesn't cause a sample or clip-level audio glitch or gap in playback, and you can also get special treatment by the kernel thread scheduler. That said, the SDL3 audio system design still sounds like a massive improvement because you get to have it both ways--and if you really want to do all your own stream mixing, no-one is stopping you. The better handling of the default audio device is especially appreciated since that's been one reason I've had to write my own low-level audio portability layers in the past.
very exciting!!!
Definitely not the right place to post this, but I'm super happy to see SDL_Set/GetAudioStreamFrequencyRatio() in SDL3. However, I think renaming it to Pitch (or SamplingRate?) instead of FrequencyRatio would be a million times more intuitive! It's practically begging to be renamed less awkwardly!
There was a discussion about this, actually, where "Pitch" was decided against (because it makes it unclear that the amount of data is changing, since we aren't doing all the FFT magic to transform the pitch without changing the amount of data), and "Sample Rate" is confusing, because there's a totally different thing for setting the sample rate of the data (SDL_SetAudioStreamFormat).
Naming things is hard. :/
@@RyanGordon Oh alright then, thanks for the explanation. Looking forward to the release! SDL is awesome and makes life so much easier.
How does the new AudioStream interface compare to PortAudio and RtAudio's blocking read/write functions? Are the write functions non-blocking?
I don't know how PortAudio and RtAudio do their things, so I can't say. SDL's write function (SDL_PutAudioStreamData) does _not_ block; it queues up any written data until it is needed, and feeds the hardware from it in another thread. This lets you queue as you have new data available, maybe generating a little at a time, or just dump a whole .wav file to the stream and largely forget about it.
@@RyanGordon Awesome! A truly push based model, which is what I was hoping for.
PortAudio's blocking interface forces the application to poll the audio device, as opposed to the audio device polling the application with a callback. So it's still polling, but from the opposite direction. And I think RtAudio is more or less the same.
I dont know why but ... i hate sdl3
-> its sdl2 but with a function lib that pop up if you code an function
Anything new in terms of spatial audio/multi channel audio, and what about low latency exclusive mode options?
Exclusive mode (that is, my game gets the sound hardware and _nothing else does_) is almost never necessary and always never wanted, since by nature it would disable notification sounds, the user's MP3 player in the background, etc. Generally games can get a reasonable and low amount latency without it.
Multi-channel audio: we have everything up to 7.1 audio, so short of driving a movie theater with a 128-speaker Dolby Atmos configuration, we've probably maxed out what most hardware configs can offer to end-users, afaik.
Spatial audio: we aren't planning to mess with this at the SDL level, since you quickly end up reimplementing OpenAL inside SDL, instead of on top of it.
@@RyanGordon Exclusive mode is actually pretty common for things like arcade cabinet setups where the PC is essentially an arcade machine and only runs games. Most video game emulators have exclusive mode options using Port Audio or WASAPI, for example.
Guess this is going to be ignored even though it effectively makes SDL Audio worthless for serious gaming and emulators (ie. the things that would actually use SDL).
Glad we have PortAudio!