After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580214 - Equalizer starts distorting the sound after a while.
Equalizer starts distorting the sound after a while.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.22
Other All
: Normal normal
: 0.10.16
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-25 13:17 UTC by Yogesh Marwaha
Modified: 2009-05-28 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Debug output (49.72 KB, text/plain)
2009-04-27 08:31 UTC, Yogesh Marwaha
  Details
Patch - Maintain precision as much as possible, move floor call to the last possible time to do so (2.49 KB, patch)
2009-05-23 01:26 UTC, Ghislain 'Aus' Lacroix
committed Details | Review

Description Yogesh Marwaha 2009-04-25 13:17:14 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:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
Yes.

Other information:
Comment 1 Sebastian Dröge (slomo) 2009-04-26 08:38:53 UTC
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)?
Comment 2 Yogesh Marwaha 2009-04-27 08:31:44 UTC
Created attachment 133398 [details]
Debug output

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.
Comment 3 Sebastian Dröge (slomo) 2009-05-04 08:57:46 UTC
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?
Comment 4 Yogesh Marwaha 2009-05-07 09:22:18 UTC
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)
    GstElement *capsFilter;
    GstCaps *caps;
    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.
Comment 5 Sebastian Dröge (slomo) 2009-05-07 10:33:28 UTC
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
Comment 6 Yogesh Marwaha 2009-05-07 11:32:47 UTC
(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.
Comment 7 Sebastian Dröge (slomo) 2009-05-07 12:22:17 UTC
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);
Comment 8 Yogesh Marwaha 2009-05-07 14:55:30 UTC
(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
> "audio/x-raw-int,width=16,depth=16"?
Right, again!

> 
> 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).
Comment 9 Sebastian Dröge (slomo) 2009-05-07 15:05:04 UTC
Great, thanks for this information :) Now we just have to find the bug ;)
Comment 10 Sebastian Dröge (slomo) 2009-05-07 15:20:04 UTC
Just curious, if you have all gains at 0.0 and change some lower bands to negative values, does it still produce the distortions?
Comment 11 Yogesh Marwaha 2009-05-07 16:14:59 UTC
Yes, it does seem to distort. (set band-0 to -12dB)
Comment 12 Sebastian Dröge (slomo) 2009-05-08 09:46:39 UTC
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
Comment 13 Yogesh Marwaha 2009-05-08 09:52:36 UTC
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.
Comment 14 Yogesh Marwaha 2009-05-13 05:46:39 UTC
(In reply to comment #12)
> Call the following to see the version
> 
> gst-inspect equalizer-nbands | grep Version
> 

  Version:              0.10.14
Comment 15 Sebastian Dröge (slomo) 2009-05-13 15:11:07 UTC
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
Comment 16 Yogesh Marwaha 2009-05-16 08:27:55 UTC
(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.
Comment 17 Ghislain 'Aus' Lacroix 2009-05-22 01:06:03 UTC
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.

@Sebastian

Do you have any pointers to try and improve on the current code?
Comment 18 Sebastian Dröge (slomo) 2009-05-22 05:31:20 UTC
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 :)
Comment 19 Ghislain 'Aus' Lacroix 2009-05-22 21:51:56 UTC
@Sebastian

Sounds good to me. I'm all setup over here to build gst so you can just post a patch when it's ready :)
Comment 20 Ghislain 'Aus' Lacroix 2009-05-23 01:26:00 UTC
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).
Comment 21 Sebastian Dröge (slomo) 2009-05-23 08:05:19 UTC
(In reply to comment #20)
> Created an attachment (id=135215) [edit]
> 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 :)
Comment 22 Ghislain 'Aus' Lacroix 2009-05-27 20:11:54 UTC
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 :)
Comment 23 Sebastian Dröge (slomo) 2009-05-28 10:41:27 UTC
commit 9507cdc84c968dc142356157c861e8d216b85716
Author: Ghislain 'Aus' Lacroix <aus@songbirdnest.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.