Am Mittwoch, 4. August 2004 09:23 schrieb Guenter Lichtenberg:

On Wednesday 04 August 2004 03:35, Marc Collin wrote:

...

hi

i can play music, mp3 without problem under kde... but i the kde control center - sound, kde notification sound system is on... but i have no sound when an event happen...

same thing for kopete... i receive a message or send one... but no sound happen

any idea?

i use suse 9.1

thanks

Hi - I had the same problem on SuSE 9.1. I solved it by - strangely enough - setting the external player to 'artsplay'. You do this by starting the control center and then going to 'Sound&Multimedia'->'System Notifications' and then push 'Player Settings' and fill in artsplay.

It is maybe a SuSE 9.1 problem, my PC at work has red-hat and there it worked without any external player (as it should).

Hope it helps gl

If you find that behavior strange, then you have deficiency in understanding the linux sound system. Nearly all sound chips can only be opened by one sound application at one time. Only exception I know are EMU10K1 based soundcards like Soundblaster 512 or Live! (and perhaps Audigy?) To get sound from two applications at one, you have to use a sound daemon like arts daemon (short artsd). This daemon opens the sound device and listens for connections from arts aware applications. These can connect to arts daemon and give it the sound stream. Artsd after that looks if any other application is playing, too and if neccessary it mixes all sound streams and then sends the one mixed sound stream to the soundcard. Artsd releases the sound device when not used for some seconds. Then you can open your music player and start playing. If after that an arts-aware app will play sound, it gives sound to artsd, but this time artsd cannot open the device. It's blocked by the music player. So one solution is to get the music player arts-aware, too. Examples are the arts plugin for xmms. Another aproach is more difficult, but it works better, because it has no noticable latency (the time between application starts playing and the time the sound comes out of your boxes). You can choose to use alsa as backend for anything. Configure alsa to use the dmix plugin (http://alsa.opensrc.org/index.php?page=DmixPlugin). This does the software mixing like artsd, but it does it somehow better and faster. If someone is in need for further explanation, then ask here on this list. After that, configure arts to use alsa as backend. If asound.conf is configured right, it qill use the alsa dmix plugin. After that try to switch all other sound applications to use native alsa, too. This works wonderful with apps like xine, mplayer, xmms and if you use the aoss libraries with LD_PRELOAD (I can explain this further, too), then you even can get mozilla, opera and helixplayer / realplayer to use alsa with dmix plugin, too. So, thanks for reading this biiiig mail and I hope I could give some light into this ever repeating question. Greets, Daniel

On Wednesday 04 August 2004 18:59, Daniel Eckl wrote:

So, thanks for reading this biiiig mail and I hope I could give some light into this ever repeating question.

Thank you for an excellent explanation! Cheers, Frits

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? ;) Daniel

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