Re: [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: Re: [linux-audio-dev] Laaga multiple sample rates (Re: LAAGA: updates, laaga-0.2.0 tarball available)
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Jul 11 2001 - 20:22:08 EEST


In message <ruvofqrqwiv.fsf_AT_kaarne.cs.tut.fi>you write:
>Steve Harris <S.W.Harris_AT_ecs.soton.ac.uk> writes:
>
>> No. LADSPA control signals are per fragment not per n samples.
>
>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
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.

>Yesterday I was trying to make a LADSPA host for LAAGA, and the very lack of

An excellent effort. Thanks.

>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) ...

>> In any case, in a multi sample rate system the sample rate of one input
>> won't be an integer ration to the other input, as they will most likly be
>> from different cards with different clocks, do any cards support
>> multiple sample rates with a common clock?
>
>You're right, having multiple sound cards is an issue of its own, and I
>wouldn't recommend even thinking about that.

My feeling about this is that this is an ALSA-level issue these days
(via the alsa-lib "multi" PCM device layer), and we should forget
about it unless we are writing code for alsa-lib internals.

--p


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

This archive was generated by hypermail 2b28 : Wed Jul 11 2001 - 20:22:51 EEST