GNOME Bugzilla – Bug 160340
[PATCH] gnome-sound-recorder can not play files
Last modified: 2005-02-06 17:32:39 UTC
Launch gnome-sound-recorder (Application->Multimedia->Sound Recorder) Open some file and click on Play Expected behaviour: it should play the file Bug: It throws up an error dialog stating "OSS device is already in use by another program"
I tried doing fuser /dev/dsp, but it does not show me any output. Investigating further, I found out that esd is running on that machine. To reproduce this problem: 1. Launch gnome-sound-properties (Application->Desktop Preferences->Sound) 2. Enable Sound server startup and Sound for events This will launch esd (Esound Daemon) Make sure that esd is running now(ps -ef | grep esd) 3. Launch Application->Multimedia->Sound Recorder and Open some file 4. Give any file name and click on Play It gives the error. esd has /dev/dsp opened in Write mode. So when gnome-sound-recorder tries to open it in Write mode, he gets the EBUSY error and he throws up this dialog. This is from gst-plugins/sys/oss/gstosselement.c (gst_osselement_open_audio). It should rather try again to open the device. So when esd releaves it, it will get it and can play the file. ~ ~
Ronald, I can think of 2 ways to solve this bug. If file opening fails and error is EBUSY then: 1. Find out the file that esd is going to play for a button click event. Calculcate the time that this file will take to play. Do a sleep for that amount of time + 1 second. After this time is over, try again to open the device. 2. Just put a timer of 4 seconds(emperical, 2 seconds of the click event sound + 2 seconds) and then try again to open the device, if it fails to open this time, then throw up the error dialog. Please suggest in case there can be any other way out.
Created attachment 34700 [details] [review] Patch using the second approach Attached is a patch which uses second approach mentioned above. It keeps trying to get the device so that as soon as esd releases the device, it gets it. If it does not get the device in 5 seconds, it times out and throws up the error dialog.
Hm, so is esd launched on g-s-r startup then? Or is there another specific reason that we'd want to wait 5 seconds instead of erroring out? I'm not directly against the approach, but it's rather odd...
Ronald, When we enable "Enable sound server startup" option in gnome-sound-properties then esd is started. The problem mentioned in this bug report happens when the above option is enabled along with "Sound for events" option in gnome-sound-properties So when the "play button" is clicked, esd plays a wav file to indicate that "play button" is clicked. During this time esd holds the audio device (/dev/dsp). So when g-s-r tries to open the audio device it gets EBUSY error and hence this problem. Since the wav files associated with the button click events are mostly around 2 to 3 seconds I am doing a wait for 5 seconds before erroring out. But if the device is freed before 5 seconds g-s-r starts playing the file. Okay to commit with 5 second timeout ? Ofcourse if we use esdsink instead of osssink, it becomes sequential as esd is the one that services our request.
Ah, ok, I see. That's a really cool explanation for students on what a race condition is. ;). Go ahead and apply if you've tested it, it seems fine to me. Thanks!
Hi, Sorry for late responding. I do not have commit access. Could you please commit this patch.
*** Bug 146046 has been marked as a duplicate of this bug. ***
*** Bug 158925 has been marked as a duplicate of this bug. ***
Moving this bug to gstreamer as the patch is for gst-plugins
Whoops... Right, forgot it's GStreamer... Ehm... Which reminds me, this is very OSS specific. You could do a similar approach to g-s-r, in the state change from NULL to READY (or PLAYING, in which case you can split it in two). Then, it'd work for all of OSS, ALSA and SunAudio at once... What do you think?
Archana, can you please tell me if you think my last comment is a better idea? It'd work accross soundsystems...
Ronald, I am looing into how we can implement it in a generic way. Will update the report in a day or two with the findings.
Thanks, I'll reopen the bug for the generic solution then.
Please review the attached patch for the generic solution. Now, I have added a timeout function of 3 seconds if we encounter EBUSY error while trying to get the device. This function will try to get the device again and if we dont get it this time also, we will throw up the error dialog. You may also want to test it.
Created attachment 36817 [details] [review] Patch which provides a generic solution
Comment on attachment 36817 [details] [review] Patch which provides a generic solution Looks good, basically what I had in mind. Go ahead and apply, please.
I noticed this was applied, so closing bug...