GNOME Bugzilla – Bug 580214
Equalizer starts distorting the sound after a while.
Last modified: 2009-05-28 10:41:27 UTC
Please describe the problem:
After while of playing with the lower frequency bands of the equaliser, the sound starts to distort. Once it start to distort, the distortion gets increases with every change of any of the band.
Only if all bands are set to 0, the sound is normal.
This problem was encountered in my KDE/qt based program which uses gstreamer directly. I've tested banshee and found that problem there too.
Steps to reproduce:
Does this happen every time?
Could you run with GST_DEBUG=equalizer:5 and attach the generated output here, especially the filter coefficients (and a note at which point things went wrong)?
Created attachment 133398 [details]
Output of 'GST_DEBUG=equalizer:5 banshee-1' is attached. Banshee had my previous equaliser settings saved and I did not have to do anything else to get the distortion. Simply playing-back an audio file was enough.
Thanks, could you check if this also happens (in your program) if you a) add a volume element before the eq, lowering the volume to 80% for example or b) if you add a capsfilter before the eq to only allow audio/x-raw-float as input?
I did the above but get no good result.
1) Added a volume element and set it to 50% - did not help.
2) Added a capsfilter (as below), but it results in error when it is set to audio/x-raw-float (audio/x-raw-int works with same problem of distortion)
caps = gst_caps_new_simple("audio/x-raw-float", NULL);
capsFilter = gst_element_factory_make("capsfilter", "gravity-capsfilter");
g_object_set(G_OBJECT(capsFilter), "caps", caps, NULL);
Error thrown was "Internal GStreamer error: pad problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer."
3) Tried audioconvert before capsfilter, now the above error was not shown but playback was paused.
I'm not sure I did the things (2/3) correctly as I'm still new to GStreamer.
Oh well, could you take tests/examples/equalizer and change the audiotestsrc to something else (i.e. "filesrc ! decodebin ! audioconvert") and then test if you can reproduce it with that demo? :)
In theory step 3) should've worked, if you had ... ! audioconvert ! capsfilter ! equalizer ! audioconvert ! audiosink
(In reply to comment #5)
> In theory step 3) should've worked, if you had ... ! audioconvert ! capsfilter
> ! equalizer ! audioconvert ! audiosink
Oops, I was not using second audioconvert; now this setup works properly for the equaliser.
Works properly means no distortion?
I assume that the distortions come back again if you change the capsfilter to "audio/x-raw-int,width=16,depth=16"?
In that case this is again a problem with the integer mode... probably some clipping at some point. Could you check if this still happens if the line
CREATE_OPTIMIZED_FUNCTIONS_INT (gint16, gint32, -32768, 32767);
in gstiirequalizer.c is changed to
CREATE_OPTIMIZED_FUNCTIONS_INT (gint16, gfloat, -32768, 32767);
(In reply to comment #7)
> Works properly means no distortion?
Yes, it now plays audio without distortion.
> I assume that the distortions come back again if you change the capsfilter to
> In that case this is again a problem with the integer mode... probably some
> clipping at some point..........................................
Whatever the cause may be, the problem is with every media file I tried to play (mp3-flac-vob); and most of the times the lower band is unable to bear a change of +/- 2 dB.
> ....................... Could you check if this still happens if the line
> CREATE_OPTIMIZED_FUNCTIONS_INT (gint16, gint32, -32768, 32767);
> in gstiirequalizer.c is changed to
> CREATE_OPTIMIZED_FUNCTIONS_INT (gint16, gfloat, -32768, 32767);
Sorry, I'm using precompiled binaries provided by openSUSE (11.1 Gnome repo - dumped earlier rpms from pacman thinking this problem might be caused by some kind of build issue).
Great, thanks for this information :) Now we just have to find the bug ;)
Just curious, if you have all gains at 0.0 and change some lower bands to negative values, does it still produce the distortions?
Yes, it does seem to distort. (set band-0 to -12dB)
I can't reproduce this here, no matter how hard I try... which version of gst-plugins-good are you using?
Call the following to see the version
gst-inspect equalizer-nbands | grep Version
atm i'm away from my home pc so i can't do "gst-inspect equalizer-nbands | grep Version" but know for sure that I have version 0.10.14 of gst-plugins-good installed.
(In reply to comment #12)
> Call the following to see the version
> gst-inspect equalizer-nbands | grep Version
Ok, 0.10.14... then this is a new bug that I can't reproduce unfortunately :(
Does this happen for all music files you try or only specific ones? Does it happen instantly or only after some time?
Other than that it would really help if you could test what I've written in comment #7
(In reply to comment #15)
> Ok, 0.10.14... then this is a new bug that I can't reproduce unfortunately :(
> Does this happen for all music files you try or only specific ones? Does it
> happen instantly or only after some time?
It happen (instantly) for every music file I try (format:mp3/flac).
> Other than that it would really help if you could test what I've written in
> comment #7
I've tried that but without success.
I've also run into this problem.
It's fairly subtle depending on the music you pick to test with but there's definitely a muddy quality to the sound when fiddling around with the bands and applying a sharp cut in gain (-12dB seems to do the trick).
Maybe the width of the bands ends up being a little too wide and there's overlap?
It could simply be the method that's used to manipulate the audio data that causes this and there may not be any way to make it better without switching to a different one.
Do you have any pointers to try and improve on the current code?
Yeah, I have an idea what could be the problem... the calculation of the band widths for the band filters is not 100% correct, I'll get this fixed and you can retry then :)
Sounds good to me. I'm all setup over here to build gst so you can just post a patch when it's ready :)
Created attachment 135215 [details] [review]
Patch - Maintain precision as much as possible, move floor call to the last possible time to do so
This seems to fix the muddy sound for me by maintaining the precision of the history using doubles and moving the floor() call to the last possible moment (instead of doing it in the step() function).
(In reply to comment #20)
> Created an attachment (id=135215) 
> Patch - Maintain precision as much as possible, move floor call to the last
> possible time to do so
> This seems to fix the muddy sound for me by maintaining the precision of the
> history using doubles and moving the floor() call to the last possible moment
> (instead of doing it in the step() function).
Great, I'll do some tests later too and will commit it then... and work later on the bandwidth issue mentioned above.
Using integer arithmetic for the int16 mode isn't a very good idea in general I guess because IIR filters are usually very picky about rounding errors so the patch is a good idea in any way :)
Indeed :) It was interesting that the math still worked well enough for it to seem fine if you didn't tweak some of the lower bands.
Thanks for your quick responses, they were really helpful :)
Author: Ghislain 'Aus' Lacroix <email@example.com>
Date: Thu May 28 12:39:46 2009 +0200
equalizer: Use floating point arithmetic internally for the int16 mode
By using int32 arithmetic we will introduce distortions as the
IIR filter is very sensitive to rounding errors. Fixes bug #580214.