Ok, here’s the current proposal for SDL 1.3 audio API changes. Nothing
in here is final, including new symbol names. Comments and complaints
are welcome.
http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/include/SDL_audio.h?r1=2609&r2=2685
The API changes are in Subversion for 1.3, but the actual
implementations are not, yet.
The basic gist:
-
Macros to extract information from AUDIO_* values:
printf("AUDIO_S16LSB is %d bits per sample.\n",
(int) SDL_AUDIO_BITSIZE(AUDIO_S16LSB));
if (SDL_AUDIO_ISSIGNED(AUDIO_S16LSB))
printf("AUDIO_S16LSB is a signed data type.\n");
if (SDL_AUDIO_ISBIGENDIAN(AUDIO_S16MSB))
printf("AUDIO_S16LSB is bigendian.\n");
-
New data types: 32-bit int and floating point samples (AUDIO_S32LSB,
AUDIO_F32LSB, etc). This will allow better range, and a fast path for
Mac OS X’s CoreAudio. 32-bit types are always signed, but can be in
either byte order.
-
Multiple audio devices. If a given API exposes multiple devices–for
example, DirectSound can see a Sound Blaster Live, the motherboard’s
ac97 chip, and a USB headset–then all three will be available for
seperate control by the application. Opening a specific device with the
new APIs will give you an SDL_AudioDeviceID handle. The old APIs will
continue to exist (and treat the unnamed device as ID #1), which allows
backwards compatibility for those that don’t care about multiple
devices. APIs to match the old functionality but accept a device ID are
being added, as well as functionality to enumerate available devices.
-
Audio disconnect notifications. The app can be notified if a
USB/firewire device has been unplugged, or an esound server has dropped
the connection, etc.
-
SDL_MixAudioFormat(): mix a sound buffer in an arbitrary format,
instead of whatever format the audio device is opened to use. Doesn’t
require an open audio device at all.
-
Capture support: the multiple device support also allows for devices
to be opened for capture (recording). These function as separate logical
devices, even if it’s all on the same sound card.
–ryan.
Hello !
The API changes are in Subversion for 1.3, but the actual
implementations are not, yet.
The basic gist:
- Macros to extract information from AUDIO_* values:
printf(“AUDIO_S16LSB is %d bits per sample.\n”, (int)
SDL_AUDIO_BITSIZE(AUDIO_S16LSB));
if (SDL_AUDIO_ISSIGNED(AUDIO_S16LSB)) printf(“AUDIO_S16LSB is a signed
data type.\n”); if (SDL_AUDIO_ISBIGENDIAN(AUDIO_S16MSB))
printf(“AUDIO_S16LSB is bigendian.\n”);
-
New data types: 32-bit int and floating point samples (AUDIO_S32LSB,
AUDIO_F32LSB, etc). This will allow better range, and a fast path for
Mac OS X’s CoreAudio. 32-bit types are always signed, but can be in
either byte order.
-
Multiple audio devices. If a given API exposes multiple devices–for
example, DirectSound can see a Sound Blaster Live, the motherboard’s ac97
chip, and a USB headset–then all three will be available for seperate
control by the application. Opening a specific device with the new APIs
will give you an SDL_AudioDeviceID handle. The old APIs will continue to
exist (and treat the unnamed device as ID #1), which allows backwards
compatibility for those that don’t care about multiple devices. APIs to
match the old functionality but accept a device ID are being added, as
well as functionality to enumerate available devices.
-
Audio disconnect notifications. The app can be notified if a
USB/firewire device has been unplugged, or an esound server has dropped
the connection, etc.
-
SDL_MixAudioFormat(): mix a sound buffer in an arbitrary format,
instead of whatever format the audio device is opened to use. Doesn’t
require an open audio device at all.
I would like to have two of them. A high speed, low quality one and a low
speed, high quality one.
- Capture support: the multiple device support also allows for devices
to be opened for capture (recording). These function as separate logical
devices, even if it’s all on the same sound card.
100 %
CU
Ryan C. Gordon wrote:
Ok, here’s the current proposal for SDL 1.3 audio API changes. Nothing
in here is final, including new symbol names. Comments and complaints
are welcome.
What about the possibility of taking advantage of the platforms mixing
capability? Sort of like DirectSound’s Primary and Secondary buffers,
where the existing SDL audio API would be akin to DS’s Primary buffers.
I suppose this means effectively integrating part of SDL_mixer into SDL,
especially where the target platform has no mixing capability.
Pete.
Hello !
What about the possibility of taking advantage of the platforms mixing
capability? Sort of like DirectSound’s Primary and Secondary buffers, where
the existing SDL audio API would be akin to DS’s Primary buffers.
This could be usefull to get hardware
acclerated conversion.
I suppose this means effectively integrating part of SDL_mixer into SDL,
especially where the target platform has no mixing capability.
Why ? SDL only needs a simple mixing
and conversion function. It has already both, but
it would be nice to have also better quality ones.
CU
Hi,
I was pleased to see Capture support is mentioned, is this using the same
idea behind the recording patch
(https://bugzilla.libsdl.org/show_bug.cgi?id=10 ) - I tested this under
linux and it works great but lacked win32 support at the time and I didn’t
have time to embark upon it.
-Chris> ----- Original Message -----
From: icculus@icculus.org (icculus)
To:
Sent: Thursday, August 03, 2006 9:21 PM
Subject: [SDL] SDL 1.3 audio API proposal…
Ok, here’s the current proposal for SDL 1.3 audio API changes. Nothing
in here is final, including new symbol names. Comments and complaints
are welcome.
http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/include/SDL_audio.h?r1=2609&r
2=2685
The API changes are in Subversion for 1.3, but the actual
implementations are not, yet.
The basic gist:
-
Macros to extract information from AUDIO_* values:
printf("AUDIO_S16LSB is %d bits per sample.\n",
(int) SDL_AUDIO_BITSIZE(AUDIO_S16LSB));
if (SDL_AUDIO_ISSIGNED(AUDIO_S16LSB))
printf("AUDIO_S16LSB is a signed data type.\n");
if (SDL_AUDIO_ISBIGENDIAN(AUDIO_S16MSB))
printf("AUDIO_S16LSB is bigendian.\n");
-
New data types: 32-bit int and floating point samples (AUDIO_S32LSB,
AUDIO_F32LSB, etc). This will allow better range, and a fast path for
Mac OS X’s CoreAudio. 32-bit types are always signed, but can be in
either byte order.
-
Multiple audio devices. If a given API exposes multiple devices–for
example, DirectSound can see a Sound Blaster Live, the motherboard’s
ac97 chip, and a USB headset–then all three will be available for
seperate control by the application. Opening a specific device with the
new APIs will give you an SDL_AudioDeviceID handle. The old APIs will
continue to exist (and treat the unnamed device as ID #1), which allows
backwards compatibility for those that don’t care about multiple
devices. APIs to match the old functionality but accept a device ID are
being added, as well as functionality to enumerate available devices.
-
Audio disconnect notifications. The app can be notified if a
USB/firewire device has been unplugged, or an esound server has dropped
the connection, etc.
-
SDL_MixAudioFormat(): mix a sound buffer in an arbitrary format,
instead of whatever format the audio device is opened to use. Doesn’t
require an open audio device at all.
-
Capture support: the multiple device support also allows for devices
to be opened for capture (recording). These function as separate logical
devices, even if it’s all on the same sound card.
–ryan.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Ryan C. Gordon wrote:
Ok, here’s the current proposal for SDL 1.3 audio API changes. Nothing
in here is final, including new symbol names. Comments and complaints
are welcome.
How about the ability to get the latency for playing out the audio ?
How about the ability to get the latency for playing out the audio ?
What do you suggest for this?
–ryan.
I was pleased to see Capture support is mentioned, is this using the same
idea behind the recording patch
(https://bugzilla.libsdl.org/show_bug.cgi?id=10 ) - I tested this under
linux and it works great but lacked win32 support at the time and I didn’t
have time to embark upon it.
It won’t be that patch, but it’s roughly the same idea. Capture devices
are more or less like output devices, except you read the buffer in the
callback instead of writing to it.
–ryan.
What about the possibility of taking advantage of the platforms mixing
capability? Sort of like DirectSound’s Primary and Secondary buffers,
where the existing SDL audio API would be akin to DS’s Primary buffers.
I’d say no…most platforms don’t expose hardware buffers beyond what
DirectSound calls the “primary” one, so you end up mixing on the CPU
either way.
I suppose this means effectively integrating part of SDL_mixer into SDL,
especially where the target platform has no mixing capability.
Put like that: definitely no. 
–ryan.
I would like to have two of them. A high speed, low quality one and a low
speed, high quality one.
For mixing? I’m not sure there’s really a compelling difference between
"fast" and “nice” quality.
–ryan.
Hello !
I would like to have two of them. A high speed, low quality one and a
low speed, high quality one.
For mixing? I’m not sure there’s really a compelling difference between
"fast" and “nice” quality.
If you have a fast and high quality function, great.
CU
Ryan C. Gordon wrote:
What about the possibility of taking advantage of the platforms mixing
capability? Sort of like DirectSound’s Primary and Secondary buffers,
where the existing SDL audio API would be akin to DS’s Primary buffers.
I’d say no…most platforms don’t expose hardware buffers beyond what
DirectSound calls the “primary” one, so you end up mixing on the CPU
either way.
I disagree here. Windows obviously supports hardware mixing if the
hardware has it. MacOS X doesn’t yet but should they decide to do so in
future, no doubt they will have an AudioUnit to do it (also I would
imagine the mixer AU is very fast). Games consoles pretty much all have
mixing hardware. The only odd one out here is Linux - a criticism of
ALSA I have had for many years.
Put like that: definitely no.
I would say, leave the fancy stuff like music playback and streaming
from files out of SDL, but make the multiple channel mixer part of it.
Just as a side question to this - is there any chance SDL_mixer will get
free rate mixing at any point?
Pete.
Just as a side question to this - is there any chance SDL_mixer will get
free rate mixing at any point?
If you mean mixing between samples that aren’t power-of-two frequencies,
that’s actually a limitation of SDL 1.2…I plan to fix that in 1.3
without any API changes.
–ryan.
Say what? ALSA does have hardware mixing, as long as the drivers and
hardware support it, of course. I know at least two drivers that
implement it: cs46xx and emu10k1. On supported hardware you get
multiple output streams that can be used independently.
Application support is another thing though. The only application I
know that actually makes use of ALSA hardware mixing is Stepmania.On 8/4/06, Peter Mulholland wrote:
I disagree here. Windows obviously supports hardware mixing if the
hardware has it. MacOS X doesn’t yet but should they decide to do so in
future, no doubt they will have an AudioUnit to do it (also I would
imagine the mixer AU is very fast). Games consoles pretty much all have
mixing hardware. The only odd one out here is Linux - a criticism of
ALSA I have had for many years.
–
Ryan C. Gordon wrote:
If you mean mixing between samples that aren’t power-of-two frequencies,
that’s actually a limitation of SDL 1.2…I plan to fix that in 1.3
without any API changes.
What I meant was like FMOD, where you can arbitrarily specify the
playback frequency per channel at run time (so you can implement effects
like Doppler etc). Basically, the same thing as what most MOD player
engines do.
Pete.
Simon Roby wrote:
Say what? ALSA does have hardware mixing, as long as the drivers and
hardware support it, of course. I know at least two drivers that
implement it: cs46xx and emu10k1. On supported hardware you get
multiple output streams that can be used independently.
Application support is another thing though. The only application I
know that actually makes use of ALSA hardware mixing is Stepmania.
This is not the same thing. This means you can open the sound device
more than once, so that you can have more than one app running that’s
outputting sound. It is not the same as having your app open the sound
device and then being able to feed it multiple channels to mix together.
Whenever I’ve inquired about such features I’ve been curtly told either
a) “Do it in software” or b) “use OpenAL”
Pete.
No, I wasn’t talking about multiple apps opening the same sound device
at once (though it’s naturally a bonus side effect). ALSA really does
support multiple hardware buffers, which it calls “subdevices”.
For example my SB Audigy provides 32 subdevices on its “pcm0p” device
node, according to /proc/asound/card0/pcm0p/info. Stepmania (which as
I’ve previously said is the only app I know of that uses multiple
buffers) opens up 21 of them on startup, according to its stdout
(don’t ask me why it opens so many of them though).
OTOH with my on-board AC97 chip there is only one subdevice. Stepmania
then uses a fallback “ALSA9_Software” backend that does software
mixing on a single ALSA subdevice.
Check out the Stepmania source code, all the crazy stuff they do with
ALSA is pretty interesting.On 8/4/06, Peter Mulholland wrote:
This is not the same thing. This means you can open the sound device
more than once, so that you can have more than one app running that’s
outputting sound. It is not the same as having your app open the sound
device and then being able to feed it multiple channels to mix together.
–
I would like to have two of them. A high speed, low quality one and a low
speed, high quality one.
For mixing? I’m not sure there’s really a compelling difference between
"fast" and “nice” quality.
Perhaps a fast and limited mixer, and a slightly slower but
performing-conversion-on-the-fly version?On Fri, 4 Aug 2006, Ryan C. Gordon wrote:
I’ve written a few s3m/mod/etc players before … coming up with a good and
fast mixer can be a horrid chore (unless of course, you just choose to rip
off someone else’s).
Blunt frequency changers (without doing any FFT’s etc… but rather just
duplicating/skipping samples based on ratio of playback rates) are fast and
relatively ugly… and would only take a lil bit of time to implement…
the prettier mixers are a completely different story… and you’d prolly
also want an API to pick what kind of resampling you want, etc…
I’m not sure if this SDL turf or application turf. I’m leaning towards
application myself.
Just my two cents.
-WillOn 8/4/06, Peter Mulholland wrote:
Ryan C. Gordon wrote:
If you mean mixing between samples that aren’t power-of-two frequencies,
that’s actually a limitation of SDL 1.2…I plan to fix that in 1.3
without any API changes.
What I meant was like FMOD, where you can arbitrarily specify the
playback frequency per channel at run time (so you can implement effects
like Doppler etc). Basically, the same thing as what most MOD player
engines do.
Pete.