Xpra: Ticket #1118: sink.py is not able to play sound in ubuntu 15.10 and xpra 0.16.2.

sink.py is not working properly to play sound recorded with src.py.

The xpra version is v0.16.2.

I have done some modification into it. And, then it is working properly. But, changes are not the exact changes, it may need some further modification. But, it worked for me.

I am attaching the modified sink.py.

The changes are done at line (355, 356), (358,359), (271,272,273)

Please accommodate these changes. So, that others may not face this issue.



Sun, 14 Feb 2016 09:31:53 GMT - Kundan: attachment set

sink.py file of xpra at location /usr/lib/python2.7/dist-packages/xpra.


Wed, 17 Feb 2016 15:39:47 GMT - Antoine Martin: owner changed

Again, please provide the changes in patch format (line numbers will not do), with some explanations of why those changes were needed.


Sun, 28 Feb 2016 09:53:35 GMT - Kundan:

Hi Antoine,

Here, is the error which I get with the default sink.py.

nishant@nishant-VirtualBox:~/Xpra/tags/v0.16.x/src/xpra/sound$ python sink.py ~/Documents/Hello12.vorbis
guessed codec vorbis from file extension vorbis
loaded 294562 bytes from /home/nishant/Documents/Hello12.vorbis
Traceback (most recent call last):
  File "sink.py", line 390, in <module>
    sys.exit(main())
  File "sink.py", line 355, in main
    QUEUE_LEAK = GST_QUEUE_NO_LEAK
NameError: global name 'GST_QUEUE_NO_LEAK' is not defined

I am attaching the changes which I have done in diff format. But, these are not the exact changes. It will need modification. I have commented out, which didn't worked for me.

But, after this change, I was able to play my vorbis file.

nishant@nishant-VirtualBox:~$ python /usr/lib/python2.7/dist-packages/xpra/sound/sink.py ~/Documents/Hello12.vorbis
guessed codec vorbis from file extension vorbis
loaded 294562 bytes from /home/nishant/Documents/Hello12.vorbis
2016-02-28 15:21:58,078 SoundSink(..) found matching codecs ['vorbis']
2016-02-28 15:21:58,488 add_data(294562 bytes, None) queue_state=starting
2016-02-28 15:21:58,489 pushed 294562 bytes, new buffer level:   0ms, queue state=starting
2016-02-28 15:21:58,553 using audio codec: Vorbis
2016-02-28 15:22:25,589 underrun (end of stream)
2016-02-28 15:22:25,589 stopping

Sun, 28 Feb 2016 09:55:57 GMT - Kundan: attachment set

sink.py changes to resolve LEAK error.


Sun, 28 Feb 2016 10:36:34 GMT - Antoine Martin:

The correct fixes are in r12094 + r12096 (r12095 for trunk).

With those changes I am able to play some MP3 files. Please close this ticket if it works for you.

A word of warning: the pipeline you get with "vorbis" is a gstreamer specific pipeline using gdp as container format, whereas 99.9% of media players will be expecting an ogg container - which we do not support. So the resulting file cannot be played with other tools. (most of the other non-gdp formats do not have this limitation)


Sun, 28 Feb 2016 16:09:50 GMT - Kundan:

Hi Antoine,

I tried to run the sink.py taking the latest r12096 in /Xpra/tags/v0.16.x

The command used was.

python src/xpra/sound/sink.py ~/Documents/Hello11.mp3

I got the similar error, what I used to get with src.py

assuming this is an mp3 file...
loaded 0 bytes from /home/nishant/Documents/Hello11.mp3
2016-02-28 21:36:40,125 SoundSink(..) found matching codecs []
Traceback (most recent call last):
  File "src/xpra/sound/sink.py", line 393, in <module>
    sys.exit(main())
  File "src/xpra/sound/sink.py", line 360, in main
    ss = SoundSink(codecs=codecs)
  File "src/xpra/sound/sink.py", line 78, in __init__
    raise InitExit(1, "no matching codecs between arguments '%s' and supported list '%s'" % (csv(codecs), csv(get_codecs().keys())))
xpra.scripts.config.InitExit: no matching codecs between arguments 'mp3' and supported list 'speex, wav, wavpack, flac, vorbis'

The file may be empty. But, it seems errors are real.

I am further attaching the debug output of both gstreamer_util.py and sink.py by prepending XPRA_SOUND_DEBUG=1.


Sun, 28 Feb 2016 16:11:43 GMT - Kundan: attachment set

gstreamer output log after prepending XPRA_SOUND_DEBUG=1


Sun, 28 Feb 2016 16:13:10 GMT - Kundan: attachment set

sink.py.output.log after prepending XPRA_SOUND_DEBUG=1


Sun, 28 Feb 2016 16:41:49 GMT - Kundan:

Hi Antoine,

I tried with playing the vorbis file as well. And it passed with your changes.

Command used and their output is as follows:-

nishant@nishant-VirtualBox:~/Xpra/tags/v0.16.x$ python src/xpra/sound/sink.py ~/Documents/Hello12.vorbis
guessed codec vorbis from file extension vorbis
loaded 294562 bytes from /home/nishant/Documents/Hello12.vorbis
2016-02-28 22:05:56,392 SoundSink(..) found matching codecs ['vorbis']
2016-02-28 22:05:56,465 add_data(294562 bytes, None) queue_state=starting
2016-02-28 22:05:56,472 pushed 294562 bytes, new buffer level:   0ms, queue state=starting
2016-02-28 22:05:56,475 using audio codec: Vorbis
2016-02-28 22:06:23,510 underrun (end of stream)
2016-02-28 22:06:23,511 stopping

Sun, 28 Feb 2016 17:27:01 GMT - Antoine Martin:

I tried with playing the vorbis file as well. And it passed with your changes.


That's because you have the vorbis gstreamer plugin in both gstreamer 1.x and 0.10

What is probably happening here is that you are using a different version of gstreamer when running the command line tools than when you run the gstreamer command line probing tool. I have fixed a similar bug in trunk recently: r12090 This change is scheduled to land in 0.16.x for the next stable update too.

Until then, you may be able to force the code to use a specific version of streamer by running with:

XPRA_GSTREAMER1=0 yourcommand.py ...

(or change to a 1)


Sat, 05 Mar 2016 17:13:50 GMT - Kundan:

Forcing the GSTREAMER to 1 isn't working.

Seems, like the problem is due to following Import Error.

ImportError: When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject". See: https://bugzilla.gnome.org/show_bug.cgi?id=709183

Seems, like importing and using gobject in the src.py and sink.py is causing issues.

I was not able to figure out anything more. I went to the provided bugzilla https address. There it has mentioned that it has disabled importing of some specific modules such as gobject.

Actually, I was not able to see any relation of it with r12090. Could you please clarify. As, it seems to me of some other bug.


Wed, 16 Mar 2016 06:14:11 GMT - Antoine Martin:

What branch and revision are you testing with? r12090 fixes exactly this problem: GTK3 uses the gi bindings, GTK2 uses the "pygst" bindings. We cannot mix and match, so we have to load the correct GTK / gobject version for the gstreamer bindings we load.


Wed, 16 Mar 2016 17:26:47 GMT - Kundan:

Hi Antoine,

I tried with Xpra/tags/v0.16.x/src/xpra/sound/src.py

The latest revision, as shown by my svn log is r12110. The revision, r12090 shows listed there.

It seems, may be your fix works, But it would affect those who uses wrapper.py. As, your changes are in wrapper.py.

But, what I am suspecting is that src.py and sink.py uses gstreamer_util.py directly, And that seems to be not handling the erroneous case.

A snip of the error getting reported.

2016-03-16 22:41:54,044 trying to import GStreamer 1.0 using <function import_gst1 at 0x7f341ddbcb90>
2016-03-16 22:41:54,044 import_gst1()
2016-03-16 22:41:54,045 Warning failed to import GStreamer 1.0
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/sound/gstreamer_util.py", line 297, in import_gst
    _gst = import_function()
  File "/usr/lib/python2.7/dist-packages/xpra/sound/gstreamer_util.py", line 172, in import_gst1
    import gi
  File "/usr/lib/python2.7/dist-packages/gi/__init__.py", line 39, in <module>
    raise ImportError(_static_binding_error)
ImportError: When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject". See: https://bugzilla.gnome.org/show_bug.cgi?id=709183
2016-03-16 22:41:54,046 GStreamer 0.10 environment: {'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games'}

Also, attaching the src.log with the latest r12110.

I would also like to specify first some lines of my svn log.

------------------------------------------------------------------------
r12110 | antoine | 2016-02-29 20:32:59 +0530 (Mon, 29 Feb 2016) | 1 line
r12048 for v0.16.x branch: fix pulseaudio sound input device selection client side
------------------------------------------------------------------------
r12107 | antoine | 2016-02-29 20:24:33 +0530 (Mon, 29 Feb 2016) | 1 line
r12090 for v0.16.x branch: gstreamer 1.x on gtk2 compatibility fix
------------------------------------------------------------------------
r12096 | antoine | 2016-02-28 16:01:18 +0530 (Sun, 28 Feb 2016) | 1 line
r12095 for v0.16.x branch: fix sound command line use
------------------------------------------------------------------------
r12094 | antoine | 2016-02-28 15:42:18 +0530 (Sun, 28 Feb 2016) | 1 line
#1118 fix missing import
------------------------------------------------------------------------
r12046 | antoine | 2016-02-25 09:33:35 +0530 (Thu, 25 Feb 2016) | 1 line
r12044 for v0.15.x and v0.16.x branches: remote extraneous character causing sound-source options parsing errors

Wed, 16 Mar 2016 17:27:42 GMT - Kundan: attachment set

src log output.


Thu, 17 Mar 2016 01:02:43 GMT - Kundan: owner changed


Fri, 18 Mar 2016 14:44:01 GMT - Antoine Martin: status changed; resolution set

Sorry but this is not fixable without some major surgery and I don't have time for this: the classes found in src and sink would have to be moved to another file or we would have to delay their definition. That's because the source and sink classes subclass gobject, and so we need to have gobject imported early, before we can choose which version of gstreamer we can load.


Sat, 19 Mar 2016 04:00:07 GMT - Antoine Martin: status changed; resolution deleted

Actually, I have just thought of a better way of doing this: instead of moving the gstreamer bits around (which would be too big a change), just tweak the gobject loading code to be more "gstreamer aware" (look for the presence of the "gi bindings" to decide what to do).


Sat, 19 Mar 2016 04:02:48 GMT - Antoine Martin: owner, status changed

Done in r12166 (though trunk was not actually affected by this problem), applied to v0.16.x in r12168.

With this change, my Ubuntu 15.10 VM can run the sound utility with the gstreamer 1.x bindings without erroring out. It doesn't actually play an MP3 properly (just spits it out at the sound card way too quickly so you get just noise...), but that's a different problem - and I'm not sure I care.

@kundanvp: does this work for you?


Sat, 19 Mar 2016 12:56:05 GMT - Kundan:

Hi Antoine,

Yes, now src.py is able to record mp3 sound properly. However, I needed to change the monitor device which appears in pavucontrol recording tab to regular device, to do the actual sound recording from the device.

One more thing which, it seems you have already noticed.

sink.py is not able to play that mp3. It says, underrun (end of stream). However, I was able to play the mp3 file created with some other application like videos, or vlc media player.

So, it seems, src.py has started functioning. But in sink.py still there are some issues. But, it's a different matter whether we need it's fixing or not. I am attaching the sink.py logs. But, it's entirely your decision to fix it or not.


Sat, 19 Mar 2016 13:00:55 GMT - Kundan: attachment set

sink.py log, where it is failing to play mp3 file.


Sat, 19 Mar 2016 13:04:01 GMT - Kundan:

It seems, it is failing to play vorbis file as well, which earlier worked.


Fri, 15 Apr 2016 14:37:37 GMT - Antoine Martin: owner, status, milestone changed

I don't have time to look into this, re-scheduling.


Tue, 12 Jul 2016 16:51:50 GMT - Antoine Martin: milestone changed

Milestone renamed


Sun, 21 Aug 2016 09:55:49 GMT - Antoine Martin: milestone changed

Milestone renamed


Fri, 30 Dec 2016 07:01:34 GMT - Antoine Martin: owner, status changed

Is this still an issue with version 1.0?


Mon, 23 Jan 2017 10:06:41 GMT - Antoine Martin: status changed; resolution set

Not heard back.


Sat, 23 Jan 2021 05:15:28 GMT - migration script:

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