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: Thu Jul 12 2001 - 17:08:04 EEST
Paul Davis <pbd_AT_Op.Net> writes:
> >You're right. But don't you see that this means that the audio sample rate is
> >different from the control sample rate? For every process cycle, there will
> >be one new control sample and N new audio samples (N is the fragment length),
> >implying that the audio rate is N times the control rate.
>
> But N is not fixed! The host is free to call the plugin's run() or
> runAdding() function with any non-zero argument. It might call it
> like:
>
> run(16);
> run(21467);
> run(1);
> run(480);
> run(16384);
>
> what control rate is that? The point is that the plugin has no clue
None, but neither is that a conventional real-time audio system anymore. As
you know, in (most of today's) real-time systems the process() function is
called at regular intervals, which gives birth to constant buffer lengths.
> what the control rate is unless it goes to some effort to track
> it. The host may not even have the idea of a "control rate": it may
> handle control-events in a completely asynchronous way.
Apropos asynchronous data, care to give a briefing or it wrt. LAAGA? Am I
right in thinking that the sending client sets the buffer size in calling
laaga_get_buffer(), which is then told to the receiving client?
>
> >Yesterday I was trying to make a LADSPA host for LAAGA, and the very lack of
>
> An excellent effort. Thanks.
Well, have a peek at http://iem.kug.ac.at/~jams/ladspaplugin-0.0.1.tgz
Unfortunately it's not tested, me having problems with ALSA, but it's based on
the tried-and-true plugin~ LADSPA host for Pd. I would appreciate someone
(you? :) testing (and fixing:) it.
> >per-port sample rates made me have to implement some (inferior) sort of a
> >downsampler and an upsampler right in the host, which will produce surprising
> >results.
>
> Can you explain this a little more? I don't understand the problem
> (which is not to say I claim there isn't one) ...
OK, your solution is to create a "control" port type and make all its buffers
be of length one, but I would prefer control signals to be just plain signals
just with another sample rate. The latter solution allows for connecting and
converting different-rate (control) ports together, using a resampler client.
Think combining Csound, where you can select arate and krate by hand, with
LADSPA, where you can't.
Later,
-- -Jarno
This archive was generated by hypermail 2b28 : Thu Jul 12 2001 - 17:08:44 EEST