Quote:
Originally Posted by SLK021
You are right
|
Indeed that does support my hypothesis that an application has seized the audio device, and is not letting go of it (although that is not a conclusive test).
What you could do is try and determine what application is seizing the audio device, and not letting go of the device, so that other applications can not access the audio device.
If you look at the openSUSE audio troubleshooting guide here:
SDB:AudioTroubleshooting - determining which application is using the sound device - openSUSE you will note you can determine what application is using your audio sound device at any one time by typing:
Code:
lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
In order to use this command to good purpose, you need to characterize/understand what its output is giving you. Hence save the output in a text file, with an appropriate label/description noting what application you were using to play audio at the time. Do this many times, and then compare the content of the different files.
To get a look at the sort of investigation one can do, please examine this thread:
sound stop working after updating on asus k50in - openSUSE Forums
Now its not as complex as that thread might make you think.
Some basics you need to know wrt Linux sound. Typically Linux sound daemons/servers ONLY allow one application at a time to access the sound device/hardware. If that application is badly behaved, and does not let go of the device (when the application is closed) then no other applications can access the device. It may be worth your reading up on some sound concepts:
Sound-concepts - openSUSE
Note that the alsa application is both an audio driver, and also provides an API (the alsa API). Not all desktops nor multimedia applications will use the alsa API. They ALL use the alsa sound driver. One advantage of the alsa API is it will allow sharing of audio between applications. ie if multimedia application-a is using the alsa API and multimedia application-b is using the alsa API, then they both will be able to access the audio device at the same time and hence they both will be able to play sound at the same time. Pulse audio was supposed to provide the same capability, but pulse audio has bugs.
On my PCs, I have changed the output sound engines in all applications to use the "xine" sound engine and where selectable to use the alsa API (sometimes just labelled "alsa" or "advanced linux sound architecture" as opposed to OSS, or aRts, or esound). I have also used the application xine-ui to ensure my xine is using the alsa API.
Hence for example, when I play amarok, I get audio. I can also launch smplayer, and get audio playing out of smplayer at the same time as amarok.