HI.<br><br>Last post on this thread, then I will start a new one.<br>I managed to cut down the delay considerably by simplifying the commands:<br><br>local sound server: ssh -L 5901:localhost 5901 -L 1234:localhost:1234 <remote sound client> *parec | nc -l 1234"<br>
local sound server: nc localhost 1234 | pacat<br><br>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><br>
br,<br>Quinn<br><br><div class="gmail_quote">On Sun, May 22, 2011 at 9:58 PM, Quinn Plattel <span dir="ltr"><<a href="mailto:qiet72@gmail.com">qiet72@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br><br>Correction on the last two lines:<br>local sound server: mkfifo <b>fifo.wav</b><div class="im"><br>local sound server: paplay --volume=48000 -v fifo.wav & nc localhost 1234 >fifo.wav<br><br></div>br,<br>
<font color="#888888">Quinn</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">
On Sun, May 22, 2011 at 9:57 PM, Quinn Plattel <span dir="ltr"><<a href="mailto:qiet72@gmail.com" target="_blank">qiet72@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Well, here is my almost perfect solution:<br><br>local sound server: ssh -L 5901:localhost:5901 -L 1234:localhost:1234 <remote sound client><br>remote sound client: mkfifo output.wav<br>remote sound client: parec | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav" & cat output.wav | nc -l 1234<br>
local sound server: mkfifo output.wav<br>local sound server: paplay --volume=48000 -v fifo.wav & nc localhost 1234 >fifo.wav<br><br>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.<br>
<br>Any ideas why such a huge latency?<br><br>br,<br><font color="#888888">Quinn</font><div><div></div><div><br><br><div class="gmail_quote">On Sun, May 22, 2011 at 8:13 PM, Quinn Plattel <span dir="ltr"><<a href="mailto:qiet72@gmail.com" target="_blank">qiet72@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br><br>I have now found a partial solution to the protocol error that happens when I try to play sound remotely through pulse.<br>
What I did was I played around with different versions of pulseaudio on the remote side by using different versions of Ubuntu.<br>
On the local server side, we are using pulseaudio 0.9.15.<br>Ubuntu Lucid Lynx 10.04 has version 0.9.22 of pulseaudio and it gives "protocol error" on the local server side.<br>Ubuntu Koala Karmic 9.10 has version 0.9.19 of pulseaudio and it gives "protocol error" on the local server side.<br>
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.<br><br>I will see if I can downgrade the version of pulseaudio in Ubuntu Lucid Lynx.<br>
<br>Question: Is it possible to force pulseaudio to use an older protocol?<br><br>br,<br><font color="#888888">Quinn</font><div><div></div><div><br><br><div class="gmail_quote">On Sun, May 22, 2011 at 4:49 PM, Quinn Plattel <span dir="ltr"><<a href="mailto:qiet72@gmail.com" target="_blank">qiet72@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br><br>Here are my results....<br><br><div class="gmail_quote"><div>On Sat, May 21, 2011 at 7:58 PM, Colin Guthrie <span dir="ltr"><<a href="mailto:gmane@colin.guthr.ie" target="_blank">gmane@colin.guthr.ie</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
I think you're maybe getting a little confused by client and server in<br>
terms of how things work here (perhaps not, as I've not thoroughly read<br>
all the many posts in this thread).<br></blockquote></div><div><br>You are right. I used the terminology because of the way I am ssh'ing from and to.<br><br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. Open a terminal and type: "xprop -root | grep PULSE_COOKIE" Ensure<br>
this has some output. If it does not then chances are the<br>
"start-pulseaudio-x11" script was not run at login (or you have<br>
restarted your PA server after logging in). Try just running<br>
"start-pulseaudio-x11" and see if that fixes it.<br></blockquote></div><div><br>"xprop -root | grep PULSE_COOKIE" does not turn up any results on the local sound server or on the remote sound client side<br>
"dpkg -L pulseaudio | grep start-pulseaudio-x11" does not turn up any results on the local sound server side but<br>it does turn up results on the remote sound client side.<br><br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
3. Ensure that the tcp native protocol module is loaded. "pacmd<br>
list-modules | grep module-native-protocol-tcp" If it is not loaded,<br>
then simply type: "pactl load-module module-native-protocol-tcp"<br></blockquote></div><div><br>pacmd gives the error "No PulseAudio daemon running, or not running as session daemon." on the local sound server side but<br>
I managed to get around this by:<div><br># stop pulseaudio<br># pulseaudio --system --high-priority -C<br><br></div>and then at the pulseaudio command line: list-modules<br>Here is the module:<br>-------------------------------<br>
index: 18<div><br>
name: <module-native-protocol-tcp><br></div> argument: <auth-anonymous=1><br> used: -1<br> load once: no<br> properties:<br> module.author = "Lennart Poettering"<br> module.description = "Native protocol (TCP sockets)"<br>
module.version = "0.9.15"<br>------------------------------- <br><br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
4. SSH to your other machine: ssh -X -R4713:localhost:4713 OTHERMACHINE<br>
<br>
If you get a warning:<br>
Warning: remote port forwarding failed for listen port 4713<br>
then chances are there is a PA daemon running there already, or you've<br>
SSH'ed twice. If the former, just change the *first* instance of 4713 to<br>
a random number of your choice (>1024).<br></blockquote></div><div><br>No problems there.<br> <br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
5. On this remote machine, check your cookie is available via the xprop<br>
command show in step 2. If X11 forwarding is working properly, it should<br>
show up fine.<br></blockquote></div><div><br>"xprop -root | grep PULSE_COOKIE" does not give any results on the remote machine.<br><br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
6. Set the PULSE_SERVER variable to the forwarded tunnel port.<br>
<div> export PULSE_SERVER=localhost:4713<br>
</div>(or the port number you picked in step 4 if different)<br>
<br>
7. Confirm it's all working: PULSE_LOG=99 pactl stat<br>
<br></blockquote></div><div>Results of "PULSE_LOG=99 pactl stat" on the remote sound client side:<div><br>-----------------------------------------<br>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<br>
Trying to connect to localhost:4713...<br>SHM possible: yes<br></div>Protocol version: remote 16, local 16<br>Negotiated SHM: no<br>Connection failure: Connection terminated<br>-----------------------------------------<br>
<br>Results on the local sound server side:<br>
------------------------------------------<div><br>E: protocol-native.c: protocol error, kicking client<br></div>------------------------------------------ <br><br></div><div><div></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Done!!<br>
<br>
So in this setup, the cookie used for authentication is forwarded<br>
automatically via piggy backing on to X11 connections but as you cannot<br>
connect directly to the machine we've had to override the PULSE_SERVER<br>
variable to go over the SSH tunnel.<br>
<br>
Below is the output from my session where I run these exact commands<br>
(note the host name in the pactl stat at the end).<br>
<br>
HTHs<br>
<br>
Col<br>
<br>
<br>
[colin@jimmy ~]$ hostname<br>
jimmy<br>
[colin@jimmy ~]$ xprop -root | grep PULSE_COOKIE<br>
PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9......"<br>
[colin@jimmy ~]$ pacmd list-modules | grep module-native-protocol-tcp<br>
name: <module-native-protocol-tcp><br>
[colin@jimmy ~]$ ssh -X -R 5555:localhost:4713 mediacentre<br>
Last login: Sat May 21 18:51:40 2011 from jimmy.local<br>
[media@(Media)centre ~]$ xprop -root | grep PULSE_COOKIE<br>
PULSE_COOKIE(STRING) = "71eb0d3d53819c42957ce9......"<br>
[media@(Media)centre ~]$ export PULSE_SERVER=localhost:5555<br>
[media@(Media)centre ~]$ PULSE_LOG=99 pactl stat<br>
<div>Using shared memory pool with 1024 slots of size 64.0 KiB each, total<br>
</div>size is 64.0 MiB, maximum usable slot size is 65496<br>
Trying to connect to localhost:5555...<br>
SHM possible: no<br>
Protocol version: remote 21, local 16<br>
Negotiated SHM: no<br>
Currently in use: 2 blocks containing 149.9 KiB bytes total.<br>
Allocated during whole lifetime: 1220055 blocks containing 1.6 GiB bytes<br>
total.<br>
Sample cache size: 86.0 KiB<br>
User name: colin<br>
Host Name: jimmy<br>
Server Name: pulseaudio<br>
Server Version: 1.0.0-0.354.1.csg1<br>
<div>Default Sample Specification: s16le 2ch 44100Hz<br>
Default Channel Map: front-left,front-right<br>
</div>Default Sink: alsa_output.pci-0000_00_1b.0.analog-stereo<br>
Default Source: alsa_input.pci-0000_00_1b.0.analog-stereo<br>
Cookie: d7756be2<br>
[media@(Media)centre ~]$<br>
<font color="#888888"><br>
<br>
<br>
--<br>
</font><div><div></div><div><br>
Colin Guthrie<br>
gmane(at)<a href="http://colin.guthr.ie" target="_blank">colin.guthr.ie</a><br>
<a href="http://colin.guthr.ie/" target="_blank">http://colin.guthr.ie/</a><br>
<br>
Day Job:<br>
Tribalogic Limited [<a href="http://www.tribalogic.net/" target="_blank">http://www.tribalogic.net/</a>]<br>
Open Source:<br>
Mageia Contributor [<a href="http://www.mageia.org/" target="_blank">http://www.mageia.org/</a>]<br>
PulseAudio Hacker [<a href="http://www.pulseaudio.org/" target="_blank">http://www.pulseaudio.org/</a>]<br>
Trac Hacker [<a href="http://trac.edgewall.org/" target="_blank">http://trac.edgewall.org/</a>]<br>
<br>
_______________________________________________<br>
pulseaudio-discuss mailing list<br>
<a href="mailto:pulseaudio-discuss@mail.0pointer.de" target="_blank">pulseaudio-discuss@mail.0pointer.de</a><br>
<a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a><br>
</div></div></blockquote></div></div></div><br><br clear="all"><div><div></div><div><br>-- <br>Best regards/Med venlig hilsen,<br>Quinn Plattel<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best regards/Med venlig hilsen,<br>Quinn Plattel<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best regards/Med venlig hilsen,<br>Quinn Plattel<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best regards/Med venlig hilsen,<br>Quinn Plattel<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best regards/Med venlig hilsen,<br>Quinn Plattel<br>