OK then, from the top; the first reference was to another Mageia forum thread discussing remote VNC connections and KDE and polkit. From that I have
- Code: Select all
[richard@Gardenshed ~]$ ps -ef | grep polkit
polkitd 1520 1 0 Oct11 ? 00:00:00 /usr/lib/polkit-1/polkitd --no-debug
richard 2241 1 0 Oct11 ? 00:00:00 /usr/libexec/polkit-mate-authentication-agent-1
richard 9229 9173 0 14:15 pts/0 00:00:00 grep --color polkit
So I have the necessary polkit agent in place, and indeed it works for me when I am working locally on the server.
doktor5000 wrote:Apart from x2go, are you able to forward sound via pulseaudio to a remote box at all?Then you could test via an ssh session.
That one is a little trickier as the answer is "yes and no"; "yes" if I am in the same room as the server and set it to play sound from some source or other and then return to the client to listen to it, and "no" if I try to set the server to play sound in a session started by x2go on the client while I still have my local desktop on the server, active but idle (the normal state of affairs after a normal boot with autologin to the desktop), but "yes" if the server oots to a console so that the only desktop session is the one I start remotely with x2go.
Like I said, it's complicated. The answer to your subsequent question on whether the right modules are loaded might help to clarify this.
- Code: Select all
[richard@Gardenshed ~]$ pactl list modules short | grep tcp
11 module-native-protocol-tcp auth-anonymous=1
12 module-esound-protocol-tcp auth-anonymous=1
That was from a ssh console from the client. The server is currently running two X sessions for me; one is the usual local session and the other is the x2go remote session. The local session is displaying the output from Me-TV and I am now sitting in front of the client, listening to it. If I try the same command in a terminal started in the x2go session I get:
- Code: Select all
[richard@Gardenshed ~]$ pactl list modules short | grep tcp
Connection failure: Connection refused
That seems worthy of further linguistic analysis, which should work if the writer of the code is a native english user. The first part is quite neutral and appears to be a generalised announcement. The use of the word "failure" implies nothing more than it states; something didn't work and we will try to say what that is (the colon implies more to come). The second part, after the colon tells us much more. It says that the attempt to connect was actively refused by the intended recipient; the running pulse server. So, in one simple check we have already got a lot of information and enough to start wondering by what criterion the pulse server decided it should refuse what should be a perfectly valid request.
jaywalker wrote:One thing I did get from Colin's article was to check the X11 root window properties with
- Code: Select all
xprop -root | grep PULSE
When I do this at the ssh console I get
- Code: Select all
[richard@Gardenshed ~]$ xprop -root | grep PULSEPULSE_COOKIE(STRING) = "4736ddcae7adef3a8661bf7673c6fe0a29b710ae18d22a58a2d3c5eccbc1723c2d98087de58a03018ee007e902fef236b4702fcf0cef7253a1beba19ef6b509f372ebe3467a37e952fc4f028fd6f139dbd894152b11aaabc05af95d2f474838f078c54db65944824525e1e484ae4c31dda13bd4ed9e8b0078021b9f3dbc7e2a0108673710014d864be8963caa4a538a0047e5f40ccdcb7d0a60a94746b0cef7902c3f8cf1735d524eb610f735156a1e84f207fc6d6c26968412b0f53019ba0646bff05d35f89ce1eb06962b6cff5b17b73aa6377725bae16dfb3366223cd927d439fc19311152e9ff0c3db9decaeb2c65e7c6e5870b5d5eba9b4409de5fa7a44"PULSE_SERVER(STRING) = "{4eda2d50e7ed4725bd13b43e72dd5d0c}unix:/run/user/501/pulse/native tcp:localhost:4713 tcp6:localhost:4713 tcp:localhost:59861 tcp6:localhost:35456"PULSE_SESSION_ID(STRING) = "1"PULSE_ID(STRING) = "501@4eda2d50e7ed4725bd13b43e72dd5d0c/3817"
If I start a shell in my x2go session I get nothing; a zero response, not a dicky bird.
That is what first told me that the x2go session, configured to start without sound support, was having problems starting the pulseaudio server. The pulse cookie and everything else related to pulse in the X properties is absent when checking from the x2go session but present when checking with the simultaneously connected ssh terminal. If I had read more closely I would also have seen that the pusle server had been started with the correct network module (PULSE_SERVER), but that none of this information is available to me, the same user, in my remote x2go session.
doktor5000 wrote:Where did you use paprefs, a mixer or something to send the sound to your local box?
That one is a little harder to answer as it is still not clear to me what I did to make it work as I have tried everyting I could think of and in every possible way; remotely by ssh using X forwarding to manipulate paprefs and pa volume control, as before but locally on the server, using mc in a ssh shell to modify /etc/pulse/default.pa. Another thing I have done is follow the advice at one of your references
- Code: Select all
Alternatively you can load the module at runtime:
pactl load-module module-native-protocol-tcp 'auth-cookie=".pulse-cookie"'
I then moved on to trying RTP from the server as that seemed to produce a "device" which I could see in the pulse volume control and use to broadcast the cound. It worked well but I wanted the sound to be fowrwarded in the "standard" x2go manner, over the X via ssh connection. So I turned that off and tried again with the paprefs option "Make discoverable PulseAudio network sound devices locally" and ticking all the Network Server options on the next tab. That is how things have been since my first attempt to listen to Eric Clapton reported yesterday.
As to the pulse volume control settings, that is still largely a matter of point, poke, check and try again until I get a combination that works on the server, and a similar operation on the client.
doktor5000 wrote:Did you ensure that your local box can receive something via network, e.g. also with paprefs ?
I reckon I must have, though I don't remember the exact procedure. It was compliacted by having to re-install all the MGA3 pulse-related rpms a few days ago (Friday?) and go through many failed attempts as there had not been anything coming from the server to check. Once I got both ends working I conducted the tests reported yesterday to establish under what conditions I could get a reliable sound link. Those are the conditions which I summarised above and again here:
I can achieve a working x2go session on the server ONLY IF I configure the client to connect with no sound support.
I can manage/control the server's pulseaudio from the x2go session ONLY IF the server is started in runlevel 3 and the x2go session is the ONLY session for my user.
I can hear the audio on my client ONLY IF I use a separate data stream coming directly from the pulseaudio server as the x2go route is impossible to achieve until I can resolve the problem which prompted me to seek help to get x2go sound support working.
doktor5000 wrote:Please read the documentation I've linked to above, go through it and then you can try again.
I will do as you suggest.
R
