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: Fri Jul 13 2001 - 17:11:30 EEST
>> 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
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.
>> 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?
Nope. Or rather, its not entirely worked out yet. The port buffer size
is established when the port is created, but that doesn't mean that
the entire buffer is valid at all times. So there has to be some
mechanism for the "valid region" of the buffer to be communicated to
consumers of the port data.
In general, I have tended to imagine that incoming i/o like MIDI would
be converted into scalar port values, but all you have to do is to
imagine a use of the LAAGA port system to move MIDI around, and then
it becomes clear that it doesn't work quite so well. there clearly
have to be limits on the amount of data presented at any one time
(e.g. we don't pass all of a 1.2MB firmware download to a port at one
time), but in general, the output port owner can establish a buffer of
any size they want. We just need to add a way for it to specify how
much of the buffer is available for its consumers.
--p
This archive was generated by hypermail 2b28 : Fri Jul 13 2001 - 17:12:09 EEST