GNOME Bugzilla – Bug 771772
No bus messages when audio sink has issues
Last modified: 2018-11-03 11:02:17 UTC
This is fork of rhythmbox bug: https://bugzilla.gnome.org/show_bug.cgi?id=771546 Actual problem: -------------- When a "problematic audio sink" which does not work is selected in "System Settings -> Sound", audio stops and the time slider in Rhythmbox stops. When a working sink is selected, audio works and the time slider moves. The cause of concern is when a user open Rhythmbox and clicks on a song, and the time slider never moves / no audio works, the user is confused as to what is the issue ( plugin installation issue / rhythmbox bug / audio issues ) etc. Currently, there is no way for Rhythmbox to inform the user that the issue is with the "audio output device". Rhythmbox uses playbin and listens to messages from playbin pipeline ( as below ): gst_bus_add_watch (gst_element_get_bus (mp->priv->playbin), (GstBusFunc) bus_cb, mp); But, when an audio sink is having issues, there is no message in the bus, indicating that. I tried playing a song, and switch between the working and non-working sink in Sound Preferences, 'bus_cb' was never fired in gdb.
Could you please capture a debug log of the issue by running rhythmbox like this from a command line terminal window: $ GST_DEBUG=*:6 rhythmbox 2>dbg.log .. reproduce problem .. .. quit or control-C .. $ xz -9 dbg.log and then attach the dbg.log.xz file to this bug report. Thanks!
(In reply to Tim-Philipp Müller from comment #1) > Could you please capture a debug log of the issue by running rhythmbox like > this from a command line terminal window: > > $ GST_DEBUG=*:6 rhythmbox 2>dbg.log > .. reproduce problem .. > .. quit or control-C .. > $ xz -9 dbg.log > > and then attach the dbg.log.xz file to this bug report. Thanks! Once I start playing a track "dbg.log" grows to 500MB and growing. Any other suggestions.
The question is how much does it compress to? :) You can also pass GST_DEBUG_NO_COLOR=1 to make it a bit smaller, but it will still be large. The problem should occur in the first few seconds, no?
Created attachment 336031 [details] Rhythmbox gstreamer log. ( Piece 1/2 ) File is ~4MB. Use "cat" to assemble files. ( split command was split --bytes=2M dbg.log.xz )
Created attachment 336032 [details] Rhythmbox gstreamer log. ( Piece 2/2 )
Does the bug still NEEDs INFO ?
An easy way to reproduce this issue would be to use a Linux guest in VirtualBox. Most of the time, the in-built sound cards doesn't work :). I could get it working, but I generally use remote network sink ( in the Virtualbox host ), which works perfectly fine. Both of them ( local and remote sink ) would serve as the non-working and working sink ( required to reproduce this bug ) respectively.
Not sure what to do about this. It looks to me like there's a problem in lower layers (pulseaudio) ? I don't think GStreamer should have to worry about an audio sink suddenly stopping to work / consume samples, without error from the underlying audio layer? 0:00:57.162095820 gstaudiobasesink.c:2155:gst_audio_base_sink_render:<autoaudiosink0-actual-sink-pulse> rendering at 441216 0:00:57.162149309 pulsesink.c:1487:gst_pulseringbuffer_commit:<autoaudiosink0-actual-sink-pulse> entering commit 0:00:57.162156894 pulsesink.c:1505:gst_pulseringbuffer_commit:<autoaudiosink0-actual-sink-pulse> in 1151, out 1151 0:00:57.162164342 pulsesink.c:1528:gst_pulseringbuffer_commit:<autoaudiosink0-actual-sink-pulse> need to write 1152 sampl 0:00:57.162173231 pulsesink.c:1584:gst_pulseringbuffer_commit:<autoaudiosink0-actual-sink-pulse> waiting for free space (nothing else happens)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/common/issues/1.