Subject: Re: [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: Tue Jul 17 2001 - 12:57:10 EEST
Paul Davis <pbd_AT_Op.Net> writes:
> >None, but neither is that a conventional real-time audio system anymore. As
>
> Sure it is. It has a frames-per-interrupt setting of 32768, and the
> host is under MIDI control itself, and so subdivides the processing
> because of incoming state-changing MIDI data.
Ok, so it's something else than LAAGA anyway (it doesn't subdivide the basic
processing fragment in any circumstances).
I'll just try to recapitulate my message about multiple a.k.a. per-port sample
rates.
Premises:
* I'm not talking about async data at all since it's unrelated to sample
rates; in other words, *I'm only talking about synchronous audio here*
* LAAGA: a real-time sound framework that passes synchronous audio around in
segments; is driven by the soundcard fragments; therefore, the segments are
constant-duration (in msec) during engine lifetime
* LADSPA: a plug-in system which, when used in a real-time configuration such
as LAAGA, inputs and outputs synchronous audio and control signals at
different rates, which are related by the audio buffer length (in samples)
* In a LAAGA-like system, when given the fragment duration (in msec), the
synchronous audio buffer lengths and sample rates are related by:
buffer_length = buffer_duration * sample_rate / (1000 ms)
Motivation:
* the number of industry-standard and widely used sample rates is more than
one: imagine playing that guitar part from a 48 kHz DAT tape to your 96 kHz
Ardour multitrack project, etc.
* sound synthesis applications are used to having different audio and control
rates to spare CPU power; two examples are Csound and LADSPA, where Csound
lets the user enter audio and control rates at will, and LADSPA makes a
connection between them and the fragment length.
* a glue API is supposed to prevent from having to do things like (1) record
the 48 kHz part to a WAV file; (2) invoke SOX to make another WAV file at 96
kHz; (3) delete the 48 kHz WAV file; (4) import the 96 kHz WAV file to
Ardour. See, no glue?
Solution #1: embed sample rate information in LAAGA port type strings, such as
"audio_AT_44100 Hz" or "control_AT_12000 Hz"
Pros:
- no changes to LAAGA 0.2.2 core required
- theoretically no limit for sample rates
- the client is the resampler -> the user can choose
- ports with different rates can't be wired directly -> user has to actively
decide when to use resampling and where
Cons:
- you have to write separate clients for *each* individual type; for example,
you would have "resampler (audio_AT_44100 Hz->audio_AT_48000 Hz)", "resampler
(audio_AT_48000 Hz->audio_AT_44100 Hz)", etc., each as different clients
- practically the available sample rates are limited to a common set (44100
Hz, 48000 Hz and a few friends) for the non-programmer
Solution #2: add "unsigned long sample_rate" to LAAGA port struct; remove it
from everywhere else
Pros:
- a single resampler client will happily convert any audio or control signal
to any other audio or control signal
- changes to LAAGA are minimal, since the sample_rate field is used in similar
ways and places as the existing type_name field; for example, compare when
making a connection, etc.
- the client is the resampler -> the user can choose
- ports with different rates can't be wired directly -> user has to actively
decide when to use resampling and where
Cons:
- limited to integer sample rates (no problem?)
-- -Jarno
This archive was generated by hypermail 2b28 : Tue Jul 17 2001 - 18:20:37 EEST