I see this in the console at the client, approximately twice per second.
Based on information in the output, I tried using --no-speaker and this seems to silence the errors.
I do not have a headphones connected (though I do have a soundcard) so I did not test that audio was working.
Client and sever are both the same:
$ rpm -q xpra xpra-0.9.0-23.el6.x86_64 $ cat /etc/system-release Scientific Linux release 6.3 (Carbon)
Here is the full output of a session without --no-speaker:
$ xpra attach --opengl=no ssh:nelligan.mtl:100 xpra client version 0.9.0 Xlib: extension "RANDR" missing on display ":0.0". 2013-04-24 11:51:44,297 signal_safe_exec(['setxkbmap', '-query'],None) stdout='' 2013-04-24 11:51:44,297 signal_safe_exec(['setxkbmap', '-query'],None) stderr='Error! Option "-query" not recognized ' 2013-04-24 11:51:44,297 '['setxkbmap', '-query']' failed with exit code 255 2013-04-24 11:51:44,297 the server will try to guess your keyboard mapping, which works reasonably well in most cases 2013-04-24 11:51:44,298 however, upgrading 'setxkbmap' to a version that supports the '-query' parameter is preferred 2013-04-24 11:51:45,479 Server's virtual screen is too small -- (server: 3840x1200 vs. client: 4800x1200) You may see strange behavior. Please see https://www.xpra.org/trac/ticket/10 2013-04-24 11:51:45,510 Attached to ssh:nelligan.mtl:100 (press Control-C to detach) 2013-04-24 11:51:50,594 unknown tag message: <gst.Message taglist, container-format=(string)Ogg; from oggdemux0 at 0x7fcca4001880> 2013-04-24 11:51:50,957 using audio codec: FLAC 2013-04-24 11:51:50,960 sound source pipeline error: GStreamer encountered a general stream error. / gstbasesrc.c(2543): gst_base_src_loop (): /GstPipeline:pipeline0/GstAppSrc:src: streaming task paused, reason not-negotiated (-4) 2013-04-24 11:51:51,486 push-buffer error: <enum GST_FLOW_WRONG_STATE of type GstFlowReturn> 2013-04-24 11:51:52,004 push-buffer error: <enum GST_FLOW_WRONG_STATE of type GstFlowReturn> 2013-04-24 11:51:52,522 push-buffer error: <enum GST_FLOW_WRONG_STATE of type GstFlowReturn> 2013-04-24 11:51:53,051 push-buffer error: <enum GST_FLOW_WRONG_STATE of type GstFlowReturn> [...]
Looks like a problem with the flac gstreamer plugin. I'm not getting this error here (Fedora 18
), but then again Scientific Linux release 6.3 (Carbon)
is pretty old.
Since you didn't change any sound settings, that means you don't have the required plugins installed for mp3 support, which is more tested/reliable and is first in the list of plugins to try.
You can install the gstreamer plugins from the gstreamer-plugins-*
packages.
So I've moved flac to the end of the list in r3139. Assuming that you have wav or wavpack gstreamer plugins installed, this should get selected ahead of flac now, and those generally work better too.
The client should detect that the pipeline is in the wrong state and stop trying to process sound, that's what I'll fix next. I should be able to find a way to simulate your pipeline state.
r3140 should fix these sorts of log flooding problems by stopping the sound when an error occurs (for whatever reason). You should see:
sound source pipeline error: GStreamer encountered a general stream error. \ / gstbasesrc.c(2543): gst_base_src_loop (): \ /GstPipeline:pipeline0/GstAppSrc:src: streaming task paused, reason not-negotiated (-4) push-buffer error: <enum GST_FLOW_WRONG_STATE of type GstFlowReturn> stopping sound because of error
Can you please try the latest beta packages (0.9.0-24
) and let me know if that works for you?
Note: the latest packages also have the plugin order change, so in order to reproduce the flac problem you were having you may have to add this to the command line:
--speaker-codec=flac
to ensure flac is used ahead of the rest.
Thanks, I'll try the latest beta when I get a chance.
not heard back, closing - feel free to re-open if problems persist.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/324