I tried to do with Xpra from version 0.14 to 0.16 (Beta of Winswitch)
The point is that I want to do audio transfer from the server to the client. Voice server originated from Xpra, but the client does not sound at all. It follows that Xpra not see PulseAudio? (?), Even though it is running and the other applications have no problem with that.
My system is Debian Stretch (64-bit version)
Client log
Server Pavucontrol
Client Pavucontrol
Wow - what a lot of unnecessary noise:
xpra start ssh:fervi@192.168.1.2:150 --speed=100 --auto-refresh-delay=5000 \ --packet-encoders=rencode --encoding=x264 --exit-with-children --pulseaudio \ --speaker=on --microphone=on --dbus-proxy --cursors=no --mmap=yes \ --video-encoders=x264 --speaker --microphone --min-quality=1 --quality=45 \ --compressors=lz4 --input-method=Ibus --compress=1 --video-decoders=avcodec2 \ --title='@title@ on Intinte Rasengan' --ssh='ssh -x -C' \ --csc-modules=opencl,swscale \ --start-child="/home/fervi/Intinte/Rasengan/vglconnect && /home/fervi/Intinte/Rasengan/vglrun $1 $2 $3 $4 $5 $6 $7 $8 $9"
Summary: don't use options unless you understand them and you know you need them.
Warning: cannot parse value 'yes -configdir /etc/xpra/xpra.conf.d' for 'displayfd' as a boolean
Sounds like your xpra.conf has a problem in it. Please post it. xpra.conf.d
what is this?
Now, on to sound proper: it looks like you are forwarding sound from an existing pulseaudio server running in your desktop session, right? The real problem comes from this:
could not detect any Pulseaudio monitor devices - sound forwarding is disabled
To debug this, run the pulseaudio util class (installed with xpra). This is what I get:
$ ./xpra/sound/pulseaudio_util.py device.alsa_input.pci-0000_00_1b.0.analog-stereo : Built-in Audio Analog Stereo device.alsa_output.pci-0000_00_1b.0.analog-stereo : Built-in Audio Analog Stereo device.alsa_output.pci-0000_00_1b.0.analog-stereo.monitor : Monitor of Built-in Audio Analog Stereo device.alsa_output.pci-0000_01_00.1.hdmi-stereo : HDA NVidia Digital Stereo (HDMI) device.alsa_output.pci-0000_01_00.1.hdmi-stereo.monitor : Monitor of HDA NVidia Digital Stereo (HDMI) device.audio-volume-change : Built-in Audio Analog Stereo devices : 4 pulseaudio.found : {a46a8bb32f244826a8fe08aba5c54d0c}unix:/run/user/1000/pulse/native pulseaudio.id : 1000@a46a8bb32f244826a8fe08aba5c54d0c/4839 pulseaudio.server : {a46a8bb32f244826a8fe08aba5c54d0c}unix:/run/user/1000/pulse/native pulseaudio.wrapper : pactl
Ok, I have reduced a little code.
The server has support for OpenCL, but Xpra does not support it (probably something wrong work). Just in case I did OpenCL, swscale, because if it does not OpenCL (as in this case) it would launched with swscale, which is faster in benchmarks from Cython
can not load csc_opencl (OpenCL colorspace conversion): ColorspaceConverter missing from xpra.codecs.csc_opencl.colorspace_converter: clEnqueueNDRangeKernel failed: out of resources RuntimeError: clEnqueueNDRangeKernel failed: out of resources 2015-07-14 12: 49: 14.113 csc csc_opencl module could not be loaded: clEnqueueNDRangeKernel failed: out of resources
/etc/xpra/xpra.conf.d
- I do not have this directory, I wanted to run Xfvb, but it did not work, so I abandoned it
I'm trying to find a configuration Xpra, which will allow for very quick in terms of productivity and burdens the communication network.
Client PulseAudio? Xpra Test
Server PulseAudio? Xpra test
About opencl: out of resources
probably means that your card, which you have not specified, cannot run the kernel we provide. No big loss.
If you really feel like debugging this issue, you can get more log output by running with -d opencl
.
Just in case I did OpenCL, swscale, because if it does not OpenCL (as in this case) it would launched with swscale, which is faster in benchmarks from Cython
That's already the default, Cython will only be used if the other two fail somehow.
So once again, you're just complicating things for absolutely zero benefit.
I'm trying to find a configuration Xpra, which will allow for very quick in terms of productivity and burdens the communication network.
Then you should start by understanding the options before you use them.
Xpra should be near optimal out of the box, the majority of the changes you made are actually detrimental to your goals.
Here's one I forgot to mention: ssh -C
is the worse thing you can add, it will make things considerably slower. Which is in the man page, BTW.
Now, as for this ticket, which is about pulseaudio.
It looks to me like the pulseaudio utility class did not detect any devices at all.
Please post pactl list
from both the client and server.
Pactl (1 line - Client) (469 line - Server)
r9957 makes it easier to see what the pulseaudio util class parses from the "pactl list" command line output.
After splitting your file into two:
$ ./xpra/sound/pulseaudio_pactl_util.py /home/antoine/Downloads/pactllist-client.txt 1 devices found in '/home/antoine/Downloads/pactllist-client.txt' * alsa_output.pci-0000_00_04.0.analog-stereo.monitor
$ ./xpra/sound/pulseaudio_pactl_util.py /home/antoine/Downloads/pactllist-server.txt 1 devices found in '/home/antoine/Downloads/pactllist-server.txt' * alsa_output.pci-0000_00_1b.0.analog-stereo.monitor
So this correctly detects the devices. My guess is that the environment you used is not the same. Not much I can do about that.
Client and Server gave something like this
2015-07-14 11:50:33,015 palib not available, using legacy pactl fallback
Maybe if I install something, then maybe I get palib support and it will working? Do you have any idea how to install palib?
palib is not the problem, it's optional.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/915