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

2011-05-21 Thread Quinn Plattel
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@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@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:
-
tcp0  0 0.0.0.0:47130.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



On Fri, May 20, 2011 at 7:15 PM, Fred Frigerio ffrige...@frigerio.uswrote:

 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




 On Fri, May 20, 2011 at 1:01 PM, Quinn Plattel qie...@gmail.com wrote:

 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


 On Fri, May 20, 2011 at 6:58 PM, Quinn Plattel qie...@gmail.com wrote:

 Hi,

 This is interesting:

 client: ssh -XL 4713:localhost:4713 user@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 gm...@colin.guthr.iewrote:

 Hi,

 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and gimble:
  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 

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

2011-05-21 Thread Quinn Plattel
Hi,

I found this message when I am trying to tunnel 4713 via ssh ssh -L
4713:localhost:4713 user@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@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

On Sat, May 21, 2011 at 10:31 AM, Quinn Plattel qie...@gmail.com wrote:

 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@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@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:
 -
 tcp0  0 0.0.0.0:47130.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




 On Fri, May 20, 2011 at 7:15 PM, Fred Frigerio ffrige...@frigerio.uswrote:

 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




 On Fri, May 20, 2011 at 1:01 PM, Quinn Plattel qie...@gmail.com wrote:

 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 

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

2011-05-21 Thread Quinn Plattel
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


On Sat, May 21, 2011 at 10:53 AM, Quinn Plattel qie...@gmail.com wrote:

 Hi,

 I found this message when I am trying to tunnel 4713 via ssh ssh -L
 4713:localhost:4713 user@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@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


 On Sat, May 21, 2011 at 10:31 AM, Quinn Plattel qie...@gmail.com wrote:

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

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

2011-05-21 Thread Quinn Plattel
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@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

On Sat, May 21, 2011 at 11:29 AM, Quinn Plattel qie...@gmail.com wrote:

 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



 On Sat, May 21, 2011 at 10:53 AM, Quinn Plattel qie...@gmail.com wrote:

 Hi,

 I found this message when I am trying to tunnel 4713 via ssh ssh -L
 4713:localhost:4713 user@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@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, 

[pulseaudio-discuss] Strange parsing module args?

2011-05-21 Thread mar...@saepia.net
Hi,

why following command does not work

load-module module-null-sink sink_description=tuned\ patchbay:\ TCP\
source\ xxx,sink_name=tuned.patchbay.source.xxx


while this one works:

load-module module-null-sink
sink_name=tuned.patchbay.source.xxx,sink_description=tuned\
patchbay:\ TCP\ source\ xxx


Why argument order makes difference? Is it correct behaviour or a bug?

m.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


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

2011-05-21 Thread Quinn Plattel
Hi,

I did a LANG=C pulseaudio --system --high-priority -
/root/pulseverbose.log 21 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

On Sat, May 21, 2011 at 5:14 PM, Quinn Plattel qie...@gmail.com wrote:

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


 On Sat, May 21, 2011 at 11:29 AM, Quinn Plattel qie...@gmail.com wrote:

 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



 On Sat, May 21, 2011 at 10:53 AM, Quinn Plattel qie...@gmail.com wrote:

 Hi,

 I found this message when I am trying to tunnel 4713 via ssh ssh -L
 4713:localhost:4713 user@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@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
 -


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

2011-05-21 Thread 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).

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@jimmy ~]$ hostname
jimmy
[colin@jimmy ~]$ xprop -root | grep PULSE_COOKIE
PULSE_COOKIE(STRING) = 71eb0d3d53819c42957ce9..
[colin@jimmy ~]$ pacmd list-modules | grep module-native-protocol-tcp
name: module-native-protocol-tcp
[colin@jimmy ~]$ ssh -X -R :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:
[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:...
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-_00_1b.0.analog-stereo
Default Source: alsa_input.pci-_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/]

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