Xpra: Ticket #1003: server control channel isn't re-starting sound-output after stopping

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.



Thu, 15 Oct 2015 04:31:49 GMT - Antoine Martin: owner changed

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

Thu, 15 Oct 2015 17:26:24 GMT - alas:

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


Fri, 16 Oct 2015 02:27:40 GMT - Antoine Martin:

Good catch!

This should be fixed in r10860.

How did it break? What were the messages? (and should we be re-starting it?)


Thu, 22 Oct 2015 17:32:44 GMT - alas: status changed; resolution set

The server control channel speaker-output start is working again as of 0.16.0 r10922 OSX client and 0.16.0 r10916 fedora 21 server.

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.


Fri, 23 Oct 2015 04:27:09 GMT - Antoine Martin:

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


Sat, 23 Jan 2021 05:12:11 GMT - migration script:

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