[pulseaudio-discuss] How to redirect pulse audio through ssh?

Discussion:

Quinn Plattel

2011-05-20 14:52:01 UTC

Hi,

I am currently trying to attempt to redirect pulse audio sound from a server
to a client through ssh. I am bit unclear on what the correct way is of
doing it.
Some guides on the net refer to paprefs and some refer to socat and others
again refer to loading modules via pactl. There is also something about
using libpulse to get it automatically setup via X11 forwarding under ssh.
I have tried different solutions without success so far.

The server is running Ubuntu Linux 10.04 without a physical sound card
installed.
The client is running Maemo Linux Fremantle with a physical sound card
installed. Client audio has been tested and confirmed working.

paprefs does exist on the server but not on the client. Pulseaudio on the
client seems not to be configured with "per-user" sessions. Pulseaudio on
the server is configured for "per-user" sessions. The pulse socket on the
client is on /var/run/pulse/native.

The server's /etc/pulse/client.conf looks like this:
-----------------------------------------------------
; default-sink =
; default-source =
; default-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually
64 MiB
-----------------------------------------------------

One question: when modifying the pulse configuration via paprefs, what files
does it modify?

Anyways, what is the easiest method to get pulse audio on a server
redirected to the client using ssh?

qiet72
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110520/efa1a174/attachment.htm>

Colin Guthrie

2011-05-20 15:48:11 UTC

Permalink

Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from a
server to a client through ssh. I am bit unclear on what the correct
way is of doing it.

Firstly, I wrote up how our X11 piggy backing stuff work here:

http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/

Technically we do not tunnel over SSH directly (this can of course be
done, but not automatically as SSH does not know about PA in the same
way it knows about X11). We can however piggy back on the X11 forwarding
built into SSH for our authentication (cookie) and server connection
strings.

If this is on a private network (direct routing) then the built in way
is the best, but it doesn't go over SSH. You just need to ensure the
machine you're sshing from has the netwrok protocol module loaded into
PA (pactl load-module module-protocol-native-tcp, or put it in your
default.pa) and make sure port 4713/tcp is open for external connections.

Also ensure that module-x11-publish is loaded on the client side and you
should get some interesting results from "xprop -root | grep PULSE".

Then when you ssh with x11 forwarding running the xprop command on the
remote machine should show you the same results.

If you cannot use the direct connection, just setup TCP tunnels in your
SSH config and then hack the PULSE_SERVER property or env var on the
remote machine to point to e.g. localhost:4713 which will actually be a
tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE
stuff already forwarded should be enough for auth.

For debugging connections:

PULSE_LOG=99 pactl stat

This shows you e.g. the server name it's trying to connect to etc.

Hope that helps (although I wrote it really quick so apologies if it
doesn't! I'll clarify later if needs be :D)

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

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/]

Quinn Plattel

2011-05-20 16:45:33 UTC

Permalink

HI,

Thanks for info, but I don't think it is the solution I am interested in. I
have to use ssh as my server is behind a firewall
and ssh is the only way to contact it. The other thing is I would like to
use vnc to work with my server.

Right now, I am doing this:

client: ssh -L 5901:localhost:5901 user at server
client: vncviewer localhost:5901

Of course vnc, does not support sound so I was hoping that I can use ssh
tunnels to redirect the sound somehow.

I did some "xprop -root|grep PULSE" tests. If I ssh to my server from an
Ubuntu Linux machine, then I can see four PULSE variables in use.
If I do the xprop test from Maemo Linux, then it shows no PULSE variables.
If I ssh from there to my server with the -X parameter, then there is also
no PULSE variables shown.
I can confirm that pulseaudio is working on Maemo by doing a "mplayer -ao
pulse some-sound-file.wav"

br,
Quinn

Post by Colin Guthrie
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from a
server to a client through ssh. I am bit unclear on what the correct
way is of doing it.

http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/
Technically we do not tunnel over SSH directly (this can of course be
done, but not automatically as SSH does not know about PA in the same
way it knows about X11). We can however piggy back on the X11 forwarding
built into SSH for our authentication (cookie) and server connection
strings.
If this is on a private network (direct routing) then the built in way
is the best, but it doesn't go over SSH. You just need to ensure the
machine you're sshing from has the netwrok protocol module loaded into
PA (pactl load-module module-protocol-native-tcp, or put it in your
default.pa) and make sure port 4713/tcp is open for external connections.
Also ensure that module-x11-publish is loaded on the client side and you
should get some interesting results from "xprop -root | grep PULSE".
Then when you ssh with x11 forwarding running the xprop command on the
remote machine should show you the same results.
If you cannot use the direct connection, just setup TCP tunnels in your
SSH config and then hack the PULSE_SERVER property or env var on the
remote machine to point to e.g. localhost:4713 which will actually be a
tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE
stuff already forwarded should be enough for auth.
PULSE_LOG=99 pactl stat
This shows you e.g. the server name it's trying to connect to etc.
Hope that helps (although I wrote it really quick so apologies if it
doesn't! I'll clarify later if needs be :D)
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

--
Best regards/Med venlig hilsen,
Quinn Plattel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110520/6ed499f5/attachment.htm>

Quinn Plattel

2011-05-20 16:58:54 UTC

Permalink

Hi,

This is interesting:

client: ssh -XL 4713:localhost:4713 user at server
server: PULSE_LOG=99 pactl stat
----------------------------------------
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
/home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: yes
Currently in use: 1 blocks containing 63.9 KiB bytes total.
Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes
total.
Sample cache size: 0 B
User name: quinn
Host Name: server
Server Name: pulseaudio
Server Version: 0.9.21-63-gd3efa-dirty
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 6ccbf517
----------------------------------------
server: export PULSE_SERVER=localhost:4713
server: PULSE_LOG=99 pactl stat
---------------------------------------
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...
connect(): Connection refused
Connection failure: Connection refused
---------------------------------------

Ideas?

Quinn

Post by Colin Guthrie
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from a
server to a client through ssh. I am bit unclear on what the correct
way is of doing it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110520/40169c07/attachment.htm>

Quinn Plattel

2011-05-20 17:01:57 UTC

Permalink

Here is pactl stat on the client side:

PULSE_LOG=99 pactl stat
-------------------------------------------------
Using private memory pool with 1024 slots of size 16,0 KiB each, total size
is 16,0 MiB, maximum usable slot size is 16344
Trying to connect to
/home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native...
connect(): No such file or directory (2)
Trying to connect to /var/run/pulse/native...
SHM possible: no
Protocol version: remote 16, local 16
Negotiated SHM: no
Currently in use: 1 blocks containing 16,0 KiB bytes total.
Allocated during whole lifetime: 263989 blocks containing 231,3 MiB bytes
total.
Sample cache size: 0 B
User name: pulse
Host Name: Nokia-N900
Server Name: pulseaudio
Server Version: 0.9.15
Default Sample Specification: s16le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: sink.music
Default Source: source.record
Cookie: 26e54bb2
-------------------------------------------------

br,
Quinn

Post by Quinn Plattel
Hi,
client: ssh -XL 4713:localhost:4713 user at server
server: PULSE_LOG=99 pactl stat
----------------------------------------
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
/home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: yes
Currently in use: 1 blocks containing 63.9 KiB bytes total.
Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes
total.
Sample cache size: 0 B
User name: quinn
Host Name: server
Server Name: pulseaudio
Server Version: 0.9.21-63-gd3efa-dirty
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 6ccbf517
----------------------------------------
server: export PULSE_SERVER=localhost:4713
server: PULSE_LOG=99 pactl stat
---------------------------------------
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...
connect(): Connection refused
Connection failure: Connection refused
---------------------------------------
Ideas?
Quinn

Post by Colin Guthrie
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from a
server to a client through ssh. I am bit unclear on what the correct
way is of doing it.

Fred Frigerio

2011-05-20 17:15:56 UTC

Permalink

Have you tried redirecting the port in SSH? Then you get the native PA with
SSH. I am not sure if there is some standard port.

Fred Frigerio

Post by Colin Guthrie
PULSE_LOG=99 pactl stat
-------------------------------------------------
Using private memory pool with 1024 slots of size 16,0 KiB each, total size
is 16,0 MiB, maximum usable slot size is 16344
Trying to connect to
/home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native...
connect(): No such file or directory (2)
Trying to connect to /var/run/pulse/native...
SHM possible: no
Protocol version: remote 16, local 16
Negotiated SHM: no
Currently in use: 1 blocks containing 16,0 KiB bytes total.
Allocated during whole lifetime: 263989 blocks containing 231,3 MiB bytes
total.
Sample cache size: 0 B
User name: pulse
Host Name: Nokia-N900
Server Name: pulseaudio
Server Version: 0.9.15
Default Sample Specification: s16le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: sink.music
Default Source: source.record
Cookie: 26e54bb2
-------------------------------------------------
br,
Quinn

Post by Colin Guthrie
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from a
server to a client through ssh. I am bit unclear on what the correct
way is of doing it.

http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/
Technically we do not tunnel over SSH directly (this can of course be
done, but not automatically as SSH does not know about PA in the same
way it knows about X11). We can however piggy back on the X11 forwarding
built into SSH for our authentication (cookie) and server connection
strings.
If this is on a private network (direct routing) then the built in way
is the best, but it doesn't go over SSH. You just need to ensure the
machine you're sshing from has the netwrok protocol module loaded into
PA (pactl load-module module-protocol-native-tcp, or put it in your
default.pa) and make sure port 4713/tcp is open for external
connections.
Also ensure that module-x11-publish is loaded on the client side and you
should get some interesting results from "xprop -root | grep PULSE".
Then when you ssh with x11 forwarding running the xprop command on the
remote machine should show you the same results.
If you cannot use the direct connection, just setup TCP tunnels in your
SSH config and then hack the PULSE_SERVER property or env var on the
remote machine to point to e.g. localhost:4713 which will actually be a
tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE
stuff already forwarded should be enough for auth.
PULSE_LOG=99 pactl stat
This shows you e.g. the server name it's trying to connect to etc.
Hope that helps (although I wrote it really quick so apologies if it
doesn't! I'll clarify later if needs be :D)
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

--
Best regards/Med venlig hilsen,
Quinn Plattel
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110520/734d6b5f/attachment.htm>

Quinn Plattel

2011-05-21 08:31:53 UTC

Permalink

Hi,

From what Colin says, the standard port is 4713 for pulseaudio. As I said

before all network ports are blocked except port 22 which is only for ssh
connections.
I should be able to tunnel port 4713 through ssh by doing this: "ssh -L
4713:localhost:4713 user at server". Then I can tell pulseaudio to use the
servers local port 4713 which is automatically forwarded to the client's
local port 4713. But from what "pactl stat" command is telling me, then
port 4713 on the client side seems to be blocked as it is giving a
"connection refused". I know the tunnelling works with ssh because I use
vnc connections through ssh by "ssh -L 5901:localhost:5901 user at server" and
that works perfectly with my vnc client and server solution.

I am not sure if I can use "pactl load-module module-protocol-native-tcp"
together with tunnelled tcp connections. I need more details on how to
that.

btw, I can see there is something listening on port 4713 on the client when
I use the "netstat -an|grep 4713" command:
---------------------------------------------------------
tcp 0 0 0.0.0.0:4713 0.0.0.0:* LISTEN
---------------------------------------------------------
So now the question is why does the listener process on the client not
accept pulseaudio data via the ssh tunnel?

br,
Quinn

Have you tried redirecting the port in SSH? Then you get the native PA
with SSH. I am not sure if there is some standard port.
Fred Frigerio

Post by Colin Guthrie
PULSE_LOG=99 pactl stat
-------------------------------------------------
Using private memory pool with 1024 slots of size 16,0 KiB each, total
size is 16,0 MiB, maximum usable slot size is 16344
Trying to connect to
/home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native...
connect(): No such file or directory (2)
Trying to connect to /var/run/pulse/native...
SHM possible: no
Protocol version: remote 16, local 16
Negotiated SHM: no
Currently in use: 1 blocks containing 16,0 KiB bytes total.
Allocated during whole lifetime: 263989 blocks containing 231,3 MiB bytes
total.
Sample cache size: 0 B
User name: pulse
Host Name: Nokia-N900
Server Name: pulseaudio
Server Version: 0.9.15
Default Sample Specification: s16le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: sink.music
Default Source: source.record
Cookie: 26e54bb2
-------------------------------------------------
br,
Quinn

Post by Quinn Plattel
Hi,
client: ssh -XL 4713:localhost:4713 user at server
server: PULSE_LOG=99 pactl stat
----------------------------------------
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
/home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: yes
Currently in use: 1 blocks containing 63.9 KiB bytes total.
Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes
total.
Sample cache size: 0 B
User name: quinn
Host Name: server
Server Name: pulseaudio
Server Version: 0.9.21-63-gd3efa-dirty
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 6ccbf517
----------------------------------------
server: export PULSE_SERVER=localhost:4713
server: PULSE_LOG=99 pactl stat
---------------------------------------
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...
connect(): Connection refused
Connection failure: Connection refused
---------------------------------------
Ideas?
Quinn

Post by Colin Guthrie
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from a
server to a client through ssh. I am bit unclear on what the correct
way is of doing it.

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Quinn Plattel

2011-05-21 08:53:55 UTC

Permalink

Hi,

I found this message when I am trying to tunnel 4713 via ssh "ssh -L
4713:localhost:4713 user at server":
------------------------------------------------------------
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 4713
Could not request local forwarding.
------------------------------------------------------------

BUT, this seems to work "ssh -R 4713:localhost:4713 user at server" (notice the
"-R" parameter)

So, it seems the forwarding direction has some say in this. Forwarding from
local to remote is not the right way, but forwarding from remote to local is
the correct way.

"pactl stat" also seems to get a bit futher this time with the correct
tunnelling direction:
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------

So now we are down from "connection refused" to "connection failure:
connection terminated".

If I attach an strace to the pulseaudio process then this happens when
"pactl stat" tries to connect to it remotely:
---------------------------------------------------------------------------
Process 1075 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
accept(57, 0, NULL) = 66
fcntl64(66, F_GETFD) = 0
fcntl64(66, F_SETFD, FD_CLOEXEC) = 0
setsockopt(57, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
setsockopt(57, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(57, SOL_IP, IP_TOS, [16], 4) = 0
fcntl64(66, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(66, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fstat64(66, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
getpeername(66, {sa_family=AF_INET, sin_port=htons(54205),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getpeername(66, {sa_family=AF_INET, sin_port=htons(54205),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
setsockopt(66, SOL_SOCKET, SO_RCVBUF, [16344], 4) = 0
setsockopt(66, SOL_SOCKET, SO_SNDBUF, [16344], 4) = 0
getsockname(66, {sa_family=AF_INET, sin_port=htons(4713),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
open("/proc/0/cmdline", O_RDONLY) = -1 ENOENT (No such file or
directory)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbed12ef4) = -1 ENOTTY
(Inappropriate ioctl for device)
write(2, "E: client-ext.c: client-ext.c: Ca"..., 57) = 57
---------------------------------------------------------------------------

I am assuming the problem lies on the client side and not on the server
side. Any more ideas? How can I see what is going on with the pulseaudio
daemon when a remote client is trying to connect?

br,
Quinn

Hi,
From what Colin says, the standard port is 4713 for pulseaudio. As I said
before all network ports are blocked except port 22 which is only for ssh
connections.
I should be able to tunnel port 4713 through ssh by doing this: "ssh -L
4713:localhost:4713 user at server". Then I can tell pulseaudio to use the
servers local port 4713 which is automatically forwarded to the client's
local port 4713. But from what "pactl stat" command is telling me, then
port 4713 on the client side seems to be blocked as it is giving a
"connection refused". I know the tunnelling works with ssh because I use
vnc connections through ssh by "ssh -L 5901:localhost:5901 user at server"
and that works perfectly with my vnc client and server solution.
I am not sure if I can use "pactl load-module module-protocol-native-tcp"
together with tunnelled tcp connections. I need more details on how to
that.
btw, I can see there is something listening on port 4713 on the client when
---------------------------------------------------------
tcp 0 0 0.0.0.0:4713 0.0.0.0:* LISTEN
---------------------------------------------------------
So now the question is why does the listener process on the client not
accept pulseaudio data via the ssh tunnel?
br,
Quinn

Post by Fred Frigerio
Have you tried redirecting the port in SSH? Then you get the native PA
with SSH. I am not sure if there is some standard port.
Fred Frigerio

Post by Colin Guthrie
PULSE_LOG=99 pactl stat
-------------------------------------------------
Using private memory pool with 1024 slots of size 16,0 KiB each, total
size is 16,0 MiB, maximum usable slot size is 16344
Trying to connect to
/home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native...
connect(): No such file or directory (2)
Trying to connect to /var/run/pulse/native...
SHM possible: no
Protocol version: remote 16, local 16
Negotiated SHM: no
Currently in use: 1 blocks containing 16,0 KiB bytes total.
Allocated during whole lifetime: 263989 blocks containing 231,3 MiB bytes
total.
Sample cache size: 0 B
User name: pulse
Host Name: Nokia-N900
Server Name: pulseaudio
Server Version: 0.9.15
Default Sample Specification: s16le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: sink.music
Default Source: source.record
Cookie: 26e54bb2
-------------------------------------------------
br,
Quinn

Post by Quinn Plattel
Hi,
client: ssh -XL 4713:localhost:4713 user at server
server: PULSE_LOG=99 pactl stat
----------------------------------------
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
/home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: yes
Currently in use: 1 blocks containing 63.9 KiB bytes total.
Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes
total.
Sample cache size: 0 B
User name: quinn
Host Name: server
Server Name: pulseaudio
Server Version: 0.9.21-63-gd3efa-dirty
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 6ccbf517
----------------------------------------
server: export PULSE_SERVER=localhost:4713
server: PULSE_LOG=99 pactl stat
---------------------------------------
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...
connect(): Connection refused
Connection failure: Connection refused
---------------------------------------
Ideas?
Quinn

Post by Colin Guthrie
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from a
server to a client through ssh. I am bit unclear on what the correct
way is of doing it.

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

--
Best regards/Med venlig hilsen,
Quinn Plattel

Quinn Plattel

2011-05-21 09:29:31 UTC

Permalink

Hi,

I finally got some more details from pulseaudio. I did this on the client:
----------------------------------
# stop pulseaudio
# pulseaudio --system --high-priority -C
----------------------------------

Now, when I run "pactl stat" on the server, pulseaudio on the client
reports:
--------------------------------------
E: client-ext.c: client-ext.c: Can't obtain command line
E: protocol-native.c: protocol error, kicking client
---------------------------------------

This is strange because pactl on the server side reports that the protocol
version is the same on both the remote and the local side:
------------------------------------------
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
------------------------------------------

Any ideas?

br,
Quinn

Post by Quinn Plattel
Hi,
I found this message when I am trying to tunnel 4713 via ssh "ssh -L
------------------------------------------------------------
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 4713
Could not request local forwarding.
------------------------------------------------------------
BUT, this seems to work "ssh -R 4713:localhost:4713 user at server" (notice
the "-R" parameter)
So, it seems the forwarding direction has some say in this. Forwarding
from local to remote is not the right way, but forwarding from remote to
local is the correct way.
"pactl stat" also seems to get a bit futher this time with the correct
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
connection terminated".
If I attach an strace to the pulseaudio process then this happens when
---------------------------------------------------------------------------
Process 1075 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
accept(57, 0, NULL) = 66
fcntl64(66, F_GETFD) = 0
fcntl64(66, F_SETFD, FD_CLOEXEC) = 0
setsockopt(57, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
setsockopt(57, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(57, SOL_IP, IP_TOS, [16], 4) = 0
fcntl64(66, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(66, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fstat64(66, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
getpeername(66, {sa_family=AF_INET, sin_port=htons(54205),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getpeername(66, {sa_family=AF_INET, sin_port=htons(54205),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
setsockopt(66, SOL_SOCKET, SO_RCVBUF, [16344], 4) = 0
setsockopt(66, SOL_SOCKET, SO_SNDBUF, [16344], 4) = 0
getsockname(66, {sa_family=AF_INET, sin_port=htons(4713),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
open("/proc/0/cmdline", O_RDONLY) = -1 ENOENT (No such file or
directory)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbed12ef4) = -1 ENOTTY
(Inappropriate ioctl for device)
write(2, "E: client-ext.c: client-ext.c: Ca"..., 57) = 57
---------------------------------------------------------------------------
I am assuming the problem lies on the client side and not on the server
side. Any more ideas? How can I see what is going on with the pulseaudio
daemon when a remote client is trying to connect?
br,
Quinn

Hi,
From what Colin says, the standard port is 4713 for pulseaudio. As I said
before all network ports are blocked except port 22 which is only for ssh
connections.
I should be able to tunnel port 4713 through ssh by doing this: "ssh -L
4713:localhost:4713 user at server". Then I can tell pulseaudio to use the
servers local port 4713 which is automatically forwarded to the client's
local port 4713. But from what "pactl stat" command is telling me, then
port 4713 on the client side seems to be blocked as it is giving a
"connection refused". I know the tunnelling works with ssh because I use
vnc connections through ssh by "ssh -L 5901:localhost:5901 user at server"
and that works perfectly with my vnc client and server solution.
I am not sure if I can use "pactl load-module module-protocol-native-tcp"
together with tunnelled tcp connections. I need more details on how to
that.
btw, I can see there is something listening on port 4713 on the client
---------------------------------------------------------
tcp 0 0 0.0.0.0:4713 0.0.0.0:*
LISTEN
---------------------------------------------------------
So now the question is why does the listener process on the client not
accept pulseaudio data via the ssh tunnel?
br,
Quinn

Post by Fred Frigerio
Have you tried redirecting the port in SSH? Then you get the native PA
with SSH. I am not sure if there is some standard port.
Fred Frigerio

Post by Colin Guthrie
PULSE_LOG=99 pactl stat
-------------------------------------------------
Using private memory pool with 1024 slots of size 16,0 KiB each, total
size is 16,0 MiB, maximum usable slot size is 16344
Trying to connect to
/home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native...
connect(): No such file or directory (2)
Trying to connect to /var/run/pulse/native...
SHM possible: no
Protocol version: remote 16, local 16
Negotiated SHM: no
Currently in use: 1 blocks containing 16,0 KiB bytes total.
Allocated during whole lifetime: 263989 blocks containing 231,3 MiB
bytes total.
Sample cache size: 0 B
User name: pulse
Host Name: Nokia-N900
Server Name: pulseaudio
Server Version: 0.9.15
Default Sample Specification: s16le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: sink.music
Default Source: source.record
Cookie: 26e54bb2
-------------------------------------------------
br,
Quinn

Post by Quinn Plattel
Hi,
client: ssh -XL 4713:localhost:4713 user at server
server: PULSE_LOG=99 pactl stat
----------------------------------------
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
/home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: yes
Currently in use: 1 blocks containing 63.9 KiB bytes total.
Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes
total.
Sample cache size: 0 B
User name: quinn
Host Name: server
Server Name: pulseaudio
Server Version: 0.9.21-63-gd3efa-dirty
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 6ccbf517
----------------------------------------
server: export PULSE_SERVER=localhost:4713
server: PULSE_LOG=99 pactl stat
---------------------------------------
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...
connect(): Connection refused
Connection failure: Connection refused
---------------------------------------
Ideas?
Quinn

Post by Quinn Plattel
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from

Post by Quinn Plattel
server to a client through ssh. I am bit unclear on what the

correct

Post by Quinn Plattel
way is of doing it.

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

--
Best regards/Med venlig hilsen,
Quinn Plattel

Quinn Plattel

2011-05-21 15:14:01 UTC

Permalink

Hi,

Some more attempts. I have now tried this:
client (session 1): stop pulseaudio
client (session 1): pulseaudio --system --high-priority -C

client (session 2): ssh -R 4000:localhost:4000 user at server
client (session 3): socat TCP-LISTEN:4000,fork
UNIX-CONNECT:/var/run/pulse/native

server: export PULSE_SERVER=localhost:4000
server: pactl stat

client (session 1) response (pulseaudio): E: protocol-native.c: protocol
error, kicking client

"protocol error" - how can we go deeper to debug the problem?

Pulseaudio version information:
server: 0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu14
client: 0.9.15-1maemo43+0m5

client pulseaudio modules loaded (pactl list|grep "Name: module")
-----------------------------------------------
Name: module-native-protocol-unix
Name: module-simple-protocol-unix
Name: module-stream-restore
Name: module-rescue-streams
Name: module-suspend-on-idle
Name: module-augment-properties
Name: module-null-sink
Name: module-alsa-sink-old
Name: module-alsa-sink-volume
Name: module-alsa-source-old
Name: module-nokia-voice
Name: module-nokia-music
Name: module-nokia-record
Name: module-alsa-sink-old
Name: module-alsa-source-old
Name: module-bluetooth-discover
Name: module-combine
Name: module-esound-protocol-unix
Name: module-native-protocol-tcp
Name: module-policy-enforcement
Name: module-match
Name: module-cli
-----------------------------------------------

br,
Quinn

Post by Quinn Plattel
Hi,
----------------------------------
# stop pulseaudio
# pulseaudio --system --high-priority -C
----------------------------------
Now, when I run "pactl stat" on the server, pulseaudio on the client
--------------------------------------
E: client-ext.c: client-ext.c: Can't obtain command line
E: protocol-native.c: protocol error, kicking client
---------------------------------------
This is strange because pactl on the server side reports that the protocol
------------------------------------------
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
------------------------------------------
Any ideas?
br,
Quinn

Hi,
From what Colin says, the standard port is 4713 for pulseaudio. As I
said before all network ports are blocked except port 22 which is only for
ssh connections.
I should be able to tunnel port 4713 through ssh by doing this: "ssh -L
4713:localhost:4713 user at server". Then I can tell pulseaudio to use the
servers local port 4713 which is automatically forwarded to the client's
local port 4713. But from what "pactl stat" command is telling me, then
port 4713 on the client side seems to be blocked as it is giving a
"connection refused". I know the tunnelling works with ssh because I use
vnc connections through ssh by "ssh -L 5901:localhost:5901 user at server"
and that works perfectly with my vnc client and server solution.
I am not sure if I can use "pactl load-module module-protocol-native-tcp"
together with tunnelled tcp connections. I need more details on how to
that.
btw, I can see there is something listening on port 4713 on the client
---------------------------------------------------------
tcp 0 0 0.0.0.0:4713 0.0.0.0:*
LISTEN
---------------------------------------------------------
So now the question is why does the listener process on the client not
accept pulseaudio data via the ssh tunnel?
br,
Quinn

Post by Fred Frigerio
Have you tried redirecting the port in SSH? Then you get the native PA
with SSH. I am not sure if there is some standard port.
Fred Frigerio

Post by Colin Guthrie
PULSE_LOG=99 pactl stat
-------------------------------------------------
Using private memory pool with 1024 slots of size 16,0 KiB each, total
size is 16,0 MiB, maximum usable slot size is 16344
Trying to connect to
/home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native...
connect(): No such file or directory (2)
Trying to connect to /var/run/pulse/native...
SHM possible: no
Protocol version: remote 16, local 16
Negotiated SHM: no
Currently in use: 1 blocks containing 16,0 KiB bytes total.
Allocated during whole lifetime: 263989 blocks containing 231,3 MiB
bytes total.
Sample cache size: 0 B
User name: pulse
Host Name: Nokia-N900
Server Name: pulseaudio
Server Version: 0.9.15
Default Sample Specification: s16le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: sink.music
Default Source: source.record
Cookie: 26e54bb2
-------------------------------------------------
br,
Quinn

Post by Quinn Plattel
Hi,
client: ssh -XL 4713:localhost:4713 user at server
server: PULSE_LOG=99 pactl stat
----------------------------------------
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
/home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: yes
Currently in use: 1 blocks containing 63.9 KiB bytes total.
Allocated during whole lifetime: 15741 blocks containing 81.5 MiB
bytes total.
Sample cache size: 0 B
User name: quinn
Host Name: server
Server Name: pulseaudio
Server Version: 0.9.21-63-gd3efa-dirty
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 6ccbf517
----------------------------------------
server: export PULSE_SERVER=localhost:4713
server: PULSE_LOG=99 pactl stat
---------------------------------------
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...
connect(): Connection refused
Connection failure: Connection refused
---------------------------------------
Ideas?
Quinn

Post by Quinn Plattel
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound from

Post by Quinn Plattel
server to a client through ssh. I am bit unclear on what the

correct

Post by Quinn Plattel
way is of doing it.

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

--
Best regards/Med venlig hilsen,
Quinn Plattel

Quinn Plattel

2011-05-21 16:47:02 UTC

Permalink

Hi,

I did a "LANG=C pulseaudio --system --high-priority -vvvv

/root/pulseverbose.log 2>&1" on the client to write a detailed log file.

Here is the results when the remote client tries to connect:
-----------------------------------------------------------------
I: client.c: Created 9 "Native client (TCP/IP client from 127.0.0.1:50604)"
I: protocol-native.c: Client authenticated anonymously.
E: client-ext.c: client-ext.c: Can't obtain command line
D: client-ext.c: new/modified client (idx=9) (Native client (TCP/IP client
from 127.0.0.1:50604)|<noid>|0|0|<noexe>|<noarg>|<noargs>)
D: protocol-native.c: Protocol version: remote 16, local 16
D: protocol-native.c: SHM possible: no
D: protocol-native.c: Negotiated SHM: no
E: protocol-native.c: protocol error, kicking client
I: client.c: Freed 9 "Native client (TCP/IP client from 127.0.0.1:50604)"
D: client-ext.c: client removed (idx=9)
-----------------------------------------------------------------

Still have not got further to solving the "protocol error" problem. Maybe
something to do with SHM?

br,
Quinn

Hi,
client (session 1): stop pulseaudio
client (session 1): pulseaudio --system --high-priority -C
client (session 2): ssh -R 4000:localhost:4000 user at server
client (session 3): socat TCP-LISTEN:4000,fork
UNIX-CONNECT:/var/run/pulse/native
server: export PULSE_SERVER=localhost:4000
server: pactl stat
client (session 1) response (pulseaudio): E: protocol-native.c: protocol
error, kicking client
"protocol error" - how can we go deeper to debug the problem?
server: 0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu14
client: 0.9.15-1maemo43+0m5
client pulseaudio modules loaded (pactl list|grep "Name: module")
-----------------------------------------------
Name: module-native-protocol-unix
Name: module-simple-protocol-unix
Name: module-stream-restore
Name: module-rescue-streams
Name: module-suspend-on-idle
Name: module-augment-properties
Name: module-null-sink
Name: module-alsa-sink-old
Name: module-alsa-sink-volume
Name: module-alsa-source-old
Name: module-nokia-voice
Name: module-nokia-music
Name: module-nokia-record
Name: module-alsa-sink-old
Name: module-alsa-source-old
Name: module-bluetooth-discover
Name: module-combine
Name: module-esound-protocol-unix
Name: module-native-protocol-tcp
Name: module-policy-enforcement
Name: module-match
Name: module-cli
-----------------------------------------------
br,
Quinn

Post by Quinn Plattel
Hi,
I found this message when I am trying to tunnel 4713 via ssh "ssh -L
------------------------------------------------------------
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 4713
Could not request local forwarding.
------------------------------------------------------------
BUT, this seems to work "ssh -R 4713:localhost:4713 user at server" (notice
the "-R" parameter)
So, it seems the forwarding direction has some say in this. Forwarding
from local to remote is not the right way, but forwarding from remote to
local is the correct way.
"pactl stat" also seems to get a bit futher this time with the correct
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
connection terminated".
If I attach an strace to the pulseaudio process then this happens when
---------------------------------------------------------------------------
Process 1075 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
accept(57, 0, NULL) = 66
fcntl64(66, F_GETFD) = 0
fcntl64(66, F_SETFD, FD_CLOEXEC) = 0
setsockopt(57, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0
setsockopt(57, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(57, SOL_IP, IP_TOS, [16], 4) = 0
fcntl64(66, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(66, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fstat64(66, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
getpeername(66, {sa_family=AF_INET, sin_port=htons(54205),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getpeername(66, {sa_family=AF_INET, sin_port=htons(54205),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
setsockopt(66, SOL_SOCKET, SO_RCVBUF, [16344], 4) = 0
setsockopt(66, SOL_SOCKET, SO_SNDBUF, [16344], 4) = 0
getsockname(66, {sa_family=AF_INET, sin_port=htons(4713),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
open("/proc/0/cmdline", O_RDONLY) = -1 ENOENT (No such file or
directory)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbed12ef4) = -1 ENOTTY
(Inappropriate ioctl for device)
write(2, "E: client-ext.c: client-ext.c: Ca"..., 57) = 57
---------------------------------------------------------------------------
I am assuming the problem lies on the client side and not on the server
side. Any more ideas? How can I see what is going on with the pulseaudio
daemon when a remote client is trying to connect?
br,
Quinn

Hi,
From what Colin says, the standard port is 4713 for pulseaudio. As I
said before all network ports are blocked except port 22 which is only for
ssh connections.
I should be able to tunnel port 4713 through ssh by doing this: "ssh -L
4713:localhost:4713 user at server". Then I can tell pulseaudio to use
the servers local port 4713 which is automatically forwarded to the client's
local port 4713. But from what "pactl stat" command is telling me, then
port 4713 on the client side seems to be blocked as it is giving a
"connection refused". I know the tunnelling works with ssh because I use
vnc connections through ssh by "ssh -L 5901:localhost:5901 user at server"
and that works perfectly with my vnc client and server solution.
I am not sure if I can use "pactl load-module
module-protocol-native-tcp" together with tunnelled tcp connections. I need
more details on how to that.
btw, I can see there is something listening on port 4713 on the client
---------------------------------------------------------
tcp 0 0 0.0.0.0:4713 0.0.0.0:*
LISTEN
---------------------------------------------------------
So now the question is why does the listener process on the client not
accept pulseaudio data via the ssh tunnel?
br,
Quinn

Post by Fred Frigerio
Have you tried redirecting the port in SSH? Then you get the native PA
with SSH. I am not sure if there is some standard port.
Fred Frigerio

Post by Colin Guthrie
PULSE_LOG=99 pactl stat
-------------------------------------------------
Using private memory pool with 1024 slots of size 16,0 KiB each, total
size is 16,0 MiB, maximum usable slot size is 16344
Trying to connect to
/home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native...
connect(): No such file or directory (2)
Trying to connect to /var/run/pulse/native...
SHM possible: no
Protocol version: remote 16, local 16
Negotiated SHM: no
Currently in use: 1 blocks containing 16,0 KiB bytes total.
Allocated during whole lifetime: 263989 blocks containing 231,3 MiB
bytes total.
Sample cache size: 0 B
User name: pulse
Host Name: Nokia-N900
Server Name: pulseaudio
Server Version: 0.9.15
Default Sample Specification: s16le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: sink.music
Default Source: source.record
Cookie: 26e54bb2
-------------------------------------------------
br,
Quinn

Post by Quinn Plattel
Hi,
client: ssh -XL 4713:localhost:4713 user at server
server: PULSE_LOG=99 pactl stat
----------------------------------------
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
/home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native...
SHM possible: yes
Protocol version: remote 16, local 16
Negotiated SHM: yes
Currently in use: 1 blocks containing 63.9 KiB bytes total.
Allocated during whole lifetime: 15741 blocks containing 81.5 MiB
bytes total.
Sample cache size: 0 B
User name: quinn
Host Name: server
Server Name: pulseaudio
Server Version: 0.9.21-63-gd3efa-dirty
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: auto_null
Default Source: auto_null.monitor
Cookie: 6ccbf517
----------------------------------------
server: export PULSE_SERVER=localhost:4713
server: PULSE_LOG=99 pactl stat
---------------------------------------
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...
connect(): Connection refused
Connection failure: Connection refused
---------------------------------------
Ideas?
Quinn
On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie <gmane at colin.guthr.ie

Post by Quinn Plattel
Hi,

Post by Quinn Plattel
I am currently trying to attempt to redirect pulse audio sound

from a

Post by Quinn Plattel
server to a client through ssh. I am bit unclear on what the

correct

Post by Quinn Plattel
way is of doing it.

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

--
Best regards/Med venlig hilsen,
Quinn Plattel

Colin Guthrie

2011-05-21 17:58:28 UTC

Permalink

Hi,

I think you're maybe getting a little confused by client and server in
terms of how things work here (perhaps not, as I've not thoroughly read
all the many posts in this thread).

As I know how to do what you want to do, I'll just write the
instructions here:

1. Start of on the machine you want to hear the sound on. This will be
your local terminal. It's the "server" in this case as it's running the
PulseAudio server. You do not need to run a PulseAudio server on the
other machine, just use the PulseAudio client library for audio (either
directly or via alsa-pulse plugin).

2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure
this has some output. If it does not then chances are the
"start-pulseaudio-x11" script was not run at login (or you have
restarted your PA server after logging in). Try just running
"start-pulseaudio-x11" and see if that fixes it.

3. Ensure that the tcp native protocol module is loaded. "pacmd
list-modules | grep module-native-protocol-tcp" If it is not loaded,
then simply type: "pactl load-module module-native-protocol-tcp"

4. SSH to your other machine: ssh -X -R4713:localhost:4713 OTHERMACHINE

If you get a warning:
Warning: remote port forwarding failed for listen port 4713
then chances are there is a PA daemon running there already, or you've
SSH'ed twice. If the former, just change the *first* instance of 4713 to
a random number of your choice (>1024).

5. On this remote machine, check your cookie is available via the xprop
command show in step 2. If X11 forwarding is working properly, it should
show up fine.

6. Set the PULSE_SERVER variable to the forwarded tunnel port.
export PULSE_SERVER=localhost:4713
(or the port number you picked in step 4 if different)

7. Confirm it's all working: PULSE_LOG=99 pactl stat

Done!!

So in this setup, the cookie used for authentication is forwarded
automatically via piggy backing on to X11 connections but as you cannot
connect directly to the machine we've had to override the PULSE_SERVER
variable to go over the SSH tunnel.

Below is the output from my session where I run these exact commands
(note the host name in the pactl stat at the end).

HTHs

Col

[colin at jimmy ~]$ hostname
jimmy
[colin at jimmy ~]$ xprop -root | grep PULSE_COOKIE
PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9......"
[colin at jimmy ~]$ pacmd list-modules | grep module-native-protocol-tcp
name: <module-native-protocol-tcp>
[colin at jimmy ~]$ ssh -X -R 5555:localhost:4713 mediacentre
Last login: Sat May 21 18:51:40 2011 from jimmy.local
[media@(Media)centre ~]$ xprop -root | grep PULSE_COOKIE
PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9......"
[media@(Media)centre ~]$ export PULSE_SERVER=localhost:5555
[media@(Media)centre ~]$ PULSE_LOG=99 pactl stat
Using shared memory pool with 1024 slots of size 64.0 KiB each, total
size is 64.0 MiB, maximum usable slot size is 65496
Trying to connect to localhost:5555...
SHM possible: no
Protocol version: remote 21, local 16
Negotiated SHM: no
Currently in use: 2 blocks containing 149.9 KiB bytes total.
Allocated during whole lifetime: 1220055 blocks containing 1.6 GiB bytes
total.
Sample cache size: 86.0 KiB
User name: colin
Host Name: jimmy
Server Name: pulseaudio
Server Version: 1.0.0-0.354.1.csg1
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_00_1b.0.analog-stereo
Default Source: alsa_input.pci-0000_00_1b.0.analog-stereo
Cookie: d7756be2
[media@(Media)centre ~]$
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

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/]

Quinn Plattel

2011-05-22 14:49:54 UTC

Permalink

Hi,

Here are my results....

Post by Colin Guthrie
Hi,
I think you're maybe getting a little confused by client and server in
terms of how things work here (perhaps not, as I've not thoroughly read
all the many posts in this thread).

You are right. I used the terminology because of the way I am ssh'ing from
and to.

2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure

Post by Colin Guthrie
this has some output. If it does not then chances are the
"start-pulseaudio-x11" script was not run at login (or you have
restarted your PA server after logging in). Try just running
"start-pulseaudio-x11" and see if that fixes it.

"xprop -root | grep PULSE_COOKIE" does not turn up any results on the local
sound server or on the remote sound client side
"dpkg -L pulseaudio | grep start-pulseaudio-x11" does not turn up any
results on the local sound server side but
it does turn up results on the remote sound client side.

Post by Colin Guthrie
3. Ensure that the tcp native protocol module is loaded. "pacmd
list-modules | grep module-native-protocol-tcp" If it is not loaded,
then simply type: "pactl load-module module-native-protocol-tcp"

pacmd gives the error "No PulseAudio daemon running, or not running as
session daemon." on the local sound server side but
I managed to get around this by:
# stop pulseaudio
# pulseaudio --system --high-priority -C

and then at the pulseaudio command line: list-modules
Here is the module:
-------------------------------
index: 18
name: <module-native-protocol-tcp>
argument: <auth-anonymous=1>
used: -1
load once: no
properties:
module.author = "Lennart Poettering"
module.description = "Native protocol (TCP sockets)"
module.version = "0.9.15"
-------------------------------

Post by Colin Guthrie
4. SSH to your other machine: ssh -X -R4713:localhost:4713 OTHERMACHINE
Warning: remote port forwarding failed for listen port 4713
then chances are there is a PA daemon running there already, or you've
SSH'ed twice. If the former, just change the *first* instance of 4713 to
a random number of your choice (>1024).

No problems there.

Post by Colin Guthrie
5. On this remote machine, check your cookie is available via the xprop
command show in step 2. If X11 forwarding is working properly, it should
show up fine.

"xprop -root | grep PULSE_COOKIE" does not give any results on the remote
machine.

Post by Colin Guthrie
6. Set the PULSE_SERVER variable to the forwarded tunnel port.
export PULSE_SERVER=localhost:4713
(or the port number you picked in step 4 if different)
7. Confirm it's all working: PULSE_LOG=99 pactl stat

-----------------------------------------
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
-----------------------------------------

Results on the local sound server side:
------------------------------------------
E: protocol-native.c: protocol error, kicking client
------------------------------------------

Post by Colin Guthrie
Done!!
So in this setup, the cookie used for authentication is forwarded
automatically via piggy backing on to X11 connections but as you cannot
connect directly to the machine we've had to override the PULSE_SERVER
variable to go over the SSH tunnel.
Below is the output from my session where I run these exact commands
(note the host name in the pactl stat at the end).
HTHs
Col
[colin at jimmy ~]$ hostname
jimmy
[colin at jimmy ~]$ xprop -root | grep PULSE_COOKIE
PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9......"
[colin at jimmy ~]$ pacmd list-modules | grep module-native-protocol-tcp
name: <module-native-protocol-tcp>
[colin at jimmy ~]$ ssh -X -R 5555:localhost:4713 mediacentre
Last login: Sat May 21 18:51:40 2011 from jimmy.local
PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9......"
Using shared memory pool with 1024 slots of size 64.0 KiB each, total
size is 64.0 MiB, maximum usable slot size is 65496
Trying to connect to localhost:5555...
SHM possible: no
Protocol version: remote 21, local 16
Negotiated SHM: no
Currently in use: 2 blocks containing 149.9 KiB bytes total.
Allocated during whole lifetime: 1220055 blocks containing 1.6 GiB bytes
total.
Sample cache size: 86.0 KiB
User name: colin
Host Name: jimmy
Server Name: pulseaudio
Server Version: 1.0.0-0.354.1.csg1
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_00_1b.0.analog-stereo
Default Source: alsa_input.pci-0000_00_1b.0.analog-stereo
Cookie: d7756be2
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Quinn Plattel

2011-05-22 18:13:55 UTC

Permalink

Hi,

I have now found a partial solution to the protocol error that happens when
I try to play sound remotely through pulse.
What I did was I played around with different versions of pulseaudio on the
remote side by using different versions of Ubuntu.
On the local server side, we are using pulseaudio 0.9.15.
Ubuntu Lucid Lynx 10.04 has version 0.9.22 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Koala Karmic 9.10 has version 0.9.19 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Jaunty Jackelope 9.04 has version 0.9.14 of pulseaudio and it works
perfectly without the "protocol error" on the local server side.

I will see if I can downgrade the version of pulseaudio in Ubuntu Lucid
Lynx.

Question: Is it possible to force pulseaudio to use an older protocol?

br,
Quinn

Post by Quinn Plattel
Hi,
Here are my results....

You are right. I used the terminology because of the way I am ssh'ing from
and to.
2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure

pacmd gives the error "No PulseAudio daemon running, or not running as
session daemon." on the local sound server side but
# stop pulseaudio
# pulseaudio --system --high-priority -C
and then at the pulseaudio command line: list-modules
-------------------------------
index: 18
name: <module-native-protocol-tcp>
argument: <auth-anonymous=1>
used: -1
load once: no
module.author = "Lennart Poettering"
module.description = "Native protocol (TCP sockets)"
module.version = "0.9.15"
-------------------------------

No problems there.

Post by Colin Guthrie
5. On this remote machine, check your cookie is available via the xprop
command show in step 2. If X11 forwarding is working properly, it should
show up fine.

"xprop -root | grep PULSE_COOKIE" does not give any results on the remote
machine.

-----------------------------------------
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
-----------------------------------------
------------------------------------------
E: protocol-native.c: protocol error, kicking client
------------------------------------------

--
Best regards/Med venlig hilsen,
Quinn Plattel

Quinn Plattel

2011-05-22 19:57:10 UTC

Permalink

Well, here is my almost perfect solution:

local sound server: ssh -L 5901:localhost:5901 -L 1234:localhost:1234
<remote sound client>
remote sound client: mkfifo output.wav
remote sound client: parec | sox -t raw -r 44100 -s -L -b 16 -c 2 -
"output.wav" & cat output.wav | nc -l 1234
local sound server: mkfifo output.wav
local sound server: paplay --volume=48000 -v fifo.wav & nc localhost 1234

fifo.wav

As you can see, I use port 5901 for VNC and port 1234 to forward sound. The
only thing is it takes at least 30 seconds before it plays on the speakers.

Any ideas why such a huge latency?

br,
Quinn

Hi,
I have now found a partial solution to the protocol error that happens when
I try to play sound remotely through pulse.
What I did was I played around with different versions of pulseaudio on the
remote side by using different versions of Ubuntu.
On the local server side, we are using pulseaudio 0.9.15.
Ubuntu Lucid Lynx 10.04 has version 0.9.22 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Koala Karmic 9.10 has version 0.9.19 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Jaunty Jackelope 9.04 has version 0.9.14 of pulseaudio and it works
perfectly without the "protocol error" on the local server side.
I will see if I can downgrade the version of pulseaudio in Ubuntu Lucid
Lynx.
Question: Is it possible to force pulseaudio to use an older protocol?
br,
Quinn

Post by Quinn Plattel
Hi,
Here are my results....

You are right. I used the terminology because of the way I am ssh'ing
from and to.
2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure

"xprop -root | grep PULSE_COOKIE" does not turn up any results on the
local sound server or on the remote sound client side
"dpkg -L pulseaudio | grep start-pulseaudio-x11" does not turn up any
results on the local sound server side but
it does turn up results on the remote sound client side.

No problems there.

Post by Colin Guthrie
5. On this remote machine, check your cookie is available via the xprop
command show in step 2. If X11 forwarding is working properly, it should
show up fine.

"xprop -root | grep PULSE_COOKIE" does not give any results on the remote
machine.

-----------------------------------------
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
-----------------------------------------
------------------------------------------
E: protocol-native.c: protocol error, kicking client
------------------------------------------

--
Best regards/Med venlig hilsen,
Quinn Plattel

Quinn Plattel

2011-05-22 19:58:36 UTC

Permalink

Hi,

Correction on the last two lines:
local sound server: mkfifo *fifo.wav*
local sound server: paplay --volume=48000 -v fifo.wav & nc localhost 1234

Post by Quinn Plattel
fifo.wav

br,
Quinn

Post by Quinn Plattel
local sound server: ssh -L 5901:localhost:5901 -L 1234:localhost:1234
<remote sound client>
remote sound client: mkfifo output.wav
remote sound client: parec | sox -t raw -r 44100 -s -L -b 16 -c 2 -
"output.wav" & cat output.wav | nc -l 1234
local sound server: mkfifo output.wav
local sound server: paplay --volume=48000 -v fifo.wav & nc localhost 1234

Post by Quinn Plattel
fifo.wav

As you can see, I use port 5901 for VNC and port 1234 to forward sound.
The only thing is it takes at least 30 seconds before it plays on the
speakers.
Any ideas why such a huge latency?
br,
Quinn

Post by Quinn Plattel
Hi,
I have now found a partial solution to the protocol error that happens
when I try to play sound remotely through pulse.
What I did was I played around with different versions of pulseaudio on
the remote side by using different versions of Ubuntu.
On the local server side, we are using pulseaudio 0.9.15.
Ubuntu Lucid Lynx 10.04 has version 0.9.22 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Koala Karmic 9.10 has version 0.9.19 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Jaunty Jackelope 9.04 has version 0.9.14 of pulseaudio and it works
perfectly without the "protocol error" on the local server side.
I will see if I can downgrade the version of pulseaudio in Ubuntu Lucid
Lynx.
Question: Is it possible to force pulseaudio to use an older protocol?
br,
Quinn

Post by Quinn Plattel
Hi,
Here are my results....

You are right. I used the terminology because of the way I am ssh'ing
from and to.
2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure

"xprop -root | grep PULSE_COOKIE" does not turn up any results on the
local sound server or on the remote sound client side
"dpkg -L pulseaudio | grep start-pulseaudio-x11" does not turn up any
results on the local sound server side but
it does turn up results on the remote sound client side.

No problems there.

Post by Colin Guthrie
5. On this remote machine, check your cookie is available via the xprop
command show in step 2. If X11 forwarding is working properly, it should
show up fine.

"xprop -root | grep PULSE_COOKIE" does not give any results on the remote
machine.

-----------------------------------------
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
-----------------------------------------
------------------------------------------
E: protocol-native.c: protocol error, kicking client
------------------------------------------

--
Best regards/Med venlig hilsen,
Quinn Plattel

Quinn Plattel

2011-05-23 04:52:35 UTC

Permalink

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.

br,
Quinn

Post by Quinn Plattel
Hi,
local sound server: mkfifo *fifo.wav*
local sound server: paplay --volume=48000 -v fifo.wav & nc localhost 1234

Post by Quinn Plattel
fifo.wav

br,
Quinn

Post by Quinn Plattel
fifo.wav

As you can see, I use port 5901 for VNC and port 1234 to forward sound.
The only thing is it takes at least 30 seconds before it plays on the
speakers.
Any ideas why such a huge latency?
br,
Quinn

Post by Quinn Plattel
Hi,
I have now found a partial solution to the protocol error that happens
when I try to play sound remotely through pulse.
What I did was I played around with different versions of pulseaudio on
the remote side by using different versions of Ubuntu.
On the local server side, we are using pulseaudio 0.9.15.
Ubuntu Lucid Lynx 10.04 has version 0.9.22 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Koala Karmic 9.10 has version 0.9.19 of pulseaudio and it gives
"protocol error" on the local server side.
Ubuntu Jaunty Jackelope 9.04 has version 0.9.14 of pulseaudio and it
works perfectly without the "protocol error" on the local server side.
I will see if I can downgrade the version of pulseaudio in Ubuntu Lucid
Lynx.
Question: Is it possible to force pulseaudio to use an older protocol?
br,
Quinn

Post by Quinn Plattel
Hi,
Here are my results....

You are right. I used the terminology because of the way I am ssh'ing
from and to.
2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure

"xprop -root | grep PULSE_COOKIE" does not turn up any results on the
local sound server or on the remote sound client side
"dpkg -L pulseaudio | grep start-pulseaudio-x11" does not turn up any
results on the local sound server side but
it does turn up results on the remote sound client side.

No problems there.

Post by Colin Guthrie
5. On this remote machine, check your cookie is available via the xprop
command show in step 2. If X11 forwarding is working properly, it should
show up fine.

"xprop -root | grep PULSE_COOKIE" does not give any results on the
remote machine.

-----------------------------------------
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
-----------------------------------------
------------------------------------------
E: protocol-native.c: protocol error, kicking client
------------------------------------------

--
Best regards/Med venlig hilsen,
Quinn Plattel

Colin Guthrie

2011-05-23 08:29:43 UTC

Permalink

Post by Quinn Plattel
HI.
Last post on this thread, then I will start a new one.
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
0.9.15....

But if you cannot work out the protocol error here, I guess you're work
around is the easiest option :s

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

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/]

Quinn Plattel

2011-05-23 16:00:05 UTC

Permalink

Hi,

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
/etc/pulse/client.conf:
default-server = localhost
cookie-file = /etc/pulse/pulse-cookie-n900
- on the remote sound client side, I made /etc/pulse/pulse-cookie-n900
permissions 644
- 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.

br,
Quinn

Post by Colin Guthrie

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
0.9.15....
But if you cannot work out the protocol error here, I guess you're work
around is the easiest option :s
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss