Am Montag, 9. August 2004 18:45 schrieb Guenter Lichtenberg:
On Sunday 08 August 2004 10:47, Daniel Eckl wrote:
Zitat von Guenter Lichtenberg
: What I meant with 'strangely' was that I have to put in 'artsplay' as the *external* player if I want to hear any sound notifications, even if no other application uses the soundcard.
Hi Guenter!
artsd _is_ an application which uses the soundcard.
If artsd is running, it opens the soundcard and blocks it for other applications. Even if no arts _client_ it playing sound. It just runs in the background and keeps the soundcard open.
That's why you have to use artsplay, because it does not use the soundcard directly but uses the artsd which plays the sound over it's own connection to the card.
If you use KDE on RedHat, then you have the very same problem. There are only two possible reasons why it behaves other way:
1. You have an EMU10K1 based soundcard there (Soundblaster 512, Live!, Audigy)
2. The artsd sound daemon is configured that way, that it releases the sound card after some (perhaps some very few) seconds. You can do that under SuSE, too in KDE control center.
Now clear? ;)
Hi - thanks for the answer. On the risk of being banned forever from this list (or worse: being ignored) some more ramblings. I don't exactly know what soundcard my PC on work (the redhat one) has: I know that it is an onboard Intel sound and artsshell status gives oss as the audio method. I don't know how to find the details under redhat (didn't find lsmod or something similar) but I also didn't put too much time into it, since I'm supposed to work at my work PC ;-). On work the server suspends after 15 seconds. I get my system notification immediately also when some other application is using the soundcard, so I guess everthing is channeled through artsd or whatever the sound-configuration has as the output.
On my home PC (alsa (snd-via686,snd-via8233) driver for a VIA onboard sound card and an AMD64 motherboard, which I always thought was not one of the cards you mention above) suspend is set to 5 seconds.
I did some testing: Case A: external player not used: No sound even when the artsd sound server is suspended
Case B: external player set to artsplay: Notification always works immediately, even when I start realplay and let it run my favorite radio station, i.e constantly playing sound. While realplay is running artsshell gives sound server suspended as expected. But now the surprise at least for me: Notification still works, artsshell gives soundserver running, suspending in xx seconds after the notification. From that I would conclude that I somehow managed -unknowingly- to configure the sound system for more than one application. I did have to compile the alsa drivers myself to get the sound running, but I blindly followed the instructions, maybe there the answer lies.
I dimly remember that under SuSE 8.2 (on an other system) I got all notifications that came up during running another legacy application at once after stopping the application (which is also understandable, I guess the notification are simply put into a buffer and artsd grabs the sound device as soon as it is available and plays the buffered sounds).
Maybe I don't understand the 'external player' in sound notifications of the control center correctly. I thought that anything except artsplay is meant by external. But maybe anything except some default set by the sound-system is meant by external. Or I don't understand artsplay: I thought it always goes through artsd.
So I'm still mildly confused, but since everything is working even better than expected this is no problem (keeps me from thinking I know everything)
Thanks for the patience and reading through my ramblings gl
Hmmmmm.... let's see.... You have artsd running. It's suspended after some seconds, so we assume the sound card to be not blocked. If you don't set an external player, the filename of the sounds will be given directly to artsd. This opens the sound device on demand and plays the sound. So sound server artsd should automatically go from suspend mode to running mode __if the soundcard is not blocked by another application__ But if it's blocked, then artsd will set the filenames of the sounds in a queue and if the blocking application releases the sound card, artsd will grab it at once and starts playing all the sounds in the queue. If you set "external player" in control center > system notification, then all the filenames of the sounds are just given to the external player instead of artsd. - This player can open the sound device itself. You could use play which plays a wav through oss. If artsd was disabled, terminated or suspended by not being used for the configured amount of time, the soundcard should not be blocked and the sound should play. (tested and working fine here) - The external player can be "artsplay", too, which connects to the local running artsd. This daemon get's the play request and open's the sound device again and plays sound. This is possible, but should give the very same effect than not using an external player itself: Sound playing through artsd. So I'm a bit puzled what could be the reason for your problem. If artsplay plays good as external player, then the sound should work without expernal player configuration, too, because it uses artsd directly. So you can check if your artsd, which is running in suspend mode, gets blocked by another application using the soundcard. In this case I use lsof for that reason. For example: # lsof -nP |grep "pcm\|dsp\|dmix\|snd" timidity 3135 root 6u CHR 116,1 53422 /dev/snd/seq gkrellm 4944 daniel 12u CHR 116,0 53189 /dev/snd/controlC0 So this means that timidity running in the background uses the sequencer port. Fine, no problem. Gkrellm uses the control port for controlling volume and other mixer stuff. No blocking by that, too. So the sound card is not blocked. Now I use an application which opens the sound device. timidity 3135 root 6u CHR 116,1 53422 /dev/snd/seq gkrellm 4944 daniel 12u CHR 116,0 53189 /dev/snd/controlC0 xmms 7806 daniel mem CHR 116,16 53295 /dev/snd/pcmC0D0p xmms 7806 daniel 11u CHR 116,0 53189 /dev/snd/controlC0 xmms 7806 daniel 13u CHR 116,0 53189 /dev/snd/controlC0 xmms 7806 daniel 15u CHR 116,0 53189 /dev/snd/controlC0 xmms 7806 daniel 16u CHR 116,16 53295 /dev/snd/pcmC0D0p So xmms is using /dev/snd/pcmC0D0p, which is the first (and only) pcm channel of my soundcard. Now artsd cannot play as can any other application. Now I close xmms and start artsd: (excerpt) artsd 7872 daniel 11r CHR 116,33 53423 /dev/snd/timer artsd 7901 daniel mem CHR 116,16 53295 /dev/snd/pcmC0D0p artsd 7901 daniel 10u CHR 116,16 53295 /dev/snd/pcmC0D0p Artsd is now using (and blocking) the device. Only arts-aware applications can play now through artsd another one is artsd running with alsa dmix plugin: artsd 7872 daniel 10u CHR 116,16 53295 /dev/snd/pcmC0D0p artsd 7872 daniel 11r CHR 116,33 53423 /dev/snd/timer artsd 7901 daniel mem CHR 116,16 53295 /dev/snd/pcmC0D0p artsd 7901 daniel 9u unix 0xd081f080 \ 202169 /tmp/alsa-dmix-7872-1092072347-303584 artsd 7901 daniel 10u CHR 116,16 53295 /dev/snd/pcmC0D0p Now I know that only applications can play which uses artsd as backend or which uses alsa with dmix plugin. That's my favorite configuration. Perhaps now you can find your problem with this trick. Greets, Daniel