GNOME Bugzilla – Bug 120883
osssink advertises more rates than it handles
Last modified: 2004-12-22 21:47:04 UTC
Gstreamer plays mp3 aswell as ogg files with a pitch to high. Other applications like XMMS, or audacity, do not have trouble with the pitch. f.e Rhythmbox plays my songs to fast, aswell as gst-launch-ext. On my own system, I have ossink enabled, which reduces the pitch-level, but leaves it still to high.
Created attachment 19564 [details] log file gst-launch-ext thanks to ds-work :)
*** This bug has been marked as a duplicate of 120880 ***
*** Bug 120880 has been marked as a duplicate of this bug. ***
Please run 'gst-launch --gst-mask filesrc location=it.mp3 ! mad ! osssink &>logfile', compress the logfile, and attach that file.
Created attachment 19565 [details] log file gst-launch-ext. the right one! :)
I have the same problem here when using the oss audiosink. The reason seems to be my stupid laptop soundcard which is only able to play at 48kHz sample rate. For 44.1 kHz mp3 stuff, this results in a higher pitched output from gstreamer->osssink based stuff. xmms seems to do the right thing here (internal resampling). Note that for both xmms and gsreamer using the esdsink (or esd output plugin in the case of xmms) isn't an option either, because the resampling of esd is so bad that I better don't listen to music at all. What I would really like to have is to use esd BUT have gstreamer detect (don't know if this is possible) which sample rate esd can play without using resampling and for every other rate use an (gstreamer-) internal high quality resampler instead.
just to clarify: using esdsink solves the pitch problem on my system, it's just that the resampling quality is absymal.
esdsink did not solve anything here. I have changed via gconf-editor audiosink to esdsink sync=true but still to fast. Thijs Thiessens
gst-launch-ext doesn't use gconf (obviously), so be sure you've tested that via rhythmbox or another gconf-using app... If you change the gconf value to "audioscale frequency=48000 ! osssink", does it work?
Hey!! Thanks Ronald, it worked right away! I'm thrilled.. finally I can make use of rhythmbox for the first time ever.. :) I'm so happy. Really thanks man! And ds-work also thanks for your time! :) So for me this bug is over. Do I need to close it or something? Thijs
I'll leave it open, it's actually a good idea to modify osssink to only provide the caps that it actually supports (though I'm not 100% sure on how to request that; might need to look at the OSS specs to be sure) on its template (probably through a _get_caps() function). We could then use audioscale as a standard element in rhythmbox and gst-player, so all this goes transparently. By default, audioscale will act as a "no-op" element, if both elements on its left/right side can fit together without audio re-scaling; this works just like colo(u)rspace for video. So, we might want to do a topic change from "Gstreamer plays with a pitch to high" to "osssink doesn't check for caps restrictions". Once that's done, we can make all apps use audioscale and this will all be done automatically. :).
As far as GNOME is concerned, this is a *horrible* bug without the workaround. IMHO, it would be really nice to have some sort of fix soon-ish, even if it's just modifying the schema default (if that works for all cases?).
*** Bug 126260 has been marked as a duplicate of this bug. ***
ronald, what do you still think needs to be done here ?
Hey, just to note; I have been installing gnome on redhat and fedora distributions on numerous computers. On each installation I had to use the line 'audioscale frequency = 48000 ! osssink' to adjust the pitch for gstreamer. Not one played back normal on first boot. Thanks Thijs Thiessens
I resolved the problem using alsa and the oss emulation layer. be sure to use the latest alsa, as it contains bug fixes for that kind of problems. it's better to let the sound driver do that, instead of the applications, as it only needs upsampling in one location (the driver)
The problem is that setting a rate in OSS leads to some funny results. If you try setting the rate to 44100, OSS might actually set it to 44100, 44018, 44787, 47655 or even 22050 Hz. Currently we just accept those instead of using a heuristic to figure out what rate is "good enough" and return an error if it's not. Add to this that OSS doesn't support good enough querying capabilities - the only way to query a supported format is trying to set it and looking at the result. Other apps using OSS do query/try to set some list of formats to figure out what's supported btw.
And I intend to add that to OSS, btw... V4l does it too (similar bug), and v4lsrc does the try-for-list on startup. Ugly, but the only right way.
This is still a bug in 0.8.0, so updating version.
*** Bug 137979 has been marked as a duplicate of this bug. ***
I added rate probing code to CVS for osssink. Please test this out and let me know how it works. In particular, a launch line such as gst-launch sinesrc ! audioconvert ! audio/x-raw-int, rate=12345 ! osssink should fail to negotiate, i.e., give the warning WARNING: erroneous pipeline: could not link sinesrc0 to osssink0 instead of an ignored problem in osssink: WARNING: couldn't set the right sample rate (wanted %d, got %d), enjoy the speed difference
*** Bug 139929 has been marked as a duplicate of this bug. ***
verified fixed, thanks.