GNOME Bugzilla – Bug 794411
gstaudioresample: insufficient anti-aliasing
Last modified: 2018-11-03 12:04:17 UTC
I am using GStreamer for calibration of LIGO data. After an update from version 1.4.5 to version 1.10.4, I discovered that the anti-aliasing was much lower in quality than before, leading to ~2% systematic errors. I set the property quality = 9, and the rest of the properties were the default values.
Could you please also check with the lastest version (1.14 rc2 = 1.13.91) or git master? And/or make a test case available so we can try it ourselves?
Did you also try the different settings (apart from quality)? See https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstAudio.html#GstAudioResamplerFilterInterpolation and everything below it.
Created attachment 369920 [details] Transfer Function for audioresample I used a command line similar to this to generate the data for the attached plot: gst-launch-1.0 audiotestsrc num-buffers=100 samplesperbuffer=16384 wave=5 ! audio/x-raw,format=F64LE,rate=16384 ! tee name="teeAB" silent=false ! audioresample quality=9 name="B1" ! audio/x-raw,format=F64LE,rate=2048 ! audioresample quality=9 name="B2" ! audio/x-raw,format=F64LE,rate=16384 ! identity name="B3" teeAB. ! identity name="A1" A1. ! lal_nxydump ! filesink location=data.txt async=false B3. ! lal_nxydump ! filesink location=resampled_data.txt async=false The plot is a transfer function (magnitude and phase) between white noise produced by audiotestsrc and the same data after it has been downsampled from 16 kHz to 2 kHz and then upsampled back to 16 kHz. The magnitude plot shows that the signal is significantly attenuated below the Nyquist frequency of 1 kHz. (So perhaps I should clarify that the systematic errors I observed were not likely due to aliasing, but rather to this extra attenuation.) Is this attenuation intentional, and if so, is there a setting that will not attenuate the signal much below the Nyquist rate?
I would have to check in more detail, but isn't this what https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstAudio.html#GST-AUDIO-RESAMPLER-OPT-CUTOFF:CAPS is configuring?
I assumed that <https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstAudio.html#GST-AUDIO-RESAMPLER-OPT-CUTOFF:CAPS> is defining the cutoff frequency to be 0.94 times the Nyquist frequency. Is this correct? My question is why the signal is attenuated far below this, even at the DC component. From DC to a little under the Nyquist frequency in the plot I attached, the attenuation factor is between about 0.6 and 0.9. Is this the intended behavior, and is there a way to avoid this attenuation?
CC'ing Wim as he wrote the resampler. He probably knows best :)
Created attachment 370187 [details] audioresample transfer function After experimenting with different properties, I found that using quality = 9 and resample_method = 4 (kaiser) came closer to the desired behavior. However, there was a phase error in the passband, as shown in the attached plots. I've attached similar plots of transfer functions (see comment 3). I've also included plots zoomed in on the passband to show the phase error. For comparison, I've attached the same two transfer function plots produced from data that was resampled by another resampling element that we use. Perhaps there is a timestamp bug?
Created attachment 370188 [details] audioresample transfer function zoomed
Created attachment 370189 [details] lal_resample transfer function
Created attachment 370190 [details] lal_resample transfer function zoomed
Created attachment 370191 [details] audioresample transfer function zoomed only downsample To see whether the phase error comes from upsampling or downsampling, I did a similar test to the one above, but using audioresample for only downsampling, and then using it for only upsampling. Plots are attached.
Created attachment 370192 [details] audioresample transfer function zoomed only upsample It appears that there is a phase error associated with both upsampling and downsampling, but the error is greater when upsampling. I am still using the same basic pipeline that generates white noise at 16384 Hz, downsamples it to 2048 Hz, and then upsamples it again to 16384 Hz.
<slomo> wtay: https://bugzilla.gnome.org/show_bug.cgi?id=794411 do you have any ideas about this one? :) <slomo> wtay: audio resampler aliasing <wtay> slomo, no idea, I tuned the quality param to give exactly the same values as what speex did <wtay> other than that.. would need to compare the calculated filter against speex to see if it lines up
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/426.