Hi Ralf,
I am the Windows maintainer for X2Go Client. I also am maintaining the Windows builds of PulseAudio.
Sorry that you are running into this problem, and sorry for not getting back to you earlier. Something came up in my personal life that kept me busy, and I contribute in my free time.
See the rest of my responses inline below.
On Fri, Dec 5, 2014 at 5:16 AM, Ralf <x2go-list@bergfelde.homelinux.net> wrote:
Hi!
I did some further research and now it is running as desired:
First part has nothing to do with x2go - it's a pulseaudio problem or more specific a driverproblem with Intel-Onboardsound. Pulseaudio will terminate with a nasty error on win7. Can be seen by running pulseaudio.exe in an administrative command-window.
This can be solved if the line load-module module-waveout sink_name=output source_name=input is edited to load-module module-waveout record=0 sink_name=output source_name=input in the default.pa
It sounds like record=0 disables microphone input on the device. http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modul...
Lately I have been working on building PulseAudio 6.0RC1; I was successful. Now I am making X2Go Client for Windows work with it. (There is a source code change required to X2Go Client for Windows.) Once I have a build of X2Go Client for Windows with PulseAudio 6.0RC1 (or 6.0RC2, or 6.0 final, etc) ready, I would like you to try it. Perhaps PulseAudio's 6.0's new logic will work around the bug in your audio driver.
If not, I would be more than happy to add an option somewhere in X2Go Client to pass record=0 to module-waveout. It sounds like it should probably in the X2Go Client for Windows Settings (Options -> Settings), rather than a session's settings.
... and there comes the problem with the pulseaudio from x2go. There is no default.pa to be edited. I have taken the lastest pulseaudio for windows (1.1) and started it manually before connecting with x2go. Check with pulseaudio.exe --dump-conf to be sure your edited default.pa is used.
We do not use default.pa because we generate our own custom config.pa . This custom config.pa is used instead of default.pa .
More info about default.pa: Launch x2goclient.exe and connect to a session with audio enabled. Then look under C:\Users\mike.DEPAULO\.x2go\pulse\ .There should be a subdirectory in the format "tmp.p*", where "*" is a 3 to 5 digit number. Its timestamp should indicate that it was created when you connected. Until you quit x2goclient, there will be a config.pa file under it. I've attached a sample one.
Starting pulseaudio by hand before an x2go-session brings the next problem: The x2go-client tries to start pulseaudio automatically and if the standardport 4713 is already in use it takes the next free port. Here 4714 ... although it will not start (remember the first problem with driver) it gives this port as targetserver to his session. This will end in no audiosound - running pulse on pc is on port 4713, the x2go-session will send to 4714 -> no way. There are two ways to avoid this: Easy way: First start x2go-session without audioforward over ssh, then start pulseaudio on commandline. You can check with netstat -a if pulseaudio occupies port 4713 on your windows pc and in your x2go-session have a look at 'less $PULSE_CLIENTCONFIG' if your windowspc is used as targetserver by pulseaudio with the right port. This way works fine for people knowing what to do and which are comfortable using a commandline.
For automated deploying dockercontainers to "normal user staff" do following: Attention these are "bad" ideas, because something is hardcoded and must be kept in mind when changing for example the dockercontainer-image. If people should use a "full" desktop put following little script in /etc/profile.d and make it executable for all: write_pulseclient_conf.sh
#!/bin/sh
PORT=4731 SERVER=
echo $SSH_CONNECTION | awk -F " " '{print $1}'echo "default-server = "$SERVER":"$PORT > $PULSE_CLIENTCONFIGthis will overwrite the "wrong" conf send be x2go-client and change the pulseserver-port to whatever you have choosen. Here 4731
For people who should only get a windowed application like iceweasel it get's more complicated, because they are not loading a profile. But it works this way ... Take the script /usr/bin/x2goruncommand. Search the line: echo "exec $cmd" >> "$MESSAGE_FILE" Add after that line the following line: /etc/profile.d/write_pulseclient_conf.sh This will run the little script from above everytime a x2go-session is started (yes it will run 2 times when someone connects to a full desktopsession, but it is an ugly hack, right?)
So there is only one question left: How to change the pulseaudio-serverport on your windows? Again it is the default.pa . Search: load-module module-native-protocol-tcp listen=0.0.0.0 auth-anonymous=1 Change to: load-module module-native-protocol-tcp listen=0.0.0.0 port=4731 auth-anonymous=1 ... and done. Simple after reading the pulseaudio docs on modules ... and don't expect to find the "port=" in the doc about module-native-protocol-tcp :)
Famous last words ... this is my way how it works for me in an internal network, where security is less then "in the wild". The audio-connection is NOT encrypted this way. Audio is not that good, but enough to have a look at trainingvideos on eg. youtube - make sure to use html5 ... flashaudio is horrible in this szenario.
Many thanks to uncountable websites and others for the view into the mechanics of pulseaudio ...and to the x2go-team to write readable code :)
Have a nice time Ralf
Thank you for spending time your time to figure this out. Hopefully your workaround will not be necessary for very long.
[...]
Is there a chance to give an modified default.pa to the "internal" pulseaudio-server of the x2go-client or even better: is it possible to use an "external" pulseaudio.exe with the x2go-client?
I am confident that I can fix this bug under your case by either Upgrading PulseAudio to 6.0, or by adding a record=0 option. If any other use case requires one of those 2 approaches, then I will look into adding them.
Whether or not another use case is discovered, patches are welcome.
-Mike
[...]