Hi Stefan,
yes pulseaudio is started from x2gothinclientd - rdesktop does not support pulseaudio as audio backend - but you can workaround that with 'padsp' from the pulseaudio-utils package. - you just have to prefix the rdesktop command with padsp like:
padsp rdesktop -u <username> -f -r sound:local <address>
then pulseaudio redirects the access to /dev/dsp of rdesktop to itself.
xfreerdp should have native pulseaudio-support so it depends on your choice of software. To force xfreerdp to use pulseaudio you could add the parameter '--data tsmf:audio:pulse' to the xfreerdp-command
Kind regards
Florian Wicke
Hetzner Online AG Industriestr. 25 91710 Gunzenhausen / Germany Tel: +49 9831 505-187 Fax: +49 9831 505-387 florian.wicke@hetzner.de www.hetzner.com
Register Court: Registergericht Ansbach, HRB 3204 Management Board: Dipl. Ing. (FH) Martin Hetzner Chairwoman of the Supervisory Board: Diana Rothhan
Am 29.04.2015 um 12:13 schrieb Stefan Baur:
package: x2gothinclient version: 1.1.0.2
Hi,
when starting x2goclient in thinclient mode, pulseaudio gets started in the background. This blocks remote audio when using the RDP-DirectConnect feature of x2goclient.
When you do this:
/etc/init.d/x2gothinclient stop X & export DISPLAY=:0 ln -s /etc/x2go/x2gothinclient_sessions ~/.x2goclient/sessions x2goclient --thinclient
sound in an RDP-DirectConnect session works. So the Pulseaudio start takes place somewhere else - x2gothinclientd maybe? - and needs to be stopped for RDP-DirectConnect, as it blocks the audio device.
How that can be accomplished, without killing sound support for regular X2Go sessions, I don't know.
Who was the one that originally asked for the RDP-DirectConnect feature? How do they handle sound, or do they not need it?
-Stefan
x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev