[linux-audio-dev] Laaga multiple sample rates (Re: LAAGA: updates, laaga-0.2.0 tarball available)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Laaga multiple sample rates (Re: LAAGA: updates, laaga-0.2.0 tarball available)
From: Jarno Seppanen (jams_AT_cs.tut.fi)
Date: Mon Jul 09 2001 - 15:31:29 EEST


Hi Paul, others,

having skimmed through the source, at least one thing that should be added
came into my mind: support for per-port sample rates. I'll start with
motivation: it is not so far from reality to have to work with many sample
rates with a Linux box, for example when dealing with a 96 kHz recording
project, a CD player and a DAT recorder at the same time. Now, if Laaga
intends to be a layer for interoperation and integration of all Linux music
apps, I sure bet it has to be able to connect (say) a 48 kHz DAT stream to
(say) a 96 kHz Ardour input.

With the 0.2.2 Laaga source, support for different sample rates could be
kludged in by (mis)using the port type mechanism: have types be "audio_AT_44100
Hz", "audio_AT_48000 Hz", "audio_AT_192000 Hz" and everything in between, but this
is not nice.

Now, should this be implemented properly, it would require that all ports have
a sample rate of their own and (a) there is no global sample rate and (b)
there is no per-client sample rate. This implies that the buffer lengths
between ports with different sample rates would be different. The engine
would have to check that sample rates match before making connections, and it
would compute buffer lengths from the sample rates.

All in all, the implementation burden is not really that big, and this feature
really is needed in a today's digital audio workstation. What comes to the
actual resampling code, I have GPL'd "academic-strength" resampling routines,
see resampler_base.cc, downsampler.cc, and upsampler.cc in
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sonicflow/sf/src/blocks/

P.S. one thing about LAAGA terminology: I was really mislead by the use of the
word "frame" in the sources; I've always assumed that a frame of audio is
something like 100 ms of a mono signal, but the sources use that to refer to
an audio sample (e.g. nframes_t). I don't see why a sample is not called a
sample?

-- 
-Jarno


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jul 09 2001 - 15:32:44 EEST