Testing with osx client 0.16.0 r10828 against a 0.16.0 r10786 server, I happened to use the server control channel to stop sound-output, but when I immediately tried to start it again, there was a message that "None" had been started.
[tlaloc@jimador ~]$ xpra control :13 sound-output stop X11ServerSource(Protocol(tcp socket: 10.0.32.136:2200 <- 10.0.11.153:52981)) : stopped [tlaloc@jimador ~]$ xpra control :13 sound-output start X11ServerSource(Protocol(tcp socket: 10.0.32.136:2200 <- 10.0.11.153:52981)) : started None [tlaloc@jimador ~]$ xpra control :13 sound-output resume X11ServerSource(Protocol(tcp socket: 10.0.32.136:2200 <- 10.0.11.153:52981)) : unknown sound action: resume
The stop command worked as expected, stopping the sound. The start, on the other hand, did as it said and started nothing.
I also tried "resume", in case I was just remembering wrong... but looks like not so much.
If you look at your server log (and you always should do that), you would have seen and reported:
Warning: invalid codec specified: None
You needed to specify which codec you want to use, ie:
xpra control :13 sound-output start vorbis
r10840 will choose one for you if you don't specify one, so this will now also work:
xpra control :13 sound-output start
I'll see about testing that shortly - but I had my sound apparently break leaving a session run overnight. I tried the speaker on/off (well, technically off/on) to see about restarting and got the following traceback (seems like it might be related to this ticket)
Traceback (most recent call last): File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 792, in check_enabled File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 731, in spk_on TypeError: start_receiving_sound() takes exactly 2 arguments (1 given)
(Yes, I'll re-test that as well, just wanted to make the note before I lose it.)
This should be fixed in r10860.
How did it break? What were the messages? (and should we be re-starting it?)
I'm not sure how it is breaking exactly... I can only repro by leaving sound running in an idle session over night - but I see absolutely no output server side during the idle period, and the only thing I see client side is the periodic (every 20 seconds it looks like) message on an OSX client that the UI thread is blocked/running.
I do see an occasional message or two, in the middle of the night, about spinners on the client side:
2015-10-22 10:27:26,671 server is not responding, drawing spinners over the windows 2015-10-22 10:27:32,214 server is OK again
... which I suspect to be related.
Perhaps a patch for a client that will output audio status after recovering from a spinners episode? (In the meantime, I'll see if I can't spot, though
-d sound logs for a 6-8 hour stretch are a daunting prospect... I might try though with a grep for the spinner message and search the nearby vicinity?)
All that aside, I will close this ticket, and open another regarding what's toggling the sound off if I manage to pin it down.
Note about the sound turning off: the "server is OK again" message comes 6 seconds after the "not responding" message, which is longer than has been reported elsewhere. It could be a network drop out, maybe some service being restarted overnight? Does it happen always around the same time? This should be tracked in #855. Packet delays should not cause the sound to stop. There is one thing that can cause the sound process to stop without logging a message: if it gets killed. This could happen if the OS decides to kill it, for example if it uses too much memory.
See also #986
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1003