Jan, Thanks ever so much for the fantastic detailed reply below. It inspires me to make another attempt on the coming weekend. Your pointers to where the LTSP system keeps its startup commands will be particularly helpful. (Emergencies at work will now take me off-line for a day or two.)
I do understand that usually the LTSP-server is the pulseaudio-client, while the LTSP-[thin-]client is the pulseaudio-server. This criss-cross in simultaneous roles adds a little challenge to writing clearly about which device is doing what! But I am also happy to get confirmation that the pulseaudio daemon needs to run on both machines in order for sound to flow between them. Gratitude now; further details later. - Philip On 06/13/2012 03:31 AM, Jan Middelkoop wrote: > On 13-06-12 08:28, Philip Loewen wrote: >> Unfortunately I don't really understand how pulseaudio is supposed to >> work across the network. Should a pulseaudio process be running also on >> the LTSP server? > > Seems like you have figured out most of it already. > > See pulseaudio as a sound 'server'. It provides a way for applications > to play sound. The applications connect to the pulseaudio server, and > pulseaudio directs that sound to an output device (a soundcard). The > pulseaudio server should therefor always be running on the machine which > has access to the sound device. > > In LTSP's case, applications running on the server, connect to > pulseaudio running on the client, and pulseaudio there sends the audio > to the local soundcard. So the pulseaudio process should be running on > each client, and not on the server (unless you want to use the soundcard > in the server, for whatever reason - but that's another story). > > You've already found the PULSE_SERVER export - that's how the server > applications know where to send their audio streams to. You can use the > command 'pactl' to connect to and control the server specified in > PULSE_SERVER. For example, 'pactl info' shows the status of the > pulseaudio server. As you've already determined the server isn't running > on your client, this will not return anything useful. > > And that concludes this drive-by introduction to pulseaudio in LTSP. As > for the specific problem you're having - the question you should be > asking yourself is: what have you changed since the last time you ran > ltsp-update-image? My experience is that usually these things do not > happen 'spontaneously', despite obvious appearances. > > About your error: the LTSP code that is responsible for starting the > pulseaudio daemon, can be found in > /opt/ltsp/<arch>/usr/share/ltsp/ltsp-init-common. You can find some > pointers there, such as the exact arguments that LTSP uses to launch > pulseaudio. You will see it calls pulseaudio with very different > arguments than you used in your test case, therefor your test case (and > any error messages you get from it) are unreliable. > > From the ltsp-init-common file, you can also see that LTSP instructs > pulseaudio to log to the syslog - so be sure to check /var/log/syslog on > the client. That's where the pulseaudio startup error messages will be. > It might be the same as your test case... but then it might just not be. > > Kindest regards, > > Jan Middelkoop > Recreatie en Zorg Groep B.V. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
