[pulseaudio-discuss] Apps playing through PA do not show up in pacmd or pavucontrol

[Colin Guthrie]

'Twas brillig, and Timothy J Massey at 01/07/09 06:28 did gyre and gimble:
> Hello!
> 
> I have a MPD session playing through PulseAudio.  The *only* audio_output 
> in the mpd.conf looks like this:
> 
> audio_output {
>         type "pulse"
>         name "MPD Player #1 via PulseAudio"
>         sink "mpdplayer1"
> }
> 
> I start MPD and play something, and it plays properly.  HOWEVER, 
> PulseAudio shows no evidence that MPD is actually playing through it.  For 
> example, if I use pavucontrol and display the Playback tab shows "System 
> Sounds" only.  No MPD.  Or, if I use list-sink-inputs from pacmd, it tells 
> me that there are *0* sink-inputs!

Sounds like you're running mpd as a different user and has it's own 
pulseaudio daemon process running. Your user is connecting to it's 
session of pulseaudio.

> However, it seems that MPD *is* playing throuh PA.  For example, if I use 
> pacmd to mute or change the volume of the sink, the MPD music is affected. 

That doesn't necessarily mean mpd is using pulseaudio. It just means the 
mixer that your pulse process attaches too affects the device mpd is 
playing through. It doesn't mean mpd is *not* using pulse either tho', 
so this bit is inconclusive.

>  Or, if I kill pulseaudio and restart the MPD server, it will not play, 
> and I will get an error in /var/log/mpd/errors.log saying that it could 
> not connect to the PulseAudio server.  So it *sure* seems that MPD *is* 
> playing through PA.  So why don't I see it in pacmd or pavucontrol?

This is a bit odd for sure.

I'd try and work out whether there are multiple PA's running first. Is 
mpd running as it's own user, and if so, is it a member of the "audio" 
group? If so this would bypass the ACL stuff, and allow two instances of 
pulse to run at the same time where both of them open your sound h/w. 
While this can work on some h/w (when it supports hardware mixing), the 
majority of h/w on the market will only let one process use it at a time 
(which is why sound daemons exist in some form or another: and I include 
alsa's own dmix in this classification).

After that perhaps check lsof to see what files mpd has open - make sure 
it's using the pulse libraries and indeed a pulse socket file. You can 
tell from the socket file if it's using the same PA as you.

Perhaps also it's trying to connect to your users pulseaudio and 
failing, then falling back to alsa.

It's kinda hard to say what's going on here to be honest :s

> This has happened more than once under both Ubuntu 9.04 fully-updated, and 
> Ubuntu 9.10 alpha 2, not updated.  Given the problems I've been having 
> with 9.04, I'm giving Karmic a shot:  2.6.30 kernel and PA 0.9.15.  Does 
> anyone have a suggestion for a better distro to try?  Fedora is *not* a 
> better distro:  while Ubuntu uses ~50% CPU to play a single MP3 stream 
> through PA, Fedora 11 is *choppy* and at 100% CPU for the *same* 
> *thing*...

I'd imagine Ubuntu is using the old interrupt driven mode whereas Fedora 
is using glitch free and your card's h/w driver doesn't support that. 
Compare the default.pa on each distro and see if there are any 
differences. I suspect the Ubuntu one will have tsched=0 passed to 
module-hal-detect.

In Mandriva we have a ticky box in our config utility, draksound, to 
enable or disable glitch free mode. (While the name is a bit ironic on 
some hardware due to driver issues, the term really refers to the way in 
which it works internally).

HTHs

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]