Bug 117421 - Oggs played in rhythmbox are staticy
Summary: Oggs played in rhythmbox are staticy
Alias: None
Product: Fedora
Classification: Fedora
Component: rhythmbox (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i686 Linux
Target Milestone: ---
Assignee: Colin Walters
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-03 20:26 UTC by Greg Gilbert
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-12 14:44:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Greg Gilbert 2004-03-03 20:26:39 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040217 Epiphany/1.1.9

Description of problem:
When I play an ogg file ( I've tried about a dozen of them ) using
rhythmbox, there is a lot of static that drowns out the music. The
sound of the distortion is inconsistant between different songs, but I
have not found one that is undistorted

Version-Release number of selected component (if applicable):
rhythmbox-0.6.7-1 alsa-lib-1.0.2-2 gstreamer-0.7.5-1

How reproducible:

Steps to Reproduce:
1. Open Rhythmbox
2. Pick an Ogg
3. Press play


Actual Results:  4. Cringe in pain at the staticy audio

Expected Results:  4. Listen to soothing music

Additional info:

Fedora Core Test1 with updates as of 2004-03-03
Linux 2.6.1-1.65smp also occurs with Linux 2.6.3-1.106smp
SBLive (emu10k)

I'm able to play the oggs without trouble using a copy of mplayer that
I have compiled seperatly.

The only error that rhythmbox outputs on the stdout or stderr is "**
(rhythmbox:4071): CRITICAL **: file dparammanager.c: line 319
(gst_dpman_attach_dparam): assertion `G_PARAM_SPEC_VALUE_TYPE
(dpwrap->param_spec) == GST_DPARAM_TYPE(dparam)' failed"

Comment 1 John Thacker 2004-03-03 22:35:48 UTC
Definitely a rhythmbox issue.  I experience the same problem, but it's
perfectly fine running gst-launch-0.7 directly.  That rules out it
being a gstreamer issue.

The rhythmbox mailing list suggests that the rhythmbox-0.6.x stable
branch has known incompatibilities with the latest GStreamer CVS, and
in fact recommends using rhythmbox 0.7.0 (or the unstable CVS in
general) with the latest GStreamer.

Perhaps we should upgrade rhythmbox to the development version?

Comment 2 John Thacker 2004-03-04 01:18:26 UTC
rhythmbox development will crash right now, because the last commit to
GStreamer 0.7.5 before it released broke opt.  It's been reverted in
CVS since then until a real fix can be done.  Hmm.

Comment 3 John Thacker 2004-03-04 16:25:22 UTC
Ah, of course.  It *is* a gstreamer problem after all.  It's a problem
with spider, which is supposedly to automatically pick the right codec
to use.  rhythmbox uses that.

gst-launch-0.7 filesrc location="filename" ! spider ! alsasink
(or osssink, or esdsink) will duplicate the results

Comment 4 John Thacker 2004-03-04 16:34:10 UTC
Hmm.  I take that back.
gst-launch-0.7 filesrc location="filename" ! spider ! osssink 
duplicates the behavior, but
gst-launch-0.7 filesrc location="filename" ! spider ! alsasink
gst-launch-0.7 filesrc location="filename" ! spider ! esdsink

sound fine.  Curious.

Comment 5 John Thacker 2004-03-04 16:42:44 UTC
More data:

rhythmbox runs by default the stream:
source ! spider ! volume ! sink,
where sink is the default GStreamer output sink.

gst-launch-0.7 filesrc location="filename" ! spider ! volume ! sink
gives the static regardless of the sink.

gst-launch-0.7 filesrc location="filename" ! spider ! sink
yields static only when sink is osssink, but not otherwise

Comment 6 John Thacker 2004-03-05 14:25:53 UTC
I reported the problem to the gstreamer developers upstream and it's
been fixed in gstreamer CVS.  It was a problem with the audioconvert
plugin.  So the problem was actually in gstreamer (in
gstreamer-plugins actually), and it's been fixed upstream in CVS,
though the release hasn't been made yet.

A new release is planned soon; there just needs to be an update to the
new release before the next Fedora Cora release.

Comment 7 John Thacker 2004-03-06 04:05:25 UTC
OK, further investigation and discussion with the GStreamer folks
shows that this isn't fixed yet.  However, the problem does go away if
you switch to esd as the default GStreamer output device.  (Using
gstreamer-properties.)  This is a workaround until it's fixed upstream.

This requires updating to the esound-0.2.33 package in Rawhide, since
esound-0.2.32 is broken and segfaults.  Also users must enable esd

Comment 8 John Thacker 2004-03-06 16:50:33 UTC
Now it's definitely fixed in upstream GStreamer CVS.  There were some
problems with audioconvert and other things.  Until there's another
release, the esdsink workaround works, if a user also upgrades to

You may have to manually change the gconf key for the default
gstreamer output sink, though.  There's several gconf keys that might
be lying around:  /system/gstreamer-0.7/default/audiosink 

and gstreamer-properties does not always seem to change the same key
that rhythmbox reads.  This may have to do with me reinstalling
gstreamer (and rhythmbox) multiple times and building different
versions, though.

Comment 9 John Thacker 2004-03-06 16:52:11 UTC
Actually, the reason that gstreamer-properties doesn't always work is
that the location of the proper gconf key moves with the version of
gstreamer, but gstreamer-properties is part of gnome-media, which
doesn't necessarily know about the move.

Comment 10 John Thacker 2004-03-11 07:27:22 UTC
GStreamer and Gstreamer-Plugins 0.7.6 have been released, and they
contain the fix for this problem.  A subsequent version (0.8.0?) will
certainly make it in by FC2, as part of GNOME2.6

Recommend closing this bug as UPSTREAM, perhaps once the new GStreamer
is included in development.

Comment 11 John Thacker 2004-04-10 15:24:24 UTC
This occurred in FC test 1, but has been fixed with the packages for
gstreamer-0.8.0 that are in FC test 2 and development.  So this should
definitely be closed now.

Comment 12 Colin Walters 2004-04-12 14:44:24 UTC
Cool, thanks for following up.

Note You need to log in before you can comment on or make changes to this bug.