I tried the pulse cookie method. Here is what I did:
- on the local sound server side, I copied ~/.pulse-cookie to the remote
sound client to /etc/pulse/pulse-cookie-n900
- on the remote sound client side, I added the following two lines to
default-server = localhost
cookie-file = /etc/pulse/pulse-cookie-n900
- on the remote sound client side, I made /etc/pulse/pulse-cookie-n900
- on the local sound server side, I did a ssh -X -R 4713:localhost:4713
<remote-sound-client> "PULSE_LOG=99 pactl stat"
The following output of "pactl stat" follows:
Using shared memory pool with 1024 slots of size 64.0 KiB each, total size
is 64.0 MiB, maximum usable slot size is 65472
Trying to connect to localhost:4713...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: no
Connection failure: Connection terminated
and pulseaudio daemon reports "protocol error, kicking client"
So no luck with cookies either. I could try and upgrade pulseaudio on the
local server side, but it is going to be tricky.
On Mon, May 23, 2011 at 10:29 AM, Colin Guthrie <gm...@colin.guthr.ie>wrote:
> 'Twas brillig, and Quinn Plattel at 23/05/11 05:52 did gyre and gimble:
> > HI.
> > Last post on this thread, then I will start a new one.
> > I managed to cut down the delay considerably by simplifying the commands:
> > local sound server: ssh -L 5901:localhost 5901 -L 1234:localhost:1234
> > <remote sound client> *parec | nc -l 1234"
> > local sound server: nc localhost 1234 | pacat
> > The advantage with this is that the volume can be controlled manually
> > with the local sound server's volume control and the delay is cut down
> > to 3-5 seconds.
> The commands and procedure I outlined before is working fine and is free
> from bizarre work arounds. I'm not sure if the protocol error you are
> getting is coming form a bug in the client side or the server side, but
> either way it can be easily fixed if it's debugged appropriately.
> The lack of a cookie can be solved in several ways (e.g. by copying the
> ~/.pulse_cookie file between machines, or by setting up anonymous
> authentication when loading the TCP protocol module).
> I don't think your workaround (while creative) is the right way to go.
> Far a start parec|pacat has no dynamic sample rate adjustments to
> compensate for different clocks.
> Also with the parec command it seems you are connecting to to the remote
> PA daemon and recording from a monitor source (assuming no real source
> exists on the machine, the monitor source would be the default) so as to
> capture the sound which you then play back via pacat on the local
> system. If that's the case then you're already talking to the wrong PA
> daemon. As I said in my previous mail any client that runs on the remote
> system should connect *directly* (via SSH tunnel) to the remote PA. I'm
> sure it wouldn't take too long to work out the incompatibilities between
> the two protocol versions, but perhaps the one in Maemo has some kind of
> customisation applied on top that makes it generally incompatible?
> In general the protocol is backwards compatible and while I'd have to
> look, I'm not aware of any specific incompatibilities between 0.9.21 and
> But if you cannot work out the protocol error here, I guess you're work
> around is the easiest option :s
> Colin Guthrie
> Day Job:
> Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
> Mageia Contributor [http://www.mageia.org/]
> PulseAudio Hacker [http://www.pulseaudio.org/]
> Trac Hacker [http://trac.edgewall.org/]
> pulseaudio-discuss mailing list
Best regards/Med venlig hilsen,
pulseaudio-discuss mailing list