search

xiph / speexdsp

Speex audio processing library - THIS IS A MIRROR, DEVELOPMENT HAPPENS AT https://gitlab.xiph.org/xiph/speexdsp
https://speex.org
Other
469 stars 190 forks source link

Wraparound when resampling on Raspbian armhf #13

Closed drigz closed 6 years ago

drigz commented 7 years ago

I found that when resampling from 16k to 48k on the Raspberry Pi 3, libspeex sometimes introduces very bad distortion. I originally discovered this with ALSA's rate_speexrate plugin, but it occurs when libspeexdsp directly too. The installed version is libspeexdsp1-1.2~rc1.2-1 from Raspbian Jessie. The issue is not present on x86_64.

Here is the source code for a test case: speex-resampler.tar.gz

sudo apt-get install sox libspeexdsp-dev
tar xf speex-resampler.tar.gz
cd speex-resampler
make
aplay test_48k.wav

This is what the waveform looks like before and after resampling:

image

jmvalin commented 7 years ago

The reason it's only on ARM is likely because of fixed-point. It'd be good to check whether the generic fixed-point also has the bug or just the Neon version.

drigz commented 7 years ago

Could you explain how I could test the generic fixed version?

Am 30.06.2017 10:55 nachm. schrieb "Jean-Marc Valin" < notifications@github.com>:

The reason it's only on ARM is likely because of fixed-point. It'd be good to check whether the generic fixed-point also has the bug or just the Neon version.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/xiph/speexdsp/issues/13#issuecomment-312370929, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmlj89_zeyklZ8RIr1lw3YsmXsWaYaFks5sJWDRgaJpZM4OGlhQ .

tmatth commented 7 years ago

On Tue, Jul 4, 2017 at 2:45 AM, Rodrigo Queiro notifications@github.com wrote:

Could you explain how I could test the generic fixed version?

Am 30.06.2017 10:55 nachm. schrieb "Jean-Marc Valin" < notifications@github.com>:

The reason it's only on ARM is likely because of fixed-point. It'd be good to check whether the generic fixed-point also has the bug or just the Neon version.

Try ./configure --enable-fixed-point --disable-neon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/xiph/speexdsp/issues/13#issuecomment-312370929, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmlj89_ zeyklZ8RIr1lw3YsmXsWaYaFks5sJWDRgaJpZM4OGlhQ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/xiph/speexdsp/issues/13#issuecomment-312794141, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEFLr5W5XKnxNOR6EvSZ2FswgVZ6DYfks5sKd90gaJpZM4OGlhQ .

tmatth commented 7 years ago

And thanks for the detailed report, I will try on a NEON device.

fbarchard commented 6 years ago

The smlal in ARM does a 16 bit * 16 bit multiple and accumulate to 32 bit, but does not clamp. I made the 64 bit code do exactly what the 32 bit NEON code does. What does the C and/or x86 do?

tmatth commented 6 years ago

@drigz So I can reproduce this with the packaged speexdsp on Rasbpian as well, however so far I can't with the latest speexdsp.

tmatth commented 6 years ago

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799176