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
On Sat, May 21, 2011 at 11:29 AM, Quinn Plattel <qiet72 at 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 <qiet72 at gmail.com> wrote:
>
>> 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
>>
>>
>> On Sat, May 21, 2011 at 10:31 AM, Quinn Plattel <qiet72 at 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 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
>>>
>>>
>>>
>>>
>>> On Fri, May 20, 2011 at 7:15 PM, Fred Frigerio <ffrigerio at 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 <qiet72 at 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 <qiet72 at gmail.com>wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>> On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie <gmane at 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 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> Best regards/Med venlig hilsen,
>> Quinn Plattel
>>
>
>
>
> --
> Best regards/Med venlig hilsen,
> Quinn Plattel
>
--
Best regards/Med venlig hilsen,
Quinn Plattel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110521/68312fa9/attachment.htm>
