29 Mar
2006
29 Mar
'06
10:41 a.m.
Hello List,
I'm trying to find a library or code-snippet in order to do audio
resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to
resample the data in realtime - resampling a buffer of data, not a
soundfile. The quality doesn't need to be good so I guess the best
solution might be linear audio resampling. The device to do the
resampling on is an ARM CM-X255 running at 400MHz.
I tried out libsamplerate so far but when I tested it with the
soundfile conversion test program it needed 3,5 secs to sample from
8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me.
Is there something faster that can do the job?
Any suggestions are highly welcome
Greetings,
Tobias
29 Mar
29 Mar
10:47 a.m.
Tobias Scharnberg wrote:
Hello List,
I'm trying to find a library or code-snippet in order to do audio
resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to
resample the data in realtime - resampling a buffer of data, not a
soundfile. The quality doesn't need to be good so I guess the best
solution might be linear audio resampling. The device to do the
resampling on is an ARM CM-X255 running at 400MHz.
I tried out libsamplerate so far but when I tested it with the
soundfile conversion test program it needed 3,5 secs to sample from
8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me.
libsamplerate uses floating point calculations and most ARM CPUs
don't have an FPU.
Julius O. Smith's original resample program used integer arithmetic
and would therefore be a better choice.
However, please do not use linear resampling; its just too crappy.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"I have never met anyone who can do Scheme, Haskell, and C pointers
who can't pick up Java in two days, and create better Java code than
people with five years of experience in Java." --
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
5:09 p.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de Castro Lopo wrote:
Tobias Scharnberg wrote:
However, please do not use linear resampling; its just too crappy.
urgh... i just switched my local copies of alsa_in and _out to linear
resampling, because SRC_SINC_FASTEST was eating CPU juice.
i should add yet another switch to the programs.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
30 Mar
30 Mar
3:34 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
torbenh(a)gmx.de wrote:
On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de
Castro Lopo wrote:
Just out of curiosity, what kind of hardware are you running this
on and what sort of performance would you find acceptable for your
application. An estimate that provides:
- input and output sample rates
- samples per second per channel throughput wrt the output rate
would give me the best idea of what you are after.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Question #2459: Ruling on shaking hands with the opposite sex
http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=2459&…
Tobias Scharnberg wrote:
However, please do not use linear resampling; its just too crappy.
urgh... i just switched my local copies of alsa_in and _out to linear
resampling, because SRC_SINC_FASTEST was eating CPU juice. 
5:35 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
Hi!
On Thu, Mar 30, 2006 at 04:34:43PM +1000, Erik de Castro Lopo wrote:
torbenh(a)gmx.de wrote:
By the way, if you have a clear idea how to constrain the resampling
process, it should be possible to be quite fast (well, of course it
depends on what fast is) while maintaining good quality. From my recent
work on SSE based resampling code for BEAST:
performance test for factor 2 upsampling using SSE instructions
(performance will be normalized to upsampler input samples)
total samples processed = 64000000
processing_time = 1.268400
samples / second = 50457270.836486
which means the resampler can process 1144.16 44100 Hz streams simultaneusly
or one 44100 Hz stream takes 0.087401 % CPU usage
Note that it is normalized to input rate, not output rate. It would
perform twice as good when normalized to output rate. But it is not an
arbitary-rate upsampler but factor 2 upsampling, and values were
measured on a fast processor (AMD64, 2200 MHz).
Details: http://mail.gnome.org/archives/beast/2006-March/msg00001.html
Measuring the same example with libsamplerate with SRC_SINC_FASTEST
gives a throughput of 1233140 samples/second, which means that my code
is about 41 times faster.
Cu... Stefan
--
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de
Castro Lopo wrote:
Just out of curiosity, what kind of hardware are you running this
on and what sort of performance would you find acceptable for your
application. An estimate that provides:
- input and output sample rates
- samples per second per channel throughput wrt the output rate
would give me the best idea of what you are after. Tobias Scharnberg wrote:
However, please do not use linear resampling; its just too crappy.
urgh... i just switched my local copies of alsa_in and _out to linear
resampling, because SRC_SINC_FASTEST was eating CPU juice. 
6:12 a.m.
New subject: [linux-audio-dev] linear resampling is crap ?
Stefan Westerfeld wrote:
process, it should be possible to be quite fast (well,
of course it
depends on what fast is) while maintaining good quality. From my recent
work on SSE based resampling code for BEAST:
At least you can make SSE process four float streams in parallel without
significant limitations to the algorithm itself. Getting all the
benefits of SIMD with single stream would probably mean limitations or
significant modifications to the algorithm.
Typically filter codes are something where compilers fail to generate
fast code and where hand written asm usually helps. Complex math is
another thing. I've seen this with FIR and especially IIR filters.
- Jussi
6:31 a.m.
New subject: [linux-audio-dev] linear resampling is crap ?
On Thu, Mar 30, 2006 at 12:12:23 +0300, Jussi Laako wrote:
Stefan Westerfeld wrote:
I'm not so sure, the cascading technique used by Faust[1] produces very
efficient SIMD implementations for filters. However you wouldn't
want to write that code by hand, you really need a compiler to do it.
[1] ftp://ftp.grame.fr/pub/Documents/JIM2003vect.pdf
- Steve
process, it should be possible to be quite fast
(well, of course it
depends on what fast is) while maintaining good quality. From my recent
work on SSE based resampling code for BEAST:
At least you can make SSE process four float streams in parallel without
significant limitations to the algorithm itself. Getting all the
benefits of SIMD with single stream would probably mean limitations or
significant modifications to the algorithm.
6:48 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
Stefan Westerfeld wrote:
Measuring the same example with libsamplerate with
SRC_SINC_FASTEST
gives a throughput of 1233140 samples/second, which means that my code
is about 41 times faster.
Are you comparing apples to apples here?
What is the bandwidth of your resampler?
From the comments in the code it seems that your
resampler is not an
abritrary resampler like mine but an 2 times upsampler. Its not
really
a fair comparison to compare a general time varying resampler like
mine to a 2 times upsampler.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Pastafarianism : http://www.venganza.org/
The intelligent alternative to 'Intelligent Design'.
9:59 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
Hi!
On Thu, Mar 30, 2006 at 07:48:02PM +1000, Erik de Castro Lopo wrote:
Stefan Westerfeld wrote:
No, I am not. I just wanted to say that if you can constrain your
resampler and need not to be as generic as libsamplerate, then you can
be a lot faster.
Measuring the same example with libsamplerate
with SRC_SINC_FASTEST
gives a throughput of 1233140 samples/second, which means that my code
is about 41 times faster.
Are you comparing apples to apples here? What is the bandwidth of your resampler?
I think its hard to compare my filter directly to one of your quality
settings (or bandwidth). The reason is that I am using a halfband
filter, which means that the filter is at -6dB at the nyquist frequency,
so it produces some aliasing for very high frequencies, which I assumed
to be not or barely audible.
But here are a few numbers, which are - if I understood your comments in
the source right - normalized to your normalization (0..2):
-3dB attenuation at 0.975
-96dB attenuation at 1.184
And here is a frequency plot of the filter made with gnuplot:
http://space.twc.de/~stefan/kde/download/us32_resample_filter.png
From the comments in the code it seems that your
resampler is not an
abritrary resampler like mine but an 2 times upsampler. Its not really
a fair comparison to compare a general time varying resampler like
mine to a 2 times upsampler.
Yes. And the results don't mean that libsamplerate performs bad for what
it does. They just mean that if you don't need a general time varying
resampler, you can produce a more efficient implementation.
Cu... Stefan
--
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
5:38 p.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
On Thu, Mar 30, 2006 at 07:48:02PM +1000, Erik de Castro Lopo wrote:
Stefan Westerfeld wrote:
i cant use a 2 times upsampler....
i want to use an unsynced soundcard with clockdrift as a recording
source. and i really dont want to make any quality compromises.
i need all features of libsrc (slowly changing samplerate, and resample
factors of 1.00001 or so)
Measuring the same example with libsamplerate
with SRC_SINC_FASTEST
gives a throughput of 1233140 samples/second, which means that my code
is about 41 times faster.
Are you comparing apples to apples here?
What is the bandwidth of your resampler?
From the comments in the code it seems that your
resampler is not an
abritrary resampler like mine but an 2 times upsampler. Its
not really
a fair comparison to compare a general time varying resampler like
mine to a 2 times upsampler.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Pastafarianism : http://www.venganza.org/
The intelligent alternative to 'Intelligent Design'.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
1 Apr
1 Apr
6:49 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
On Thu, 2006-03-30 at 22:33 +0200, torbenh(a)gmx.de wrote:
i need all features of libsrc (slowly changing
samplerate, and resample
factors of 1.00001 or so)
Lets assume - unrealistically, but for the convenience of the
maths - a sample rate of 50kHz and a buffer size of 1000. Your
resample factor of 1.00001 or so means you need to "find" or
"lose" a sample about once every 2 seconds, and 99% of your
buffers will be precisely the same size going out as they are
coming in.
Is putting the entire stream through a resampler (especially
a "crap" one) the thing to do here? I'm wondering if there
might be a better way to gain or lose the occasional sample.
erm... Anyone?
Simon Jenkins
Bristol, UK
8:20 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
On Sat, Apr 01, 2006 at 10:49:20AM +0100, Simon Jenkins wrote:
On Thu, 2006-03-30 at 22:33 +0200, torbenh(a)gmx.de
wrote:
well... there are some soundcards which can only do one samplerate
(48k or 44k1 namely) so for this case its real resampling...
i have just found that there was a timeout value in the select()
in net_driver_wait() resulting in kernel busy waiting...
this changed the cpu usage in some unfavourable manner... i am off for
some other tests... and going back to SINC_FASTEST now...
also for the internet case i am getting quite bursty clocking an
currently dont have a way to get timestamps etc from the jack_driver to
the client. so while experimenting with this stuff, i am experiencing
resampling of 5% or so...
i am currently experimenting with the coefficients and function for the
delay locked loop controlling the resample factor...
i need all features of libsrc (slowly changing
samplerate, and resample
factors of 1.00001 or so)
Lets assume - unrealistically, but for the convenience of the
maths - a sample rate of 50kHz and a buffer size of 1000. Your
resample factor of 1.00001 or so means you need to "find" or
"lose" a sample about once every 2 seconds, and 99% of your
buffers will be precisely the same size going out as they are
coming in.
Is putting the entire stream through a resampler (especially
a "crap" one) the thing to do here? I'm wondering if there
might be a better way to gain or lose the occasional sample.
erm... Anyone?
Simon Jenkins
Bristol, UK
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
7:18 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
Hi!
On Thu, Mar 30, 2006 at 10:33:58PM +0200, torbenh(a)gmx.de wrote:
i cant use a 2 times upsampler....
i want to use an unsynced soundcard with clockdrift as a recording
source. and i really dont want to make any quality compromises.
i need all features of libsrc (slowly changing samplerate, and resample
factors of 1.00001 or so)
Ok, I thought a bit in this case. You probably can get better quality
than the libsrc linear interpolation while still being quite a bit
faster than libsrc sinc interpolation.
First algorithm: upsample by factor 2 (you can use my code as it is),
then use linear interpolation. Why this is better than plain linear
interpolation? Because low frequency signals can be better approximated
by lines than high frequency signals, and after upsampling by factor 2
your signals will tend to be low frequency signals.
Second algorithm: perform factor N upsampling (for instance factor 16
upsampling), then use linear interpolation. The quality should become
even better. The performance will not suck as badly as "factor 16
upsampling" sounds, because you only need to compute those sample values
that you need to do linear interpolation.
As performance estimate, I think the first algorithm should outperform
libsrc with a factor between 10 and 30, the second algorithm should
outperform libsrc with a factor between 3 and 15 (given that both are
implemented in an SSE accelerated way, like I did).
As for quality, I'd really like to know what quality can be attained by
this approach at what speed. Could it even outperform libsrc on both,
quality and performance, under some circumstances?
Cu... Stefan
--
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
8:11 a.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
Stefan Westerfeld wrote:
First algorithm: upsample by factor 2 (you can use my
code as it is),
then use linear interpolation. Why this is better than plain linear
interpolation? Because low frequency signals can be better approximated
by lines than high frequency signals, and after upsampling by factor 2
your signals will tend to be low frequency signals.
Second algorithm: perform factor N upsampling (for instance factor 16
upsampling), then use linear interpolation. The quality should become
even better. The performance will not suck as badly as "factor 16
upsampling" sounds, because you only need to compute those sample values
that you need to do linear interpolation.
Upsampling followed by linear resampling can be a good approach. Linear
resampling can produce high quality results if you can guarantee that the
input signal is strictly band limited well below half the sample rate. I
even have some rough figures for this on page 11 of this paper which was
given at the Audio Miniconf attached to 2005 Linux.conf.au :
http://www.mega-nerd.com/tmp/secret_rabbit_code.pdf
For the case of upsampling from 44100Hz to 48000Hz, with the source
signal consisting of a single sine wave, I got the following SNR
values:
Sine Freq Signal to Noise ratio
333 Hz 146.0 dB
666 Hz 115.8 dB
1332 Hz 103.8 dB
2664 Hz 49.8 dB
5328 Hz 38.7 dB
10656 Hz 28.4 dB
21312 Hz 19.5 dB
However, beware that the upsample followed by linear resampling will
only work correctly when the output sample rate is greater than the
input sample rate. When this is not the case, extra filtering is needed
on the input side which complicates things somewhat.
As for quality, I'd really like to know what
quality can be attained by
this approach at what speed. Could it even outperform libsrc on both,
quality and performance, under some circumstances?
Linear resampling can outperfrom the best resampler in libsamplerate
under some conditions. That still doesn't make linear resampling a
good idea unless you can be 100% sure that your data *always* fits
the specific conditions where linear resampling performs well.
I'll say it again, libsamplerate is a *general purpose* resampler.
For any pair of constant input and output sample rates, it has a well
specified worst case behaviour of greater than 96 db SNR. On top of
that, it *also* handles the case where the ratio between input and
output sample rates is not constant.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Unix and C are the ultimate computer viruses." -- Richard P Gabriel
30 Mar
30 Mar
5:34 p.m.
New subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
On Thu, Mar 30, 2006 at 04:34:43PM +1000, Erik de Castro Lopo wrote:
torbenh(a)gmx.de wrote:
ok... the program is a jack application, that opens an alsa pcm device
(obviously not the one, jackd is bound to) and either outputs or inputs
the sound.
On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de
Castro Lopo wrote:
Just out of curiosity, what kind of hardware are you running this
on and what sort of performance would you find acceptable for your
application. An estimate that provides: Tobias Scharnberg wrote:
However, please do not use linear resampling; its just too crappy.
urgh... i just switched my local copies of alsa_in and _out to linear
resampling, because SRC_SINC_FASTEST was eating CPU juice.
- input and output sample rates
input is usually 48000 or 44100 (the jackd samplerate)
outputrate depends on the soundcard used. 48k or 44k1 +- 10 Hz varying
with clock drift... and calculation of resampling factor in float.
i will improve the detection algorithm soon again.
so that the samplerate is changing slower...
- samples per second per channel throughput wrt
the output rate
realtime.
when the jack source clock is not very bursty (ie LAN or local)
2 channels take 7% cpu on an athlon xp 2000
with a bursty clock source from the internet the cpu usage in top is
much higher. like 20% or so.
a little too much for a soundcard IO :)
would give me the best idea of what you are after.
i hope you get what i am after now. i am heavily exercising libsrc...
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Question #2459: Ruling on shaking hands with the opposite sex
http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=2459&…
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
5 Apr
5 Apr
9:27 p.m.
Tobias Scharnberg wrote:
Hello List,
I'm trying to find a library or code-snippet in order to do audio
resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to
resample the data in realtime - resampling a buffer of data, not a
soundfile. The quality doesn't need to be good so I guess the best
solution might be linear audio resampling. The device to do the
resampling on is an ARM CM-X255 running at 400MHz.
I tried out libsamplerate so far but when I tested it with the
soundfile conversion test program it needed 3,5 secs to sample from
8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me.
Is there something faster that can do the job?
Any suggestions are highly welcome
Hi Tobias
I suggest using a Kaiser-window based interpolation algorithm. This is
the best filter method to use for sample rate conversion. You can get
decent results with 8 taps or even fewer. For example you can get a 6dB
bandwidth of about 2.8kHz (at Fs=8kHz) with 50dB alias rejection. (of
course you need more taps for high-quality results)
I implemented an 8 tap SRC on an ARM-9 using integer arithmetic... I
can't remember the exact CPU usage but it was only of the order of 10MHz
or so. I'm not familiar with the CPU you mention - if it hasn't got the
DSP instructions then it will be a bit slower but you seem to have
plenty to spare!
Linear interpolation is no good for audio - you will have about 10%
distortion!
Andrew
6 Apr
6 Apr
7:39 a.m.
Andrew!!! How's life post-Farilight? What are you up to now? Maybe off
list :-).
Andrew Cannon wrote:
I suggest using a Kaiser-window based interpolation
algorithm. This is
the best filter method to use for sample rate conversion. You can get
decent results with 8 taps or even fewer. For example you can get a 6dB
bandwidth of about 2.8kHz (at Fs=8kHz) with 50dB alias rejection. (of
course you need more taps for high-quality results)
By way of comparison, the fastest of my three sinc based converters has
a 3dB bandwidth of 3.2kHz with reference to Fs of 8kHz.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"A mouse is a device used to point at the xterm you want to type in."
-- Kim Alm, a.s.r
6609
days inactive
6617
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
8 participants
participants (8)
-
Andrew Cannon -
Erik de Castro Lopo -
Jussi Laako -
Simon Jenkins -
Stefan Westerfeld -
Steve Harris -
Tobias Scharnberg -
torbenh＠gmx.de