On Dec 22, 2007 10:38 AM, Bill Moseley <<a href="mailto:moseley@hank.org">moseley@hank.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Dec 21, 2007 at 04:11:02PM -0500, Ritesh Kumar wrote:<br>> The big picture ain't that pretty, isn't it? :)<br><br></div>Eh, no it's not.<br><br>And I'm still not even clear in the LTSP environment who is the pulse
<br>client and who is the server. ;)<br></blockquote><div><br>He he... I am sorry though... I have little idea of the LTSP setup. But the pulse server will always likely to be where the sound card is ... similar to the X server which is always where the display is.
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Let me as a simple question, which maybe you answered in your reply<br>and I didn't recognize. On my normal workstations that uses ALSA
<br>both the GNOME volume applet and alsamixer work.<br><br>On the LTSP setup, the GNOME applet looks the same but doesn't work,<br>yet alsamixer seems to know that it should be using pulse. How does<br>alsamixer know this yet the applet doesn't?
<br></blockquote><div><br>That is odd... can you check if GNOME applet is using anything other than ALSA for controlling its audio. If Gnome is using the ALSA interface, then things should work properly.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Also, is this problem not related to Pulse? The volume control on the<br>LTSP server isn't suppose to use Pulse to run the hardware volume on<br>the LTSP thin client, correct? Rather, it controls a soft volume<br>
control on the audio stream before it's passed via pulse to the<br>hardware on the remote client, right? </blockquote><div><br>The pulse server should run on the machine where the soundcard is. However, alsa could be running anywhere if all its doing is redirecting to the pulse server.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>So the trick is getting the GNOME applet to use a soft volume control<br>-- which I believe is what you are showing below.
<br></blockquote><div><br>What I was trying to show below was how the default alsa configuration on the machine having the sound card on it could cause the pulse server not be able to control its volume. The client machines will work without problems if they all redirect any alsa calls to the pulse server and the pulse server is able to correctly control the volume.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d"><br>> If you want a quick solution try adding a device=default in you
<br>> module-alsa-sink configuration. This is not optimal as it layer dmix below<br>> pulseaudio instead of eliminating it from the pipeline.<br><br></div>And that would be on the LTSP thin client? I don't have a
<a href="http://default.pa" target="_blank">default.pa</a><br>on the LTSP server, only on the client:<br><br> /opt/ltsp/i386/etc/pulse/default.pa<br></blockquote><div><br>That seems reasonable given that the sound needs to be produced on the client.
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Currently, that module is commented out -- is that expected?<br><br> $ fgrep module-alsa-sink /opt/ltsp/i386/etc/pulse/default.pa
<br> #load-module module-alsa-sink<br> #add-autoload-sink output module-alsa-sink sink_name=output<br><div class="Ih2E3d"><br><br>> What I recommend you do is ditch the default alsa configuration and make<br>> your own. The first thing to do is to make your own virtual device and add a
<br>> "Master" softvol to it if necessary. Use the following as a guide line...<br>> use your local ~/.asoundrc if you don't feel like modifying /etc/asound.conf<br><br>> pcm.!default { type pulse }
<br>> ctl.!default { type pulse }<br>> # Create softvol devices for intelHDA.<br>> # For intelHDA, its "PCM" control controls its default (not used) softvol.<br>> pcm.intelHDA {<br>> type softvol
<br>> slave.pcm "hw:0,0"<br>> <a href="http://control.name" target="_blank">control.name</a> "Master"<br>> control.card 0<br>> }<br>><br>> # It seems we require these dummies as pulseaudio tries to look up mixer
<br>> devices.<br>> ctl.intelHDA {<br>> type hw<br>> card 0<br>> }<br>><br>> Then use intelHDA or whatever name you use above in your module-alsa-sink<br>> configuration. Something like module-alsa-sink device=intelHDA
<br><br></div>Is "intelHDA" just a name? That is, I could call it anything?<br><font color="#888888"></font></blockquote><div><br>Yes, only some pcm names are reserved (like default).<br>You might want to isolate the problem first. Why don't you first run a little alsa app on the thin clients directly and see if 1) the sound plays through pulseaudio (use pacmd to list the sink-inputs) 2) Check if alsamixer is able to control pulseaudio's volume (alsamixer should show pulseaudio as the soundcard's name) 2) Check if the gnome volume applet works.
<br>Then configure alsa on the remote machine to redirect to pulseaudio and repeat the steps above.<br></div></div><br>_r