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 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
>>
>>
>>
>>
>> On Fri, May 20, 2011 at 7:15 PM, Fred Frigerio <ffrige...@frigerio.us>wrote:
>>
>>> 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.ie>wrote:
>>>>>
>>>>>> 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 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/]
>>>>>>
>>>>>> _______________________________________________
>>>>>> pulseaudio-discuss mailing list
>>>>>> pulseaudio-discuss@mail.0pointer.de
>>>>>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards/Med venlig hilsen,
>>>> Quinn Plattel
>>>>
>>>> _______________________________________________
>>>> pulseaudio-discuss mailing list
>>>> pulseaudio-discuss@mail.0pointer.de
>>>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> pulseaudio-discuss mailing list
>>> pulseaudio-discuss@mail.0pointer.de
>>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>>>
>>>
>>
>>
>> --
>> Best regards/Med venlig hilsen,
>> Quinn Plattel
>>
>
>
>
> --
> Best regards/Med venlig hilsen,
> Quinn Plattel
>



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

Reply via email to