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.
sink.py file of xpra at location /usr/lib/python2.7/dist-packages/xpra.
Again, please provide the changes in patch format (line numbers will not do), with some explanations of why those changes were needed.
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
sink.py changes to resolve LEAK error.
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)
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.
gstreamer output log after prepending XPRA_SOUND_DEBUG=1
sink.py.output.log after prepending XPRA_SOUND_DEBUG=1
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
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)
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.
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.
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
src log output.
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.
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).
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?
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.
sink.py log, where it is failing to play mp3 file.
It seems, it is failing to play vorbis file as well, which earlier worked.
I don't have time to look into this, re-scheduling.
Milestone renamed
Milestone renamed
Is this still an issue with version 1.0?
Not heard back.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1118