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 On Sun, May 22, 2011 at 8:13 PM, Quinn Plattel <qiet72 at gmail.com> wrote: > 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 > > > On Sun, May 22, 2011 at 4:49 PM, Quinn Plattel <qiet72 at gmail.com> wrote: > >> Hi, >> >> Here are my results.... >> >> On Sat, May 21, 2011 at 7:58 PM, Colin Guthrie <gmane at colin.guthr.ie>wrote: >> >>> 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 >>> 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. >> >> >>> 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" >> ------------------------------- >> >> >>> 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). >>> >> >> No problems there. >> >> >>> >>> 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. >> >> >>> 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 >>> >>> Results of "PULSE_LOG=99 pactl stat" on the remote sound client 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 >> ----------------------------------------- >> >> Results on the local sound server side: >> ------------------------------------------ >> >> E: protocol-native.c: protocol error, kicking client >> ------------------------------------------ >> >> >>> 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/] >>> >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110522/f108d548/attachment.htm>
