On Wed,15.Oct.08, 17:04:27, H.S. wrote: > Having read what people posted, it appears that pulseaudio is on the > right track. In this thread, only Paul has discouraged its use and > Preston is having trouble (appears to be a hardware problem), and two > others are having a ball of a time with pa. I've had issues with sound on the machine using pa but I have reason to believe it's rather the hardware/sound drivers. I don't use it for local sound. Even if it would probably work, it is an additional level of complexity I don't really need, since all my apps work fine with alsa+dmix.
> So if it works, it is wonderful. If it doesn't, it is a pain to get
> working. Moreover, it has networked sound. So I can play a movie on my
> media PC in my home lan over at my laptop -- if I understand pa correctly.
> Now if somebody can describe the steps which are fairly reliable to
> get
> it to work on a Debian machine, I might give it another shot in the not
> too distant future when I get some time.
As usual, you should start by reading
/usr/share/doc/pulseaudio/README.Debian, but here is a quick setup:
on the server machine uncomment the line
load-module module-native-protocol-tcp
in /etc/pulse/default.pa
and run 'pulseaudio --daemonize' as a user who is a member of the
'pulse-rt' group. On the client machine copy the file .pulse-cookie to
the home of the user(s) needing network sound and create a
.pulse/clientrc with:
default-server=tcp:192.168.xx.xx
(the IP of the server of course). Then you'll have to configure each app
to use pulse.
AIUI there are ways to share the cookie using X (avoid the 'copy cookie'
step needed each time you restart pulseaudio on the server machine) and
to create a pseudo-alsa-device to reroute the sound to pulse (avoid
configuring each client app, should also work with clients that don't
support pulse).
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
signature.asc
Description: Digital signature
