Version 9 (modified by 8 years ago) (diff) | ,
---|
Sound
Note: at the moment sound is disabled by default so all commands must be started with the environment variable XPRA_SOUND
set to any non-zero value. ie:
export XPRA_SOUND=1 xpra start :10
Once the sound has started forwarding (and not before), you may get more diagnostic messages by setting XPRA_SOUND_DEBUG=1
. (see Debugging)
Requirements
You will need:
- a build/installation including gstreamer support for both client and server
- a client with sound output of any kind (even virtual)
- a server with pulseaudio (for going beyond the simple test step)
- users must be "pulseaudio-enabled" - whatever that means in terms of permissions and user setup (distribution specific)
Standalone Tests
You can run the following test commands to run/test individual parts of the sound pipeline:
./xpra/sound/gstreamer_util.py
(namedGStreamer_Info.exe
) on MS Windows) - will dump all the gstreamer plugins installed, validates that the gstreamer installation is functional./xpra/sound/pulseaudio_util.py
will list the pulseaudio devices found if a pulseaudio server is running./xpra/sound/src.py
will dump pulseaudio sound to file until interrupted./xpra/sound/sink.py
will play a sound file until interrupted (a "cheap mp3 player")
Test Sound Source Setup
The easiest way of testing that a system is capable of forwarding and receiving sound is on a Posix system (Linux, BSD, etc).
Using the XPRA_SOUND_TEST
environment variable, we can instruct the xpra server to use a fake sound source instead of hooking into a pulseaudio server:
XPRA_SOUND_TEST=1 xpra start :10
Then we can attach the client and start the speaker from the tray:
xpra attach
You should then hear a constant (rather annoying) tone. Getting this far ensures that sound forwarding does work on this system, albeit from a fake source instead of pulseaudio.
Simple Diagnostics
Things to look for:
- if the speaker is greyed out in the tray then sound is not enabled, check:
- Session Info shows sound attributes in 'Server Features'
- "xpra info" should show the pipeline state when a client is playing sound:
$ xpra info | grep -i speaker speaker.state=active
pavucontrol
both on the client and inside the xpra session (see examples below)
Using an existing pulseaudio server
Next, we want to add pulseaudio, but without starting it ourselves, so we can simply re-use the existing server that gets started with most modern desktops.
Check that pulseaudio is running in your Posix desktop:
pactl info
Start an xpra server:
xpra start :10
Attach from the same machine:
xpra attach
The server log file should contain the warning message:
identical pulseaudio server, refusing to create a sound loop - sound disabled
Getting this far should ensure that all the components are installed, enabled and that the xpra server found the pulseaudio device to connect to.
Test Remote Setup
Using a second client machine (or a second desktop session, virtual machine, etc), we can connect this new client to the server and get the sound from the desktop session forwarded to the client.
The server can be running the test source or a the desktop session's pulseaudio server. In the case of an existing pulseaudio server, simply start any sound application in the desktop session, the sound should come out in both this session's speakers (if any) and the client's speakers (if any / different!).
pavucontrol
on the server should show an Xpra entry in the Recording
tab.
The client should show an Xpra entry in the Playback
tab (or whatever mixer/sound tool you have installed)
Full Setup
Finally, we may want an xpra session to use a dedicated pulseaudio server.
This is more difficult and at present, unless you really know what you are doing and are prepared to pickup the pieces, you should not attempt to do this as a user which already has an existing dbus session and pulseaudio server. Simply clearing the environment and trying to start a new pulseaudio instance will not work without some serious hacks to the environment variable that pulseaudio uses to find existing instances. winswitch will do this for you.
Now, assuming that you have a dedicated user, without any form of dbus or pulseaudio server running. You should be able to setup a sound-capable environment by using a command line similar to this one:
dbus-launch xpra start :10 --no-pulseaudio \ --start-child="pulseaudio --start --daemonize=false --system=false \ --exit-idle-time=-1 -n --load=module-suspend-on-idle \ --load=module-null-sink --load=module-native-protocol-unix \ --log-level=4 --log-target=stderr"
Notes:
- the
--no-pulseaudio
flag is there to prevent old support code from firing - this may get removed in the future. - you will need to use a tcp socket (
--bind-tcp=
or ssh forwarding to connect to this account - out of scope here. - we may well introduce new xpra command line options to simplify this setup process
You should then see these messages in the server log:
(..) D: [pulseaudio] main.c: Got org.PulseAudio1! D: [pulseaudio] main.c: Got org.pulseaudio.Server! I: [pulseaudio] main.c: Daemon startup complete. 2013-01-07 17:42:55,732 xpra is ready.
And when connecting a sound capable client:
I: [pulseaudio] client.c: Created 0 "Native client (UNIX socket client)" (...) 2013-01-07 17:44:32,205 will send sound using mp3 codec (...) 2013-01-07 17:44:32,309 starting sound using null.monitor D: [pulseaudio] module-suspend-on-idle.c: Sink null becomes busy.
And yet more log messages as your start a sound application in this xpra session.
Screenshots
- A Linux client's pavucontrol showing the Xpra application connected to the local pulseaudio server:
- pavucontrol running within the xpra session ("on the server"), showing xpra recording the session's sound:
Attachments (3)
-
pavucontrol-client.png (28.8 KB) - added by 8 years ago.
pavucontrol running on the client
-
pavucontrol-server.png (30.8 KB) - added by 8 years ago.
pavucontrol running on the server
-
session-info-sound.png (38.8 KB) - added by 8 years ago.
new session info dialog showing sound attributes
Download all attachments as: .zip