[pulseaudio-discuss] PulseAudio and Network Audio Devices

Richi Plana richip at richip.dhs.org
Wed Dec 19 09:08:00 PST 2007


On Wed, 2007-12-19 at 11:46 +0100, Lennart Poettering wrote:
> On Tue, 18.12.07 08:13, Richi Plana (richip at richip.dhs.org) wrote:
> 
> > 
> > On Mon, 2007-12-17 at 17:29 -0700, Richi Plana wrote:
> > > On Mon, 2007-12-17 at 22:54 +0100, Lennart Poettering wrote:
> > > > > I'm also noticing an oddity on the two devices. When I enabled
> > > > > Multicast/RTP sender on one machine, a virtual sink appeared on the
> > > > > Output tab. When I enabled "Simultaenouse output", the simul output
> > > > > virtual device appeared. When I did both on the other machine, neither
> > > > > virtual output device appeared. Not my main concern right now (getting
> > > > > audio to appear on a remote machine is), but I thought I'd mention the
> > > > > oddity anyway.
> > > > 
> > > > paprefs require pulseaudio-module-paprefs installed and
> > > > activated. Which should be the default. 
> > > 
> > > On the machine that I'm noticing the "no change behavior" in,
> > > pulseaudio-module-gconf is indeed installed. I guess it's not activated.
> > > How does one activate it?
> > 
> > So I've updated pulseaudio to 0.9.8 and the utils to the latest on
> > Fedora rawhide and I'm still not seeing the virtual devices for
> > SUmultaneous output and RTP Multicast Sink appearing in pavucontrol even
> > though the gconf settings are changing (as shown by gconf-editor).
> > 
> > Also, with the zeroconf module installed and configured, I'm still not
> > seeing the devices across the network.
> 
> What kind of network is this? Some WLAN? Closed-source network driver?
> They usually have trouble with multicasting. Does avahi-browse -a
> work? Does it show a service regsitered via "avahi-publish-service
> foobar _foo._tcp 4711" on another machine?

I should probably give more details about the machines and the network
now. I've three machines with PulseAudio on: viper, duke and atom.

viper is a desktop connected to the switch running F8 that was actually
a result of updating from Rawhide (as a side note: I'm also experiencing
weirdness on this machine where I'm not seeing corresponding updates in
pavucontrol whenever I add virtual output devices (see my other
message)). Network driver: forcedeth

duke is a new notebook with modern specs connected also to the switch
running F8. Network driver: forcedeth

atom is an old laptop (Pentium ///) connected via a wireless router,
which, in turn, is connected via a powerline bridge to the switch. Also
running updated F8. Network driver: ath_pci

On all three machines, I've yum updated them fairly recently and are
running PA 0.9.8 from rawhide (as well as corresponding utils).

I ran "avahi-browse -at | sort" from all three machines and got the ff.:

+ eth0 IPv4 atom [00:13:46:21:61:6a]                      _workstation._tcp    local
+ eth0 IPv4 atom                                          _ssh._tcp            local
+ eth0 IPv4 duke [00:16:d3:f1:57:33]                      _workstation._tcp    local
+ eth0 IPv4 duke                                          _ssh._tcp            local
+ eth0 IPv4 legacy [00:16:e6:1e:a0:64]                    _workstation._tcp    local
+ eth0 IPv4 richip at atom: ALSA PCM on front:0 (Maestro3) via DMA _pulse-sink._tcp     local
+ eth0 IPv4 richip at atom: ALSA PCM on front:0 (Maestro3) via DMA _pulse-source._tcp   local
+ eth0 IPv4 richip at atom                                   _pulse-server._tcp   local
+ eth0 IPv4 richip at duke: ALSA PCM on front:0 (CONEXANT Analog) via DMA _pulse-sink._tcp     local
+ eth0 IPv4 richip at duke: ALSA PCM on front:0 (CONEXANT Analog) via DMA _pulse-source._tcp   local
+ eth0 IPv4 richip at duke                                   _pulse-server._tcp   local
+ eth0 IPv4 Richi Plana                                   _h323._tcp           local
+ eth0 IPv4 Richi Plana                                   _sip._udp            local
+ eth0 IPv4 richip's public files on viper                _webdav._tcp         local
+ eth0 IPv4 SFTP File Transfer on legacy                  _sftp-ssh._tcp       local
+ eth0 IPv4 viper [00:0f:ea:73:b4:01]                     _workstation._tcp    local
+ eth0 IPv4 viper                                         _ssh._tcp            local

The only difference was that on atom, instead of e.g.
"_workstation._tcp" showing, it would display "Workstation" (and I've no
idea why since they're the same command-line arguments. Only difference
is that it's using i386 binaries as opposed to x86_64 on the others). On
all three machines, I'm not seeing remote devices in the "_Output
Devices" tab on pavucontrol (which is set to "S_how" "All Output
Devices").

I seriously think that viper (which was updated from f7-rawhide) is
seriously broken. I'm thinking of installing from scratch, but I'll
refrain from doing so in case someone wants forensic clues. Otherwise,
I'll re-install ASAP.
--

Richi Plana






More information about the pulseaudio-discuss mailing list