Xpra: Ticket #673: Change sound server option

We should add an option to allow the user to select the sound server to use on the server.



Wed, 10 Sep 2014 01:41:12 GMT - Antoine Martin: owner, priority, summary, status, milestone changed

This should work for both client and server (server for speaker, client for microphone forwarding).

Add the switches, maybe sound-input? Maybe we can support module options, ie: sound-input=alsa:device=XYZ,etc

This rill require changing the start_sending_sound function. We currently check for sound loops using the pulseaudio id, this will need to be special cased somewhere.

See also #400.


Mon, 15 Sep 2014 09:38:17 GMT - Antoine Martin: owner, status changed

Done in r7616, this should help with #400 a bit.

Use it like so:

xpra start --sound-source=XYZ

For a list of source options, use:

xpra --sound-source=help

It also supports plugin options, like so:

xpra start --sound-source=alsa:device=xyz

For the list of options for each plugin, refer to the GStreamer plugin information, ie: alsasrc.

If you have problems, please post the debug output with -d sound.


Wed, 01 Oct 2014 00:57:12 GMT - Antoine Martin: status changed; resolution set

Not heard back. Closing. (default should be unchanged anyway)


Thu, 02 Oct 2014 08:11:27 GMT - peterlong0210:

I'm sorry for the late response. I resolved my trouble : use pulseaudio for windows client. And I forgot reply this track. :)


Thu, 02 Oct 2014 08:13:40 GMT - Antoine Martin:

I resolved my trouble : use pulseaudio for windows client.


@peterlong0210: Are you saying that you are using pulseaudio.exe on windows? Or that you installed pulseaudio on the server?


Thu, 02 Oct 2014 09:38:35 GMT - peterlong0210:

@totaam: I'm using pulseaudio.exe on windows ( client-side ). I removed pulseaudio on server ( Ubuntu 12.04 ) http://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Windows/Support/


Thu, 02 Oct 2014 09:43:05 GMT - Antoine Martin:

Thanks, that is one of the craziest things I have heard in a long time!

Why on earth would you want to run pulseaudio on the client side on windows? I really do not understand why you would ever want to do that.

Also, if you've removed pulseaudio from the server, you must be using the new code to get your sound forwarding to work? Or maybe you're using an alsa-pulseaudio compatibility layer or something?


Thu, 02 Oct 2014 09:57:22 GMT - peterlong0210:

@totaam: Because I found that If I use xpra with pulseaudio server, CPU usage of xpra process ~8-10% ( don't do anything else, just "xpra start :100" then attach). If I run pulseaudio on the client-side on windows, I can resolve it ( CPU usage ~0-1% ) About new code, I just add new environment variables : PULSE_SERVER=CLIENT_IP:SOUND_PORT_FORWARD then run pulseaudio.exe in windows ( with a bit config about pulseaudio).


Thu, 02 Oct 2014 10:02:30 GMT - Antoine Martin:

Ah, I get it, so you're not using xpra for sound forwarding at all. That makes more sense. FYI: last time I checked, pulseaudio will use up a large amount of bandwidth - so it is a case of trading CPU for bandwidth..


Thu, 02 Oct 2014 10:28:32 GMT - peterlong0210:

Replying to totaam:

Ah, I get it, so you're not using xpra for sound forwarding at all. That makes more sense. FYI: last time I checked, pulseaudio will use up a large amount of bandwidth - so it is a case of trading CPU for bandwidth..

Do you mean xpra with pulseaudio will decrease bandwidth and increase CPU, and If I'm not using xpra for sound forwarding, I will decrease CPU, but take more bandwidth ? Sorry If my English is not good.


Thu, 02 Oct 2014 10:34:41 GMT - Antoine Martin:

Do you mean xpra with pulseaudio will decrease bandwidth and increase CPU, and If I'm not using xpra for sound forwarding, I will decrease CPU, but take more bandwidth ?


I believe so, see https://winswitch.org/trac/ticket/88.

When I last measured it, pulseaudio over the network was using about 3MBps IIRC, xpra with the default codec uses about 100 times less (on average).

But maybe things have changed? Or maybe you have lots of bandwidth to spare? (note that this bandwidth use will affect xpra too). Otherwise, you could try different codecs to see which one gives you the best trade off, probably wavpack I would guess.


Thu, 02 Oct 2014 10:38:25 GMT - peterlong0210:

Thank you for your advice and information :)


Sat, 23 Jan 2021 05:02:36 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/673