Again and again, do NOT assign bugs directly to people !!

back to esound alias

Now, what are the settings in Sound configuration dialog ?

And which distro are you using ?

Frederic: Sorry I didn't assign this bug to you. I just left the
"Assigned to " Filed empty. I guess by default all esd bugs may be
assigned to you.

In gnome-sound-properties both the "Enable sound server startup" and
"sound for events options" are not selected. In this case I am getting
no sound output from any of the above mentioned things and recording
does not seem to happen. But all works fine when I do a pkill esd.

But when the options in gnome-sound-properties are selected and then
logged in, then all the above things are working fine, without doing a
pkill esd.

Do we need to have this options set in order for all this to work.

Thanks

Further, if the option in the gnome-sound-properties are not set
and if I try to play a mp3 in nautilus-music-preview, I am 
getting a dialog saying 

Sorry, but the music view is unable to play back sound right now. This
is because the Enable sound server startup setting in the Sound
section of the Control Center is turned off.

But even after setting the options, the progress bar in the music
preview moves but no sound output.

But if I set this options in the gnome-sound-properties and then
logout and login everything is working fine.

Hope I am clear

Sorry for bashing you about the assign stuff.. I'll bash louis :))

It seems auto-spawn has some problems on your system (and I still
don't know why distro you are using...). You should check which
options are given to esd auto-spawn (check /etc/esd.conf)

Try disabling auto-spawn (edit /etc/esd.conf). This will prevent esd
to be started when an application need sound. This also means you will
need to enable sound server at startup..

No Problem :)

By distro if you mean distribution then esound is taken from CVS head.
The entry in /etc/esd.conf is as follows

[esd]
auto_spawn=1
spawn_options=-terminate -nobeeps -as 2
spawn_wait_ms=100

This is in Linux Box.

The same behaviour is also noted in a Solaris box also and in Solaris
and the same lines are present in /opt/gnome-2.0/etc/esd.conf.

This problem is seen not only in my machine. I checked up some other
linux machine and also in most of the lab machines (Solaris)
and all behave the same way.

So to have all the above things work properly, do we need to set
the "Enable sound server startup" in gnome-sound-properties then
login.  Thanks.

Try increasing spawn_wait_ms to 500, it might fix the problem..

I tried changing spawn_wait_ms to 500 in both Solaris and Linux
but still the problem is not solved

You should try to enable full debugging in your esound build
(--enable-debugging at configure stage) and add debug flags to the
auto-spawn option (-vt -vm -vc) to determine where is the problem
exactly...

Frederic: Can I mark bug 89130 as a duplicate of this bug. 

Agreed, I was about to suggest that..

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

Federic, I used --enable-debugging with while running autogen and
in esd.c I changed the values of the following varibales from 0 to 1

int esdbg_trace = 1;          /* show warm fuzzy debug messages */
int esdbg_comms = 1;          /* show protocol level debug messages */
int esdbg_mixer = 1;          /* show mixer engine debug messages */

So now when I run esd in the command prompt I am getting the debug  
messages. But the point is when I log in esd is started automatically
and I am not able to see the debug messages. But if kill esd and
start it in a command promt all the above things are working.
So is there any other way to debug this problem. Thanks, Bala

Try starting esd before login (using a console login) or patch
gnome-control-center gnome-settings-daemon to redirect esd output when
it starts it..

when I login to gnome-desktop, esd_proto_standby() handler is called
and hence esd_forced_standby is set to 1. So when we get a record
request, esd_proto_stream_recorder () returns 0 in the following lines

if ( esd_on_autostandby  && !esd_forced_standby ) {
        ESDBG_TRACE( printf( "stuff to record, waking up.\n" ); );
        esd_server_resume();
    }

    /* if we're in standby mode, go away */
    if ( esd_on_standby )
        return 0;

And hence recording is not happening.

I guess esd_proto_resume () has to be called when we get a
record request. I tried calling esd_proto_resume () when
esd_forced_standby is set from esd_proto_stream_recorder () but the
validation fails.

When esd is run with -as option esd_server_standby() is called and
when we get a request esd_server_resume() can be called. 

When is esd_proto_standby() called and how can esd_proto_resume() 
be called ? I guess simillar things are happening for other request
and hence when we login for the first none of the above things 
mentioned in the bug report are working. 

When I do a pkill of esd all the above mentioned things are working
and under this condition esd_proto_standby () is not called.

I am attaching the trace files for esd when it is not working i.e.
after logging in and after doing a pkill esd.

Elliot, Federic: Can you suggest some way to fix this?

Is this problem reproducible or is it only happening to few systems.

I guess if we can fix this before August 23rd it will be nice.

Thanks.

Created attachment 10610 [details]
Trace file when recording is not happening. At this point none of the things mentioned in the bug report is working

Created attachment 10611 [details]
Trace file after doing pkill esd, when all the things mentioned in the bug report is working

With the latest code also I am seeing the problem. 

i dont understand the logic, how come the flags esd_forced_standby 
and esd_on_standby related. Even if the forced_standby is set to 1, 
there is no reason why it should return unless the esd_on_standby is 
set to 1. Now if i check on the code the only place esd_on_standby is 
set to 1 is in esd_server_standby(). 
would like to look at the code to really come out with anything 
useful but somehow not convinced with the above explanations.

I've look quickly to gnome-settings-daemon (in gnome-control-center)
and it seems to access esd and put it in standby.. This might be the
reason of this problem.. 

Created attachment 10734 [details] [review]
Patch for this bug

Federic: Please review this patch and give your comments.
This patch set esd_forced_standby only when esd_on_autostandby is
not set. And when ever we get a play/record request we check whether
esd_on_autostandby or esd_forced_standby is set. If any one of them
is set then we call esd_server_resume. This solves the problem.
Thanks.

The part of the patch to only set forced_standby if not autostandby
makes sense.

The rest of it is essentially causing forced_standby to have the same
effect as autostandby, which is broken.

The real problem is that gnome-settings-daemon is trying to use
esd_standby() as a substitute for a non-existent
esd_make_the_daemon_exit() function - the right solution is to do
nothing. Patches are needed in gnome-control-center (don't call
esd_standby at all, ever) and libgnomeui (don't call
gnome_sound_connection_get() unless enable_esd is true).

hi
in the case what bala mentioned, the esd startup from the gnome-
control-center is turned off, the gnome-session seems to be starting 
the esd daemon with autostandby mode enabled hence even though the 
control center code may be broken, it is not affecting in this case. 

and in the case of libgnomeui, the gnome_sound_connection_get() is 
only called when the enable_esd is set to true. Just checked up the 
code, the initialize_gtk_signal_relay() is calling the 
gnome_sound_connection_get() and initialize_gtk_signal_relay() is 
only called when the enable_esd is set to true otherwise not ( in 
functions event_sounds_changed_cb() or setup_event_listener() in file 
libgnomeui/libgnomeui/gnome-ui-init.c. The initialize_gtk_signal_relay
() is the one which attaches the signal function relay_gtk_signals() 
which calls gnome_sound_connection_get(). Sorry for this confusing 
explanation but in short, if the enable_esd is not set in the gconf 
entry, the gnome_sound_connection_get() will not be called by 
libgnomeui.

am i missing something here though?

adding myself to the cc list

As ponited out earlier, esd is started even if the "enable sound
server startup"  option is not choosen. Michael has given a patch
for this problem in gnome-control-center. Bug id 91535.
This patch might also solve this problem as well. Updated p1535 also.

I'm cc'ing the gnomecc maints on this bug, since apparently gnomecc
work is needed for the most correct fix. That said... does the fix for
91535 actually fix this? That's in CVS now, so it should be testable.

I have tested with the fix for bug 91535 and it is working.
Mariking this bug as Fixed->Verified. Thanks