Comments on: Sound on Linux is Confusing: Defuzzing Part 2: PulseAudio

By: Colin

Colin — Wed, 21 Jul 2010 08:02:50 +0000

Well there are several points to answer here:
1. The term “sink” means a somewhere audio data can be pushed to. A “source” would be somewhere audio data could be pulled from. It’s the same term as used in electrical engineering and various other disciplines too. When your tool finds a “new sink” it is basically reporting that it’s found a new output device. I think the terminology is pretty accurate.
2. I would avoid the multicast stuff just now. If you don’t specifically need multicasting, it is much more efficient (and also less error prone) to leave it disabled.
3. pabrowse is just a cut down version of avahi-browse. The problem you’re basically seeing here is something that seems to be an Ubuntu bug as no other distro has reported problems and I personally use this setup on other distros and have no problems. It seems that avahi is essentially broken on Ubuntu until the network is reset or something like that. I’m not an Ubuntu user so I’m not following this, but you can find more info at the upstream bug: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/586229

So ultimately I agree with you, this is something that should work with a few mouse clicks. And for most people with working distributions it does. For folk who drink the Ubuntu Kool Aid, you’re out of luck until they deign to fix their problem.
So while I appreciate that everyone needs to rant sometimes, please save the vitriol for those that actually deserve it rather than going off at the first person you see.

By: Andrew Kane

Andrew Kane — Wed, 21 Jul 2010 03:44:27 +0000

So, it does not work for me.
I ssh into my desktop machine from my laptop. pabrowse on the laptop shows that the desktop as a “new server” and a “new sink” (surely it should be a source?), but does not terminate. Checked in paprefs is:
– Enable network access to local sound devices
– Allow other machines on the LAN to discover local sound devices
– Don’t require authentication
– Enable multicast sender
– Create separate audio device for multicast

and nothing else.

paman shows only the local server, not the remote.

Evidently it is not “discovering” the remote pulse server, I assume because pabrowser does not terminate- though I don’t know, since I can’t find anything in the sparse manpages for these various programs nor on pulseaudio.org that tells me how to troubleshoot this.

I have configured both machines to allow incoming tcp on 4713, but netstat shows no connection on that port when I attempt to run totem under ssh -XC.
I don’t understand why the various distributions that have now made Pulseaudio the default sound server have done so, since it immediately broke compatibility with so many popular applications and is in general so difficult to use.
Like many folks, I want to be able to forward sound from one machine to another without becoming an expert in a particular application. I’ve already spent years of my life learning unix skills and tcp/ip networking, and if I have to study something I’d like it to be of more general application. This is something that ought to work with a few simple mouse clicks, and it does not; the server runs Ubuntu, but I have tried this under four different distros on the client (laptop).
I’m not sure whether to blame Pulseaudio for this. Certainly Ubuntu’s implementation is incomplete by default, and Ubuntu’s documentation is lacking in this area. However, the docs at pulseaudio.org are not much better, and require more up-front knowledge than most non-audio-experts will have.

This is a problem for a lot of people, as a search of forum posts will show.
Apologies for the rant, but it is just not as easy as the article seems to indicate. I wish it were. Maybe someday it will be. But not today.

By: Colin

Colin — Tue, 04 Aug 2009 13:47:57 +0000

Fair point re alsa-info.sh… I’ll put it into a package somewhere.

By: Adam Williamson

Adam Williamson — Tue, 04 Aug 2009 05:54:00 +0000

It’s not necessarily even a ‘problem’ as such, more a not-yet-implemented feature. Jack sensing is a fairly new thing for ALSA and hasn’t been implemented for anything like all hardware that supports it, yet. Still, Colin gave the best practical advice: ask on the alsa-devel mailing list. Include the output of the alsa-info.sh script (I don’t think Mandriva includes it – Colin, you should really package it, believe me it’ll make your life easier…in the meantime, you can find copies lying around the intarwebs).

By: Sergio

Sergio — Tue, 04 Aug 2009 00:11:23 +0000

You complaints are valid, but dude, why do you blame Mandriva for this issue????

By: SEBELK FOSS » Blog Archive » El sonido en Linux es confuso: Desmitificando Parte 2: PulseAudio

Mon, 03 Aug 2009 16:33:45 +0000

[...] Lo que sigue es una traducción “quick and dirty” del segundo de dos excelentes artículos escritos por Colin Guthrie. Todo comenzó por mi intento de desentrañar la manera en que Linux maneja el audio por estos días. Luego dí con Colin Guthrie el encargado de la parte de sonido en Mandriva, el cual tuvo la amabilidad de responder varias preguntas, y al parecer todo esto fue un disparador para que él escribiera estos dos posts altamente recomendables, aquí va el primero (el original en inglés del segundo artículo se puede leer haciendo clic aquí): [...]

By: Colin

Colin — Mon, 03 Aug 2009 07:52:30 +0000

For a while now I’ve been meaning to work on a “Troubleshooting” guide that would help to identify where in the process such a problem lies. In your case I’d say that this is a problem in the ALSA driver and you should probably seek advice from the alsa-dev mailing list.

By: Colin

Colin — Mon, 03 Aug 2009 07:48:47 +0000

Pulse no longer relies on HAL or PolicyKit. PolicyKit (indirectly via RealtimeKit) will allow pulse to obtain realtime privileges, but it’s not a required component. As you said, HAL has been supplanted by udev now that it’s got it’s act in gear and is deprecating HAL more generally. DBUS, well yes there is a requirement on that and there will be even more so in the future when pulse will use DBUS as it’s primary IPC mechanism. But then again, what’s the point of having frameworks and structures in a modern desktop if we don’t use them and always implement alternatives? I say we sometimes just have to embrace these components. DBUS is just about everywhere – GNOME/KDE both make extensive use of it… I doubt it’s really that big a deal that pulse uses it too.

By: hairy t

hairy t — Mon, 03 Aug 2009 04:17:33 +0000

Thanks for the explanation. However, I have to say that these two articles still clarify nothing for me. I have full confidence that it is quite correct and indepth — I am not questioning your knowledge at all. But I feel that it’s still too esoteric for anyone but those extremely familiar with kernel or near kernel development. I am a fairly experienced linux user (more than 10 years, not afraid of modifying rc files and even have recompiled the kernel once or twice)

I’ll tell you what I was hoping to find: an explanation of why my Fujitsu laptop sound system seems to be hosed because the sound works fine but the drivers can’t seem to sense that a headphone jack has been plugged in so the sound never goes to the headsets always to the speakers. Now where on a drawing with ALSA and PulseAudio and OSS does that issue lie. Where does one start to even look? (btw this is a pretty common issue that have been reported by many with what seems no satisfactory answer.)

Perhaps a less technical explanation with more pictures of boxes and lines would be clearer?

Thank for what you do.

By: FACORAT Fabrice

FACORAT Fabrice — Sun, 02 Aug 2009 22:34:25 +0000

I don’t care about Skype, however my issue concerns pulse audio server startup. It relies on HAL+DBUS+PolicyKit. If one of those components is not working/configured correctly, then pulse audio will not start and IMHO this is not good … Especially concerning HAL ( now udev I guess which is safer ).