Grrr... ESD

SDL Development
1

ESD has an autostandby mode in which it will release the soundcard if there
has been no activity for a while. Currently, if an SDL application starts
up when ESD is idle, then SDL will grab the soundcard and ESD will not be
able to run.

The RedHat 6.1 default (?) configuration has ESD set up this way, but also
turns on window manager sounds so that the window manager will hang if it
can’t play sounds for some reason. I consider this a bug in the window
manager, but it’s affecting lots of SDL-game users.

The problem with using ESD by default is that it has high latency.
ESD has a hard-coded lag of at least 4k samples, or 80ms.

So, I made the ESD support into it’s own selectable driver, and it currently
has preference if ESD is running. The problem is, some audio card drivers
can handle multiple applications accessing the audio device, and it simply
mixes them together on output. We want to do this whenever possible, to
avoid the latency issues with ESD.

There are two problems with this:

  1. What if the user explicitly wants to use ESD for audio over the network?
  2. How do we detect when the audio device can handle opening the device
    multiple times when ESD is idle?

Ideas?

My inclination is to have the /dev/dsp driver take preference, but have
the ESD driver selectable by the user via environment variable.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

2

Yeah, do the default /dev/dsp and maybe have it switchable at runtime so
that a user in the game could potentally select ESD if the game programmer
wanted that to be an option…On Mon, 31 Jan 2000, Sam Lantinga wrote:

ESD has an autostandby mode in which it will release the soundcard if there
has been no activity for a while. Currently, if an SDL application starts
up when ESD is idle, then SDL will grab the soundcard and ESD will not be
able to run.

The RedHat 6.1 default (?) configuration has ESD set up this way, but also
turns on window manager sounds so that the window manager will hang if it
can’t play sounds for some reason. I consider this a bug in the window
manager, but it’s affecting lots of SDL-game users.

The problem with using ESD by default is that it has high latency.
ESD has a hard-coded lag of at least 4k samples, or 80ms.

So, I made the ESD support into it’s own selectable driver, and it currently
has preference if ESD is running. The problem is, some audio card drivers
can handle multiple applications accessing the audio device, and it simply
mixes them together on output. We want to do this whenever possible, to
avoid the latency issues with ESD.

There are two problems with this:

  1. What if the user explicitly wants to use ESD for audio over the network?
  2. How do we detect when the audio device can handle opening the device
    multiple times when ESD is idle?

Ideas?

My inclination is to have the /dev/dsp driver take preference, but have
the ESD driver selectable by the user via environment variable.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

3

“Sam” == Sam Lantinga writes:

Sam> ESD has an autostandby mode in which it will release the
Sam> soundcard if there has been no activity for a while. Currently,
Sam> if an SDL application starts up when ESD is idle, then SDL will
Sam> grab the soundcard and ESD will not be able to run.

Which–for the benefit of people who haven’t yet seen this–has the
side effect of delaying, without any hint as to why, any activity that
is normally accompanied by a sound. This includes popping up a new
window or moving the GNOME panel to the side. Then, when the
SDL-using app quits, all the queued activity takes place. Although
it’s not SDL’s fault, it’s still a pretty ugly situation to get into,
especially for the user who doesn’t know what’s going on.

Sam> The RedHat 6.1 default (?) configuration has ESD set up this
Sam> way, but also turns on window manager sounds so that the window
Sam> manager will hang if it can’t play sounds for some reason.

Although in earlier e-mail to you I said that I thought the RH 6.1
default was to use ESD, I was mistaken.

As a test I removed ~/.gnome/sound/system to see what defaults I would
get and ESD isn’t started by default and you can’t get sound cues
unless you click the box to make it start. I created a new test
account and verified that it gets the same defaults.

Sam> I consider this a bug in the window manager, but it’s affecting
Sam> lots of SDL-game users.

Yes, and unfortunately it will only get worse.

Sam> The problem with using ESD by default is that it has high
Sam> latency. ESD has a hard-coded lag of at least 4k samples, or
Sam> 80ms.

Sam> So, I made the ESD support into it’s own selectable driver, and
Sam> it currently has preference if ESD is running. The problem is,
Sam> some audio card drivers can handle multiple applications
Sam> accessing the audio device, and it simply mixes them together on
Sam> output. We want to do this whenever possible, to avoid the
Sam> latency issues with ESD.

Sam> There are two problems with this: 1. What if the user
Sam> explicitly wants to use ESD for audio over the network? 2. How
Sam> do we detect when the audio device can handle opening the device
Sam> multiple times when ESD is idle?

Sam> Ideas?

I think you should look for a technical contact at Red Hat (and perhaps
with other Linux distributors) and see what he recommends, both for
the current distribution of Red Hat and for future distributions.

Sam> My inclination is to have the /dev/dsp driver take preference,
Sam> but have the ESD driver selectable by the user via environment
Sam> variable.

In the long run, that’s going to lead to more tech. support calls for
anyone releasing SDL-using applications. As Linux is used by more and
more non-propeller-heads, more of them will find the check-box for
enabling ESD and check it. Some of them will install an SDL-based app
later and then be totally mystified by the apparent breakage. They
won’t remember having turned on ESD and from their point of view the
last thing they did was install the SDL-using application. Some will
figure out what went on, but others will call tech. support.

This issue might affect anyone who releases an application that opens
/dev/dsp. As such, it’s quite possible that Red Hat (and any other
distribution creator that makes it easy for people to turn ESD on in
the “shoot yourself in the foot mode by allowing someone else to grab
/dev/dsp out from under us”) already has recommendations on how to
deal with this problem. If they don’t, then now might be a good idea
to bring it to their attention so that come May we don’t find Red Hat
7.0 having the same problem, but defaulting to ESD being on.

Sam> See ya! -Sam Lantinga (slouken at devolution.com)

–Cliff
@Clifford_T_Matthews

4

There are two problems with this:

  1. What if the user explicitly wants to use ESD for audio over the network?
  2. How do we detect when the audio device can handle opening the device
    multiple times when ESD is idle?

Ideas?

Aren’t there functions to determine #2? I’d hope that there would be.
Personally, I don’t use ESD, so it’s not that much of a worry. I keep on
looking at using ALSA and having a look at that, so if I ever get around to
installing it and I like it, I can cobble up a driver.

My inclination is to have the /dev/dsp driver take preference, but have
the ESD driver selectable by the user via environment variable.

Sounds good. Or, you could have an /etc/SDLconfig file, whcih you could read
large chunks of defaults from. I suspect that as SDL evolves and grows, more
code and more configuration options will need to be added. I have some general
purpose code that I could adapt for SDL; it uses StrTok, so it’s even ANSI
standard.

See ya!
-Sam Lantinga (slouken at devolution.com)

Nic

5

purpose code that I could adapt for SDL; it uses StrTok, so it’s even ANSI
standard.

Eek!

From ‘man strtok’:

BUGS
Never use this function. This function modifies its first
argument. The identity of the delimiting character is
lost. This function cannot be used on constant strings.

:slight_smile:

m.On Tue, Feb 01, 2000 at 04:44:20PM -0000, vining at pacificcoast.net wrote:

–
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC

6

From ‘man strtok’:

BUGS
Never use this function. This function modifies its first
argument. The identity of the delimiting character is
lost. This function cannot be used on constant strings.

That’s not a bug, it’s a feature! :slight_smile:

Funny. I’ve used it fine and have had no ill side effects (although I’ve
never gone through the string again) It depends how you use it. Sure, strsep
is nice®, but I’m pretty sure there’s no version for Win95.

Of course, Real Hackers write their own string functions :wink:

m.

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: briareos@lokigames.com (Michael Vance)
To: sdl at lokigames.com
Date: Tuesday, February 01, 2000 11:37 AM
Subject: Re: [SDL] Grrr… ESD
On Tue, Feb 01, 2000 at 04:44:20PM -0000, vining at pacificcoast.net wrote:

7

Hell yeah! I have a pimp string split library! anyone want it?On Tue, 1 Feb 2000, Nicholas Vining wrote:

-----Original Message-----
From: Michael Vance
To: sdl at lokigames.com
Date: Tuesday, February 01, 2000 11:37 AM
Subject: Re: [SDL] Grrr… ESD

On Tue, Feb 01, 2000 at 04:44:20PM -0000, vining at pacificcoast.net wrote:

From ‘man strtok’:

BUGS
Never use this function. This function modifies its first
argument. The identity of the delimiting character is
lost. This function cannot be used on constant strings.

That’s not a bug, it’s a feature! :slight_smile:

Funny. I’ve used it fine and have had no ill side effects (although I’ve
never gone through the string again) It depends how you use it. Sure, strsep
is nice®, but I’m pretty sure there’s no version for Win95.

Of course, Real Hackers write their own string functions :wink:

m.

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

8

ESD has an autostandby mode in which it will release the soundcard if there
has been no activity for a while. Currently, if an SDL application starts
up when ESD is idle, then SDL will grab the soundcard and ESD will not be
able to run.

The RedHat 6.1 default (?) configuration has ESD set up this way, but also
turns on window manager sounds so that the window manager will hang if it
can’t play sounds for some reason. I consider this a bug in the window
manager, but it’s affecting lots of SDL-game users.

The problem with using ESD by default is that it has high latency.
ESD has a hard-coded lag of at least 4k samples, or 80ms.

Yes, latency is the big problem here,
I am actually experimenting with a sound-server protocol which should give you
less than 5-10ms latency.
I am still figuring out if this will work well in pratical applications.
Anyway single apps which run SCHED_FIFO on a kernel with low-latency patches
(these patches will go into linux 2.4)
can easily achieve 3ms audio latency, an order of magnitude better than a game
requires.
:slight_smile:

at http://www.linuxdj.com/mucos ( still brainstorming phase, not much code
around)
the goal is to create a a realtime Multimedia communication
API for linux/UNIX, actually mainly for audio (plugin-streaming + fast
client/server model), but the PAI may include video too,
(for example streaming an mpeg video from disk to a decompressing plugin, and
then stream the data to a real-time blur filter plugin before sending the video
to screen).

Note that in a low-latency audio client/server enviroment,
the server and the clients are required to run with SCHED_FIFO policy,
or the scheduler will simply be unable to meet the deadlines when there
is some activity on your system. (a simple write to a logfile could cause a
dropout).

problem:
we do not want to run our games as root,
but SCHED_FIFO requires root, therefore it would be nice it the next linux
version could prodive a sort of “realtime” group (like on IRIX and HP-UX),
which grants the app to use sched_setscheduler() and mlock() / mlockall().

So, I made the ESD support into it’s own selectable driver, and it currently
has preference if ESD is running. The problem is, some audio card drivers
can handle multiple applications accessing the audio device, and it simply
mixes them together on output. We want to do this whenever possible, to
avoid the latency issues with ESD.

very annoying to play a game with delayed audio output.

There are two problems with this:

  1. What if the user explicitly wants to use ESD for audio over the network?

give him the option at runtime
:slight_smile:

  1. How do we detect when the audio device can handle opening the device
    multiple times when ESD is idle?

open it 2 times and see if the 2nd time the open() call returns an error

Ideas?

My inclination is to have the /dev/dsp driver take preference, but have
the ESD driver selectable by the user via environment variable.

yes, not bad, anyway we can use a /dev/dsp wrapper for those apps
which open the audio device directly.

Benno.On Tue, 01 Feb 2000, Sam Lantinga wrote:

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

9

Okay, notes based on the new ESD code:

There are two problems with this:

  1. What if the user explicitly wants to use ESD for audio over the network?

give him the option at runtime
:slight_smile:

This is currently done by specifying the ESPEAKER environment variable.

  1. How do we detect when the audio device can handle opening the device
    multiple times when ESD is idle?

open it 2 times and see if the 2nd time the open() call returns an error

Great idea! Implemented!

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec