xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 2 years ago

#1118 closed defect (needinfo)

sink.py is not able to play sound in ubuntu 15.10 and xpra 0.16.2.

Reported by: Kundan Owned by: Kundan
Priority: major Milestone: 2.0
Component: sound Version: trunk
Keywords: Cc:

Description

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.

Attachments (6)

sink.py (14.8 KB) - added by Kundan 3 years ago.
sink.py file of xpra at location /usr/lib/python2.7/dist-packages/xpra.
sink_changes.diff (1.2 KB) - added by Kundan 3 years ago.
sink.py changes to resolve LEAK error.
gstreamer_output.log (11.6 KB) - added by Kundan 3 years ago.
gstreamer output log after prepending XPRA_SOUND_DEBUG=1
sink.py.output.log (8.5 KB) - added by Kundan 3 years ago.
sink.py.output.log after prepending XPRA_SOUND_DEBUG=1
src.log (9.0 KB) - added by Kundan 3 years ago.
src log output.
sink.log (13.6 KB) - added by Kundan 3 years ago.
sink.py log, where it is failing to play mp3 file.

Download all attachments as: .zip

Change History (26)

Changed 3 years ago by Kundan

Attachment: sink.py added

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

comment:1 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to Kundan

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

comment:2 Changed 3 years ago by Kundan

Hi Antoine,

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

[email protected]:~/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.

[email protected]:~$ 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

Changed 3 years ago by Kundan

Attachment: sink_changes.diff added

sink.py changes to resolve LEAK error.

comment:3 Changed 3 years ago by 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)

comment:4 Changed 3 years ago by 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.

Changed 3 years ago by Kundan

Attachment: gstreamer_output.log added

gstreamer output log after prepending XPRA_SOUND_DEBUG=1

Changed 3 years ago by Kundan

Attachment: sink.py.output.log added

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

comment:5 Changed 3 years ago by 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:-

[email protected]:~/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

comment:6 Changed 3 years ago by 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)

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by 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

Changed 3 years ago by Kundan

Attachment: src.log added

src log output.

comment:10 Changed 3 years ago by Kundan

Owner: changed from Kundan to Antoine Martin

comment:11 Changed 3 years ago by Antoine Martin

Resolution: wontfix
Status: newclosed

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.

comment:12 Changed 3 years ago by Antoine Martin

Resolution: wontfix
Status: closedreopened

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

comment:13 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to Kundan
Status: reopenednew

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?

comment:14 Changed 3 years ago by 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.

Changed 3 years ago by Kundan

Attachment: sink.log added

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

comment:15 Changed 3 years ago by Kundan

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

comment:16 Changed 3 years ago by Antoine Martin

Milestone: 0.171.0
Owner: changed from Kundan to Antoine Martin
Status: newassigned

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

comment:17 Changed 3 years ago by Antoine Martin

Milestone: 1.01.1

Milestone renamed

comment:18 Changed 3 years ago by Antoine Martin

Milestone: 1.12.0

Milestone renamed

comment:19 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to Kundan
Status: assignednew

Is this still an issue with version 1.0?

comment:20 Changed 2 years ago by Antoine Martin

Resolution: needinfo
Status: newclosed

Not heard back.

Note: See TracTickets for help on using tickets.