Sorry but this bug is a control center bug.

In gnome-settings-daemon/gnome-settings-sound.c line line 53 I read :

static const char *esd_cmdline[] = {ESD_SERVER, "-nobeeps", NULL};

*** Bug 3558 has been marked as a duplicate of this bug. ***

Bug 3558 has nothing to do with this bug.

You can't fix both bugs though. Either esd reads its options from
esd.conf (the right thing to do), or control-center sets them (would
work for fixing bug 3558, but that is what this bug is about!).

I have been trying to get esd and gnome to work with my laptop for
some time, and have to specify -r 48000 to esd to get it to work.  I
feel the esd.conf file should be read by esd if no other options are
present.  Based on feedback from others, this seems like the right
thing to do.  I could patch gnome-session to parse esd.conf, but esd's
default behavior is backward IMO, so I did it there.

This patch makes esd read in esd.conf if it is called without
arguments (and ESD_SPAWN_OPTIONS is unset).  Though other behaviors
are possible, this made the most sense to me:  if the user supplies
command line arguments, then assume the user knows what he or she is
doing and don't merge in esd.conf.  Likewise for ESD_SPAWN_OPTIONS.

The benefits of this patch are twofold.  

1.  the user can adjust a single configuration file, rather than
having to worry about environment variables and command line
arguments.  It also keeps users from wondering why adjusting esd.conf
doesn't do anything when esd is not set to autospawn (its default
behavior).

2.  this patch decouples gnome-session from having to know what
options are used to set esd (eg, '-nobeeps').  The esound packager can
simply put in reasonable defaults into esd.conf, and gnome-session
will just work.  Because this patch only reads esd.conf if esd is
called with no options, gnome-session would need to be recompiled to
not pass esd any options (trivial).

The patch is based on the existing code in esound.  First, I created
esd-config.h, and just pulled a couple of defines out of esd_config.c
and put them into esd-config.h, so I could use them in esd.c.  I did a
small cleanup to get rid of a compilation warning for the strtok_r
define.  After that, the only change to esd_config.c is to include
esd-config.h.

The main part of the patch is a modification to esd.c, in main(). 
Basically, I reference esd_spawn_options in esd_config.c in the same
manner that esdlib.c does (ie via extern).  Then, if argc > 1, nothing
is changed-- command line arguments are processed.  If argc == 1, then I
call esd_config_read() (from esd_config.c), tokenize esd_spawn_options
and then they are processed with the same code that processes argv.

To make the code cleaner, I made:

num_opts = argc;
opts = argv;

and then just use num_opts and opts in place of argc and argv for
parsing the arguments.  The net effect is that if esd is called without
arguments, I create arguments for it based on the 'spawn_options' line
in esd.conf.  Because I am using esd_config_read(), ESD_SPAWN_OPTIONS
are also honored.

To apply, save the patch to the directory that esound-0.2.28 is in, and
do:
cd esound-0.2.28
cat ../esound-0.2.28.esdconf.patch | patch -p1

Created attachment 12954 [details] [review]
make esd read esd.conf if called without arguments

Created attachment 12970 [details] [review]
make esd always use esd_config_read(), instead of just when autospawning

Based on feedback from the debian maintainer, I changed the patch to
make esd.conf a general config file.  In other words, esd always looks
at ESD_SPAWN_OPTIONS and spawn_options in esd.conf first (by calling
esd_config_read()), then merges command line arguments.  Command line
arguments take precedence over ESD_SPAWN_OPTIONS and esd.conf.

This patch will greatly help gnome users have have flaky hardware
(like me with i810_audio) who have to specify a rate for esd to work
at all.  It also makes configuring esd more intuitive in that the user
can configure it using /etc/esound/esd.conf, ~/.esd.conf,
ESD_SPAWN_OPTIONS, and command line arguments-- esd will act the same
whether it is set to autospawn or not.

Please use the new patch instead..

Maybe doing some work to create a list of known problematic hardware
would be nice too. I'm sure that would help the bugherders when trying
to help users fix their sound problems.

*** Bug 108197 has been marked as a duplicate of this bug. ***

Should the patch keyword be removed? Is there a patch in here that's
acceptable?

Frédéric? Should we remove the patch keyword or close this or what do
you think?

Hmm, James opened another bug with this patch (or a similar patch)
attached and it was applied to esound.

Duplicating..

*** This bug has been marked as a duplicate of 118230 ***