GNOME Bugzilla – Bug 523878
Audio rendering sounds corrupted when using Banshee Trunk.
Last modified: 2008-05-17 13:28:34 UTC
I am using Banshee SVN Trunk (22march2008) on ubuntu 7.10 64bit. The last few days I am experiencing corrupted audio rendering. I first thought that it were my speakers, the connector, the mp3 files itself, or some hardware error, but this appears to be not the case. I just tested the files with another mediaplayer (totem and mplayer) and the music sounded OK. When I switch back after a few seconds to Banshee Trunk, the same files sounds corrupted. I even tested it with the stable Banshee and there it just sounds OK too. So something has changed in Trunk that garbles up my music. It's quite hard to describe it, but it most looks like a form of stuttering. Not very heavy, but very subtle, though very irritating. One can also describe it as like it is going into some kind of compressor. No heavy software is running, cpu load is low, at least 0.5 GB free mem available, etc. Please let me know what to do for debugging this problem.
I have heard what I think is the same thing. Our best guess right now is that it's caused by the equalizer element in the gstreamer pipeline. I see this even if the eq says it's disabled, but it still may be it.
As I clue I was getting this with mp3s too... but I removed fluendo's codecs and now I don't get those noises with my mp3s. If the volume is low I don't get any problem too. Also if you play with the equalizer setting it very low you don't get the noises too.
(In reply to comment #2) > If the volume is low I don't get any problem too. Also if you play with the > equalizer setting it very low you don't get the noises too. Sounds like (at least for you) the preamp is too high.
No, actually if I turn off the eq(disabled it) I still get the problem.
I don't have this problem but could someone who has try to simply not link and add to the bin the equalizer in libbanshee? I really doubt it's the equalizer :)
If you could explain how to not include the equalizer, I am happy to do that.
I just went ahead and ripped every equalizer reference out of the source code in my local svn copy. I guess that is not the way to do it, but I got it compiled now with no equalizer, and still the corrupted sound. If there is a better way to test this, let me know. Did the equalizer always exist in Banshee Trunk? If not, what is the SVN revision number of the import. That way I can check if something changes between that revision and the one before that.
(that makes me wondering too why the Changelog does not has svn rev numbers, but only dates.)
I don't think the EQ is the problem, probably some of changes to libbanshee did last week. The issue is that sound... in some audio formats(like wma) is probably not handled correctly. See what happens with the EQ enabled and the general volume very low... you just don't listen the corrupted sounds.
I don't really get what you are saying, but I tried the most recent svn version and played with the EQ controls, and whatever volume/preamp etc I did it still sounded corrupted. The audio format of the file is MP3.
I can confirm that removing gstreamer0.10-fluendo-mp3 solves my problem. Something strange going on with that codec in combination with Banshee.
What happen if you you loose your freedom and try to play a wma or a wmv?
I have 3 wma files in my collection, and none of them appear to have any problems with Banshee like I had with some of my mp3's. I know, it's not much to be representative of the banshee wma handling, but I couldn't find any errors.
I just committed a patch to disable the equalizer altogether in the playback pipeline. Please update to the latest revision in svn and let me know if the audio is playing properly. The way the equalizer was added in the pipeline was not good - the element would *always* be in the pipeline even if it was disabled in the UI. When disabled, it appears that all the band and preamp levels would just be set to 0. This means that all audio buffers would undergo transformation in the eq element, regardless of whether equalization was turned on or not - not a good thing. I hope to have a proper fix for equalization later. For the time being, equalization is disabled. This is also not a blocker bug. It is pretty bad though, since it is essentially a data loss issue. Please read http://bugzilla.gnome.org/page.cgi?id=bug-status.html#bug_severity
My bad on the Blocker status. :)
Tried the new svn and it looks like it's solved! (tested a know stuttering song, with fluendo-mp3 installed on Banshee SVN: no stuttering.) Will use Banshee as main player for my music now and will report if this error will show up somehow in other songs, though unlikely. I guess you'll need info from the guy that has wma problems, so I'll leave the NEEDINFO status as it is.
"the guy that has wma problems" says the problem with wma and wmv files is solve :). Thanks Aaron! I think you can close this bug.
Yeah, relinking the equalizer in real-time would probably be a better solution to fixing this, however, in theory, no processing should be taking place in the equalizer element if the values are set to 0dB. I suppose that's my bad. Re-linking the entire playbin and is a bit more involved than just setting all the elements to 0dB, haha. As a interim solution, I suppose we could pass an autogen/configure argument to enable/disable the equalizer. It should probably also be noted that this issue is really quite visible only with gstreamer0.10-fluendo-mp3. Possibly related to the caps exposed/pulled in by the plugin and the element? This issue has been around for at least a year, as far as I know. Also, if somebody could test this just with a GStreamer pipeline via gst-launch-0.10?
The equalizer does not change the data when every gain is set to 0dB... whatever, this is most probably a dup of bug #510865 so closing it as such. *** This bug has been marked as a duplicate of 510865 ***