Bug 117421
Summary: | Oggs played in rhythmbox are staticy | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Greg Gilbert <greg> |
Component: | rhythmbox | Assignee: | Colin Walters <walters> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | devscott |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-04-12 14:44:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Greg Gilbert
2004-03-03 20:26:39 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? 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. 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 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 and gst-launch-0.7 filesrc location="filename" ! spider ! esdsink sound fine. Curious. 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 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. 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 startup. 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 esound-0.2.33. 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 /system/gstreamer/default/audiosink /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. 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. 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. 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. Cool, thanks for following up. |