Audio; minor doc errors

sdlopenaudio.html:

“/* Mono */
desired->channels=0;”

should be 1; 0 isn’t accepted.

sdlmixaudio.html:

“Use mixing functions from SDL_mixer, OpenAL, or write your own mixer
instead.”

SDL_mixer appears to use SDL_MixAudio.—

Okay, trying SDL’s audio with SDL_sound, and having some problems.
Output is choppy with a buffer of 1024 samples or less at 44100khz,
and 512 samples at 22050. 2048 samples induces noticable latency at
44khz, even for menu sound effects. (The math seems to say 40ms; I
don’t know if that’s what I’m actually getting, but it seems to be in
the right ballpark.) It happens with both DirectSound and WaveOut,
with USE_POSITION_NOTIFY, and with USE_PRIMARY_BUFFER.

PlaySound (SDL_sound test program) also has this problem, so it’s not my
code.

For comparison (to what I’m replacing, so this is what I need to reproduce)
Bass has little perceptible latency (random, rather unscientific tests make
me guess around half the latency of SDL_sound with a 1024-sample buffer,
so around 20ms), and doesn’t skip with 16-bit, 44khz, stereo output. I’m
not sure which audio interface it’s using; the only relevant imports seem to
be mixerOpen and acmStreamSize.


Glenn Maynard

(I do hate replying to myself; oh well.)On Sat, Nov 09, 2002 at 10:31:22PM -0500, Glenn Maynard wrote:

For comparison (to what I’m replacing, so this is what I need to reproduce)
Bass has little perceptible latency (random, rather unscientific tests make
me guess around half the latency of SDL_sound with a 1024-sample buffer,
so around 20ms), and doesn’t skip with 16-bit, 44khz, stereo output. I’m
not sure which audio interface it’s using; the only relevant imports seem to
be mixerOpen and acmStreamSize.

Okay, I’ve figured out what Bass is doing: it’s loading samples into a
hardware buffer ahead of time, which gives it both the advantages of
larger buffers (no skipping even in higher quality formats) and smaller
buffers (low latency). I tried using Bass’s callback method, and it has
the same problems.

So, this is a pain. We need low-latency sound, but SDL’s audio API
can’t handle this. I guess we’re doomed to doing some of our own sound
porting. Is this–multiple hardware sound buffers–something that APIs
on other archs (Linux and Mac, at least) are even capable of?

Perhaps other archs can handle smaller buffers than Win2k; in that case,
I could use SDL as a fallback and just port for systems that need it.
What’s the smallest buffer size people are using on other archs for
16-bit 44khz stereo?


Glenn Maynard

Are you sure you need this kind of latency for technical reasons? Or
just think this will give you the “feel” you think you need? Try
increasing the buffer size to 100ms or more, and see what you get…
There tends to be a “sweet spot” where the latency is still good, but
the sound stops skipping… unfortunately, this sweet spot seems to
change depending on OS, system speed, and system load…

before giving up on SDL for sound, try increasing the latency a little.

Best wishes,

-LorenOn Sat, 2002-11-09 at 21:38, Glenn Maynard wrote:

(I do hate replying to myself; oh well.)

On Sat, Nov 09, 2002 at 10:31:22PM -0500, Glenn Maynard wrote:

For comparison (to what I’m replacing, so this is what I need to reproduce)
Bass has little perceptible latency (random, rather unscientific tests make
me guess around half the latency of SDL_sound with a 1024-sample buffer,
so around 20ms), and doesn’t skip with 16-bit, 44khz, stereo output. I’m
not sure which audio interface it’s using; the only relevant imports seem to
be mixerOpen and acmStreamSize.

Okay, I’ve figured out what Bass is doing: it’s loading samples into a
hardware buffer ahead of time, which gives it both the advantages of
larger buffers (no skipping even in higher quality formats) and smaller
buffers (low latency). I tried using Bass’s callback method, and it has
the same problems.

So, this is a pain. We need low-latency sound, but SDL’s audio API
can’t handle this. I guess we’re doomed to doing some of our own sound
porting. Is this–multiple hardware sound buffers–something that APIs
on other archs (Linux and Mac, at least) are even capable of?

Perhaps other archs can handle smaller buffers than Win2k; in that case,
I could use SDL as a fallback and just port for systems that need it.
What’s the smallest buffer size people are using on other archs for
16-bit 44khz stereo?


Glenn Maynard


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

This is a beat/rhythm game; latency is vital. I can easily detect
latency with a buffer of 2048 samples at 44khz (which would be about
40-50ms) in the menus; it’d be intolerable in-game.On Sat, Nov 09, 2002 at 11:23:05PM -0800, Loren Osborn wrote:

Are you sure you need this kind of latency for technical reasons? Or
just think this will give you the “feel” you think you need? Try
increasing the buffer size to 100ms or more, and see what you get…
There tends to be a “sweet spot” where the latency is still good, but
the sound stops skipping… unfortunately, this sweet spot seems to
change depending on OS, system speed, and system load…


Glenn Maynard

Hmm… I’m not sure I understand… As far as I understand the human ear
won’t be able to detect latency (audibly) less than 100ms… As far as
comparing input to audio, if you know the buffer size, you can calculate
the (almost) exact latency, so you need to compare the input to (for
instance) 100ms in the past… (i.e. when you play a note, if the user
responds before 100ms, than they are “early”… about 100ms would be in
tempo, and after that would be “late”… If you need to play back sound
on user input, you can chop the first 100ms off the sound, if you don’t
know to play it before hand…

I’m not sure I see the problem…

-LorenOn Sat, 2002-11-09 at 23:58, Glenn Maynard wrote:

On Sat, Nov 09, 2002 at 11:23:05PM -0800, Loren Osborn wrote:

Are you sure you need this kind of latency for technical reasons? Or
just think this will give you the “feel” you think you need? Try
increasing the buffer size to 100ms or more, and see what you get…
There tends to be a “sweet spot” where the latency is still good, but
the sound stops skipping… unfortunately, this sweet spot seems to
change depending on OS, system speed, and system load…

This is a beat/rhythm game; latency is vital. I can easily detect
latency with a buffer of 2048 samples at 44khz (which would be about
40-50ms) in the menus; it’d be intolerable in-game.

Are you sure you need this kind of latency for technical reasons? Or
just think this will give you the “feel” you think you need? Try
increasing the buffer size to 100ms or more, and see what you get…
There tends to be a “sweet spot” where the latency is still good, but
the sound stops skipping… unfortunately, this sweet spot seems to
change depending on OS, system speed, and system load…

This is a beat/rhythm game; latency is vital. I can easily detect
latency with a buffer of 2048 samples at 44khz (which would be about
40-50ms) in the menus; it’d be intolerable in-game.

Hmm… I’m not sure I understand… As far as I understand the human ear
won’t be able to detect latency (audibly) less than 100ms…

Maybe in clinical trials but if you’re dancing to a beat or even just tapping
your foot, you should be able to feel a beat that’s off by a fraction of
that. In a DDR-type game you’ll surely notice a 50ms delay between the arrow
hitting the line and the sound coming from the speaker.

As far as comparing input to audio, if you know the buffer size, you can
calculate the (almost) exact latency, so you need to compare the input to
(for instance) 100ms in the past… (i.e. when you play a note, if the user
responds before 100ms, than they are “early”… about 100ms would be in
tempo, and after that would be “late”…

I like this idea, though you’d want to have a separate calibration mode rather
than relying on a player with two left feet for latency calculation purposes
:-)On Sunday 10 November 2002 09:59, Loren Osborn wrote:

On Sat, 2002-11-09 at 23:58, Glenn Maynard wrote:

On Sat, Nov 09, 2002 at 11:23:05PM -0800, Loren Osborn wrote:


Matthew > http://www.soup-kitchen.net/
> ICQ 19482073

Hmm I just looked at the source code (SDL12/src/audio/SDL_audio.c), and
it looks like the latency should be the playtime of the buffer (i.e.
100ms) minus the time it takes to allocate an audio buffer and memset it
to “silence”, with the accuracy of the WaitAudio() function…

I think the WaitAudio() function varies by platform, but I doubt it’s
less accurate than 10ms…

Hope that helped,

-LorenOn Sun, 2002-11-10 at 02:43, Matthew Bloch wrote:

As far as comparing input to audio, if you know the buffer size, you can
calculate the (almost) exact latency, so you need to compare the input to
(for instance) 100ms in the past… (i.e. when you play a note, if the user
responds before 100ms, than they are “early”… about 100ms would be in
tempo, and after that would be “late”…

I like this idea, though you’d want to have a separate calibration mode rather
than relying on a player with two left feet for latency calculation purposes
:slight_smile:

Hmm… I’m not sure I understand… As far as I understand the human ear
won’t be able to detect latency (audibly) less than 100ms… As far as

My own manual response time is 130-170ms; detecting 100ms of latency is easy,
and even 40ms is too much. (Again, assuming that what I’m getting with 2048
samples is, in fact, 40ms or thereabouts, and nothing odd is happening like
getting buffered an extra chunk, which I don’t believe is happening.)

the (almost) exact latency, so you need to compare the input to (for
instance) 100ms in the past… (i.e. when you play a note, if the user

That works for DDR, but not BM; BM has notes keyed to button presses,
and it’s for that I need low-latency sound.On Sun, Nov 10, 2002 at 01:59:24AM -0800, Loren Osborn wrote:


Glenn Maynard

2048 samples of 44khz audio should be 1/44100*2048 = .046 seconds, or
46 ms latency, plus (not minus) any overhead of setting up. Too much
for a music game with keyed notes, and perceptible even for menu sound
effects.

It’d be useful if anyone on Linux or Mac systems could find out what (on
your hardware, of course) is the smallest buffer size you can play
44khz 16-bit stereo audio; my 2k system is around 2048. playsound (in
the sdl_sound distro) can test it, eg. “playsound --audiobuf 1024”.On Sun, Nov 10, 2002 at 12:41:44PM -0800, Loren Osborn wrote:

Hmm I just looked at the source code (SDL12/src/audio/SDL_audio.c), and
it looks like the latency should be the playtime of the buffer (i.e.
100ms) minus the time it takes to allocate an audio buffer and memset it
to “silence”, with the accuracy of the WaitAudio() function…


Glenn Maynard

It sounds like you really need access to either a real-time OS configuration
or real hardware audio buffers. Hardware audio buffers are on the drawing
board for SDL 2.0, but in the meantime it sounds like you want to write to
DirectX audio or possibly ALSA on Linux. Remember that not all configurations
will even have hardware audio buffers available, so if you need less than
~50ms latency then you’re restricting your target hardware.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

That’s what I’m implementing; I’ll use SDL as a fallback, since not all
game modes will need low latency.On Sun, Nov 10, 2002 at 09:12:32PM -0800, Sam Lantinga wrote:

It sounds like you really need access to either a real-time OS configuration
or real hardware audio buffers. Hardware audio buffers are on the drawing
board for SDL 2.0, but in the meantime it sounds like you want to write to
DirectX audio or possibly ALSA on Linux. Remember that not all configurations
will even have hardware audio buffers available, so if you need less than
~50ms latency then you’re restricting your target hardware.


Glenn Maynard

That’s what I’m implementing; I’ll use SDL as a fallback, since not all
game modes will need low latency.

Why not use PortAudio? PortAudio supports ALSA, JACK (the two
standards for Linux audio), Mac, and Windows. You’ll have to rewrite
your audio code in a callback style for the best latency, but that’s
the case anyway.

wbOn Monday, November 11, 2002, at 12:09 AM, Glenn Maynard wrote:

Erm, I thought the two standards are ALSA and OSS? I never even heard of JACK.On 11-Nov-2002, Will Benton wrote:

On Monday, November 11, 2002, at 12:09 AM, Glenn Maynard wrote:

That’s what I’m implementing; I’ll use SDL as a fallback, since not all
game modes will need low latency.

Why not use PortAudio? PortAudio supports ALSA, JACK (the two
standards for Linux audio), Mac, and Windows. You’ll have to rewrite
your audio code in a callback style for the best latency, but that’s
the case anyway.

wb


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

Erm, I thought the two standards are ALSA and OSS? I never even heard
of JACK.

First, learn about JACK at http://jackit.sf.net – it is somewhat like
CoreAudio on the Mac in that it provides full-duplex, low-latency,
sample-synchronized audio for multiple clients. The current
implementation is built on top of ALSA.

OSS is a “standard”, in that it is available with most distributions,
but is not “standard” in the sense of uniformity. OSS does not
provide a uniform way to access audio hardware, burying functionality
under ioctl() calls that may or may not work on any particular card.
It is horribly broken. I think a better way to think of “standard” is
to think of what people should target, and if you are writing a Linux
audio application, you should not think about targeting any API besides
raw ALSA and JACK.

OSS is mostly broken for almost all nontrivial audio work, and is
completely broken for low-latency or real-time work. OSS was a noble
attempt to use “the UNIX model” for interfacing to audio hardware, but
"the UNIX model" is completely inadequate for interfacing to audio
hardware. You can search the linux-audio-dev mailing list archives for
(many) extensive discussions of these issues.

To sum up: if the needs of your application are no more complicated
than “cat file.raw > /dev/audio”, then OSS is adequate for you.
Otherwise, it is outdated and needs to die an undignified death.

best,
wbOn Monday, November 11, 2002, at 12:49 AM, Patrick McFarland wrote:

In the recently posted book “Linux Game Programming” are chapters about sound (alsa, oss and sdl)

so, check it out.________________________________________________________________
Viren? Wir wissen nicht was Ihr Arzt empfiehlt. Wir empfehlen den
Virencheck f?r Dateianh?nge! http://freemail.web.de/features/?mc=021159

I see nothing wrong with OSS on the whole. Some drivers are starting to alter
basic functionality to screw with how OSS functions, like hardware accelerated
application multiplexing (sblive does this.) But yeah, ALSA will be much
better. I just hope it supports a software midi engine for /dev/sequencer and
/dev/midi* so most midi applications will work right without having to screw
with them.On 11-Nov-2002, Will Benton wrote:

On Monday, November 11, 2002, at 12:49 AM, Patrick McFarland wrote:

Erm, I thought the two standards are ALSA and OSS? I never even heard
of JACK.

First, learn about JACK at http://jackit.sf.net – it is somewhat like
CoreAudio on the Mac in that it provides full-duplex, low-latency,
sample-synchronized audio for multiple clients. The current
implementation is built on top of ALSA.

OSS is a “standard”, in that it is available with most distributions,
but is not “standard” in the sense of uniformity. OSS does not
provide a uniform way to access audio hardware, burying functionality
under ioctl() calls that may or may not work on any particular card.
It is horribly broken. I think a better way to think of “standard” is
to think of what people should target, and if you are writing a Linux
audio application, you should not think about targeting any API besides
raw ALSA and JACK.

OSS is mostly broken for almost all nontrivial audio work, and is
completely broken for low-latency or real-time work. OSS was a noble
attempt to use “the UNIX model” for interfacing to audio hardware, but
"the UNIX model" is completely inadequate for interfacing to audio
hardware. You can search the linux-audio-dev mailing list archives for
(many) extensive discussions of these issues.

To sum up: if the needs of your application are no more complicated
than “cat file.raw > /dev/audio”, then OSS is adequate for you.
Otherwise, it is outdated and needs to die an undignified death.

best,
wb


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989