speaker forwarding may cause server to hang

[totaam]

Issue migrated from trac ticket # 669

component: sound | priority: critical | resolution: fixed

2014-09-04 10:42:32: onlyjob created the issue

---

Attaching/disconnecting with speaker forwarding sometimes leaves server in unresponsive state.
Here are fragments ofom server log taken with "-d sound":

Server started:

2014-09-04 19:10:39,969 xpra server version 0.14.4 (7467)
2014-09-04 19:10:39,969 running with pid 9207
E: [pulseaudio] pid.c: Daemon already running.
2014-09-04 19:10:40,012 child 'pulseaudio' with pid 9219 has terminated
2014-09-04 19:10:40,098 xpra is ready.
2014-09-04 19:10:41,965 Warning: pulseaudio has terminated. Either fix the pulseaudio command line or use --no-pulseaudio to avoid this warning.
2014-09-04 19:10:41,965  usually, only a single pulseaudio instance can be running for each user account, and one may be running already

Client attached and disconnected (1st time, all good):

2014-09-04 19:11:28,295 new_sound_buffer(<SoundSource object at 0x7f2fea99f7d0 (xpra+sound+src+SoundSource at 0x237fec0)>, 60, {'duration': 500000000L, 'timestamp': 285000
00000L}) source=<SoundSource object at 0x7f2fea99f7d0 (xpra+sound+src+SoundSource at 0x237fec0)>, suspended=False, sequence=-1
2014-09-04 19:11:28,793 new_sound_buffer(<SoundSource object at 0x7f2fea99f7d0 (xpra+sound+src+SoundSource at 0x237fec0)>, 60, {'duration': 500000000L, 'timestamp': 290000
00000L}) source=<SoundSource object at 0x7f2fea99f7d0 (xpra+sound+src+SoundSource at 0x237fec0)>, suspended=False, sequence=-1
2014-09-04 19:11:29,005 Connection lost
2014-09-04 19:11:29,006 stop_sending_sound() sound_source=<SoundSource object at 0x7f2fea99f7d0 (xpra+sound+src+SoundSource at 0x237fec0)>
2014-09-04 19:11:29,006 xpra client disconnected.
2014-09-04 19:11:29,006 stop_sending_sound_thread(())
2014-09-04 19:11:29,007 SoundPipeline.cleanup()
2014-09-04 19:11:29,007 SoundPipeline.stop()
2014-09-04 19:11:29,008 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from wavpackenc0 at 0x2659530>
2014-09-04 19:11:29,008 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from volume at 0x26594b0>
2014-09-04 19:11:29,008 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from audioconvert0 at 0x2659430>
2014-09-04 19:11:29,008 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from pulsesrc0 at 0x2659330>
2014-09-04 19:11:29,008 new-state=PAUSED
2014-09-04 19:11:29,009 SoundPipeline.stop() done
2014-09-04 19:11:29,009 SoundPipeline.cleanup() done
2014-09-04 19:11:29,009 stop_sending_sound_thread(()) done

Client attached and disconnected (2nd try, still good):

2014-09-04 19:11:47,894 new_sound_buffer(<SoundSource object at 0x7f2fea99f870 (xpra+sound+src+SoundSource at 0x7f2fa8002500)>, 60, {'duration': 500000000L, 'timestamp': 7
000000000L}) source=<SoundSource object at 0x7f2fea99f870 (xpra+sound+src+SoundSource at 0x7f2fa8002500)>, suspended=False, sequence=-1
2014-09-04 19:11:48,393 new_sound_buffer(<SoundSource object at 0x7f2fea99f870 (xpra+sound+src+SoundSource at 0x7f2fa8002500)>, 60, {'duration': 500000000L, 'timestamp': 7
500000000L}) source=<SoundSource object at 0x7f2fea99f870 (xpra+sound+src+SoundSource at 0x7f2fa8002500)>, suspended=False, sequence=-1
2014-09-04 19:11:48,841 client Protocol(SocketConnection(/home/hawk/.xpra/debstor-22)) has requested disconnection: exit on signal SIGINT
2014-09-04 19:11:48,841 Disconnecting client Protocol(SocketConnection(/home/hawk/.xpra/debstor-22)): client request
2014-09-04 19:11:48,842 stop_sending_sound() sound_source=<SoundSource object at 0x7f2fea99f870 (xpra+sound+src+SoundSource at 0x7f2fa8002500)>
2014-09-04 19:11:48,842 stop_sending_sound_thread(())
2014-09-04 19:11:48,842 SoundPipeline.cleanup()
2014-09-04 19:11:48,842 xpra client disconnected.
2014-09-04 19:11:48,843 SoundPipeline.stop()
2014-09-04 19:11:48,844 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from wavpackenc1 at 0x7f2fa4001ec0>
2014-09-04 19:11:48,844 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from volume at 0x7f2fa4001f40>
2014-09-04 19:11:48,844 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from audioconvert1 at 0x2674850>
2014-09-04 19:11:48,844 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_VOID_PENDING; from pulsesrc1 at 0x26748d0>
2014-09-04 19:11:48,845 new-state=PAUSED
2014-09-04 19:11:48,845 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_PLAYING, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)G
ST_STATE_READY; from sink at 0x26749d0>
2014-09-04 19:11:48,845 SoundPipeline.stop() done
2014-09-04 19:11:48,845 SoundPipeline.cleanup() done
2014-09-04 19:11:48,845 stop_sending_sound_thread(()) done

3rd attach, renders empty windows:

2014-09-04 19:11:58,224 New connection received: SocketConnection(/home/hawk/.xpra/debstor-22)
2014-09-04 19:12:02,211 Handshake complete; enabling connection
2014-09-04 19:12:02,215 pulseaudio id=, server=, sound decoders=['wavpack'], sound encoders=['wavpack', 'flac', 'wav', 'speex'], receive=True, send=True
2014-09-04 19:12:02,216 Python/Gtk2 Linux client version 0.14.4 connected from 'deblab' as 'hawk' ('hawk')
2014-09-04 19:12:02,216 client supplied an mmap_file: /tmp/xpra.xdWpza.mmap but we cannot find it
2014-09-04 19:12:02,216 using rgb as primary encoding, also available: h264, vp8, png, png/P, png/L, webp, rgb24, jpeg, rgb32
2014-09-04 19:12:02,216 client root window size is 4400x2560 with 1 displays:
2014-09-04 19:12:02,216   ':0.0' (1161x675 mm) workarea: 4400x2527 at 0x33
2014-09-04 19:12:02,216     DisplayPort-1 1280x1024 at 0x1536 (360x270 mm)
2014-09-04 19:12:02,217     DVI-0 1440x2560 at 1280x0 (597x336 mm)
2014-09-04 19:12:02,217     DisplayPort-0 1680x1050 at 2720x1510 (474x296 mm)
2014-09-04 19:12:02,217 best resolution matching 4400x2560 is unchanged: 5120x3200
2014-09-04 19:12:02,219 setting key repeat rate from client: 660ms delay / 40ms interval
2014-09-04 19:12:02,221 keyboard mapping already configured (skipped)
2014-09-04 19:12:02,232 pactl_output('list',) returned 0
2014-09-04 19:12:02,242 pactl_output('list',) returned 0
2014-09-04 19:12:02,252 pactl_output('list',) returned 0
2014-09-04 19:12:02,264 pactl_output('list',) returned 0
2014-09-04 19:12:02,314 sound_control(start, ('wavpack',))
2014-09-04 19:12:02,314 start_sending_sound(wavpack)
2014-09-04 19:12:02,314 using sound codec wavpack
2014-09-04 19:12:02,327 pactl_output('stat',) returned 0
2014-09-04 19:12:02,327 get_pactl_stat_line(Server String:)=/tmp/pulse-8XiBnTK3trYQ/native
2014-09-04 19:12:02,328 start sound, remote pulseaudio server=, local pulseaudio server=/tmp/pulse-8XiBnTK3trYQ/native
2014-09-04 19:12:02,328 start sound, client id=, server id=
2014-09-04 19:12:02,341 pactl_output('list',) returned 0
2014-09-04 19:12:02,341 found pulseaudio monitor devices: {'auto_null.monitor': 'Monitor of Dummy Output'}
2014-09-04 19:12:02,353 pactl_output('set-source-mute', 'auto_null.monitor', '0') returned 0
2014-09-04 19:12:02,354 set_source_mute: output=
2014-09-04 19:12:02,354 pipeline elements=['pulsesrc device=auto_null.monitor', 'audioconvert', 'volume name=volume volume=1.0', 'wavpackenc', None, 'appsink name=sink']
2014-09-04 19:12:02,354 pipeline=pulsesrc device=auto_null.monitor ! audioconvert ! volume name=volume volume=1.0 ! wavpackenc ! appsink name=sink
2014-09-04 19:12:02,357 starting sound capture using pulseaudio device: Monitor of Dummy Output
2014-09-04 19:12:02,357 start_sending_sound() sound source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>
2014-09-04 19:12:02,357 SoundPipeline.start()
2014-09-04 19:12:02,362 SoundPipeline.start() done
2014-09-04 19:12:02,363 state changed: <gst.Message GstMessageState, old-state=(GstState)GST_STATE_NULL, new-state=(GstState)GST_STATE_READY, pending-state=(GstState)GST_S
TATE_VOID_PENDING; from sink at 0x26749d0>
2014-09-04 19:12:05,188 new preroll0: 112 bytes
2014-09-04 19:12:05,189 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 112, {'duration': 500000000L, 'timestamp': 
0L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:05,189 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 112, {'duration': 500000000L, 'timestamp': 
0L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:05,688 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
00000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:06,186 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 1
000000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:06,685 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 1
500000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1

After disconnect server keeps logging:

2014-09-04 19:12:57,173 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
2000000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:57,682 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
2500000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:58,181 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
3000000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:58,680 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
3500000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:59,178 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
4000000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:12:59,677 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
4500000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:13:00,176 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
5000000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1
2014-09-04 19:13:00,674 new_sound_buffer(<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, 60, {'duration': 500000000L, 'timestamp': 5
5500000000L}) source=<SoundSource object at 0x7f2fe822c6e0 (xpra+sound+src+SoundSource at 0x7f2fdc0021a0)>, suspended=False, sequence=-1

At this point server do not respond to new connections so I terminate it with "kill -9".

Workaround: attach with --no-speaker.

This is a very old issue which I can reproduce easily with 0.14.4.

[totaam]

Can you check if maybe we're leaking something every time we start + stop sound? Maybe run it without limits, and / or even as root to try?
This would cause us to hit some limit eventually (file descriptors?), which could explain why some things still run (new_sound_buffer) but others become unresponsive.

[totaam]

See also: #663, #400#comment:8.

[totaam]

2014-09-23 14:34:29: totaam uploaded file clipboard-loop.txt (86.2 KiB)

backtrace from a deep clipboard loop

[totaam]

Well, well, maybe I can reproduce this after all.
I was investigating something completely different and I think I managed to reproduce it semi reliably with:

• linux laptop with normal cinnamon session, start shadow:

xpra shadow :0 --bind-tcp=0.0.0.0:PORT

• connect to it from a ms windows xp vm:

xpra_cmd.exe attach tcp:HOST:PORT

The trick here was to also have synergy syncing the clipboard between the laptop and the host running the xp vm, as well as virtualbox doing more clipboard synchronization between the host and the xp vm, then finally we have xpra doing clipboard sync between the laptop and xp... full circle.

At one point, I saw 90+ kworker threads in my process list - they eventually cleared themselves.

But I also managed to lockup the laptop's display, requiring a reboot (killing X11 would have done it too I suppose).

Interestingly, killing a stuck server made it spit out:

2014-09-23 20:30:43,823 xpra client disconnected.
2014-09-23 20:30:43,827 loop nesting too deep: 10
2014-09-23 20:30:43,827 you may have a clipboard forwarding loop, disabling the clipboard
2014-09-23 20:30:43,828 New connection received: SocketConnection(('192.168.42.103', 10000) - ('192.168.42.195', 1316))
2014-09-23 20:30:43,829 New connection received: SocketConnection(/home/antoine/.xpra/laptop-0)
2014-09-23 20:30:43,830 New connection received: SocketConnection(/home/antoine/.xpra/laptop-0)
2014-09-23 20:30:43,831 New connection received: SocketConnection(/home/antoine/.xpra/laptop-0)
2014-09-23 20:30:43,831 New connection received: SocketConnection(/home/antoine/.xpra/laptop-0)
2014-09-23 20:30:43,832 New connection received: SocketConnection(/home/antoine/.xpra/laptop-0)
2014-09-23 20:30:43,833 New connection received: SocketConnection(/home/antoine/.xpra/laptop-0)
2014-09-23 20:30:43,849 client Protocol(SocketConnection(('192.168.42.103', 10000) - ('192.168.42.195', 1315))) has requested disconnection: exit on signal SIGINT
2014-09-23 20:30:43,849 Disconnecting client Protocol(SocketConnection(('192.168.42.103', 10000) - ('192.168.42.195', 1315))): client request
2014-09-23 20:30:43,850 internal error: read connection SocketConnection(('192.168.42.103', 10000) - ('192.168.42.195', 1316)) reset: [Errno 104] Connection reset by peer
2014-09-23 20:30:43,856 Handshake complete; enabling connection
2014-09-23 20:30:43,857 Python/Gtk2 Microsoft Windows XP client version 0.15.0 connected from 'XP-Pro-Dev-VBOX' as 'XPPro' ('XPPro')
2014-09-23 20:30:43,857 using h264 as primary encoding, also available: vp8, png, png/P, png/L, webp, rgb24, jpeg, rgb32
2014-09-23 20:30:43,857 client root window size is 1575x1177
2014-09-23 20:30:43,858 shadow server: setting default keymap translation
2014-09-23 20:30:43,907 Connection lost
2014-09-23 20:30:43,907 Connection lost
2014-09-23 20:30:43,907 Connection lost
2014-09-23 20:30:43,907 Connection lost
2014-09-23 20:30:43,907 Connection lost
2014-09-23 20:30:43,907 Connection lost

@onlyjob: can you reproduce your problem with clipboard disabled? (I cannot so far)

[totaam]

I've now connected well over a hundred times (scripted detach, with attach in a while true loop). No problem as long as the clipboard is disabled.
I think that sound just makes it worse as it relies on the main loop to be running to get the data out of gstreamer + pulseaudio in time. But maybe there are other ways of getting the main loop stuck than the clipboard?

Maybe I made things worse with r7751? As it will cause a timeout on the main loop waiting for the reply to the message that causes us to stop the clipboard. I don't think so, as the main loop should still be running, just nested. But maybe this nesting doesn't play well with gstreamer?
Worst case scenario: we have to rewrite the ugly clipboard nested loop code, or move the sound code to its own process (using multiprocessing).

@onlyjob: if you can reproduce this problem with the clipboard disabled, please provide a gdb backtrace.

[totaam]

2014-10-02 18:14:29: onlyjob commented

---

That's right, I can't reproduce when attaching with --no-clipboard.

[totaam]

I have finally managed to reproduce this one. I had to kill -9 the server and use xpra start --use-display to recover the session.

It took a laptop running the Fedora 21 alpha as server, and just my regular Fedora 20 client. Just a shame I am going away (hence the laptop upgrade)... this will have to wait until I get back.

[totaam]

I have an idea: until we rewrite the clipboard using native calls (which would be nice as it would get rid of the ugly nested loop hack - but this is going to take a long time), we can move the sound code to its own process using multiprocessing - which means it will get its own main loop, independent of the clipboard code. It is Python 2.6+ only, which is fine for v0.15+.
We can push sound data using a multiprocessing queue, and to get the events back out maybe we have to keep a thread around, just waiting for the out queue.
It also means that this process will be less subjected to latency issues found in the main process, so less likely to get overruns.

[totaam]

2014-11-19 04:04:30: onlyjob commented

---

I love this idea. :) Debian dropped Python-2.6 and 2.7 is in Wheezy for a while so I believe it is worth abandoning support for 2.6 in order to benefit from multiprocessing.

[totaam]

multiprocessing is available since python 2.6

Unfortunately, it just doesn't work with pygst, which relies on the gobject main loop and we cannot run two copies of the main loop...

The only solution that I can see would be to use a distinct subprocess that we spawn and talk to using pipes: we could use its stdin to send it messages (set_volume and stop? anything else? stop can be done with sigint) and get the compressed sound data from its stdout? Better yet would be to use mmap and re-use our video mmap code.

[totaam]

2015-02-16 07:08:28: antoine uploaded file sound-separate-process.patch (11.6 KiB)

moves the sound capture / play to a separate process - hackish

[totaam]

The patch above is very hackish and would need cleaning up. It only handles sound capture via a separate process, not playback.

It doesn't handle any message exchange, we just assume the data is the compressed sound buffers.. (don't want to add the network layer there if it can be avoided)

It doesn't handle mmap transfers which would cave us a lot of unnecessary events and process context switching, if only we had an easy way of signalling the parent that some data is available without writing to the pipe. Can't see how.

That said, it works very well and start + stop are very reliable.

[totaam]

Things left to do:

• cleanups
• get list of supported codecs by execing the helper? (and allow python3 to be used..)
• hangle get_info with timer + receiver caching
• binary files on win32 need special coding?
• use child reaper?
• implement speaker side
• remove / replace / fix the win32 executables?

[totaam]

Latest status: the win32 client seems to suffer from clock drift. But maybe this isn't a gstreamer pipeline clock drift but rather a system clock problem?? (added the "time" metadata attribute to see how this changes over time)

Notes:

• we forward the volume calls using ints, so we use the 0 to 100 range instead of 0.0 to 1.0 (which is a little confusing.. maybe we should just expose 0 to 100 only?)
• we send the "info" data every second, and use this to pass back values like "volume", "codec description", etc..
• the "time" metadata attribute is only used for debugging

Latest TODO list:

• underruns: seems that the pipeline stops in some cases if we get too many underruns... (need a reliable way of dealing with this)
• got a sound codec change not supported! (from flac to wavpack) - not sure why! (disabled wav to get going - will need fixing properly)
• verify start / stop from tray, from xpra control, etc
• verify error handling (ie: killing sound process) - looks OK

Later:

• support gstreamer 1.0 via python3 with a python2 client (implies checking for codec availability probing via exec)
• also split the wrapper into a superclass and a subclass for each of sink and src
• prioritize sound packets in the network layer so we can jump the queue
• maybe handle wav + lz4 via network layer (keep track of which container formats are actually compressed in the CODEC_OPTIONS data, then compress those that aren't in the network thread of the sound process) - because lz4 is fast! (but only lz4 or lzo, we don't want to use zlib on sound data)
• support mmap transfers: move the mmap code to the protocol layer rather than having it grafted on top
• pass-through to client (for mmap or UDP..)
• sound improvements - better queue handling, refactoring and cleanups #400: encoder options, stereo vs 5.1, quality tuning
• volume control somewhere

[totaam]

Finally applied in r8786. See long commit message for details.
(only very minor differences since v11 patch)

Some new environment variables (which should not be needed - I hope):

• XPRA_SOUND_INFO_TIME allows us to specify how often we export the pipeline info from the subprocess back to the main xpra process, default is 1000 (every second)
• XPRA_SOUND_SUBPROCESS_DEBUG can be used to enable debugging flags in the subprocess exclusively (ie: XPRA_SOUND_SUBPROCESS_DEBUG=sound,win32,util xpra attach ..)
• XPRA_SOUND_DEBUG=1 enables verbose debugging in hot paths (which is why it isn't a standard -d sound debugging option)

@afarr: what needs testing:

• start and stop sound (we should not be leaving any zombies behind on Linux), should work reliably on all platforms
• killing the sound process should also trigger the change in status so the sound can be restarted from the tray (you can find the process using ps -ef | grep _sound, or as of r8787 the pid will be shown in session-info features)
• underruns and overruns (see update to sound improvements - better queue handling, refactoring and cleanups #400)

Please re-assign to me so that I can try to close the remaining issues (as per comment:13 - though many are likely to be re-scheduled unless critical)