Change sound server option

[peterlong0210]

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

[Antoine Martin]

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.

[Antoine Martin]

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.

[Antoine Martin]

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

[peterlong0210]

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

[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?

[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/

[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?

[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).

[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..

[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.

[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.

[peterlong0210]

Thank you for your advice and information :)

[migration script]

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