#673 closed defect (worksforme)
Change sound server option
Reported by: | peterlong0210 | Owned by: | peterlong0210 |
---|---|---|---|
Priority: | minor | Milestone: | 0.15 |
Component: | server | Version: | trunk |
Keywords: | Cc: |
Description
We should add an option to allow the user to select the sound
server to use on the server.
Change History (12)
comment:1 Changed 5 years ago by
Milestone: | future → 0.15 |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Priority: | major → minor |
Status: | new → assigned |
Summary: | Change sound server on the server → Change sound server option |
comment:2 Changed 5 years ago by
Owner: | changed from Antoine Martin to peterlong0210 |
---|---|
Status: | assigned → new |
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
.
comment:3 Changed 5 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Not heard back. Closing. (default should be unchanged anyway)
comment:4 Changed 5 years ago by
I'm sorry for the late response.
I resolved my trouble : use pulseaudio for windows client.
And I forgot reply this track. :)
comment:5 Changed 5 years ago by
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?
comment:6 Changed 5 years ago by
@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/
comment:7 Changed 5 years ago by
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?
comment:8 Changed 5 years ago by
@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).
comment:9 follow-up: 10 Changed 5 years ago by
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..
comment:10 Changed 5 years ago by
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.
comment:11 Changed 5 years ago by
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.
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.