Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su syys 26 1999 - 16:31:25 EDT
>> cycle. Thats 533 instructions per frame. If you're running on a UP,
>> which many people will be, I think that the chances of you
>> timestamping the event with sample accuracy are not good.
>
>Depends on where your input events come from. Trigging a soft synth with the
>audio input from mics will give you a source of sample accurate events.
i don't get this. are you suggesting that you are reading from an ADC,
and then using the time implied by the sample count ? this will work
for some cards, and not for others (some don't use the same clock for
input as for output). It certainly won't provide sample accurate
timestamping if you use one card for input and one for output: clock
drift. OK, so if you use a Hammerfall and something else with word
clock syncing, its not a problem, but I didn't think that you wanted
to depend on this kind of hardware detail. I know that I don't. And
sure, you can play games to resync the cards every so often, but this
is not the making of a reliable system ...
>Not true with a driver that time stamps input data when the
>interrupts occur. (I did that back in the Amiga days...) And you
>shouldn't even need that with real "high accuracy" hardware.
not sample accurate though, just real-world accurate. If you're
running with +/- 0.5ms scheduling jitter (woo-hoo!), thats still a lot
of samples that may or may not have been generated so far by any given
plugin. The timestamp will be accurate, but there is no way to sync it
to the sample generation process. The best you can do is sync it to
the state of the DAC, as understood by the engine, which is well known
immediately after a write to the DAC has returned, but not known at
any other time.
in short, you can't get sample accurate timestamping unless you reduce
the control cycle to 1, which we're agreed is a bad idea.
>> So no, its true that Quasimodo's engine can't tell you the time with
>> sample resolution, but plugins know the time with sample
>> resolution. Strange, eh ?
>
>And? What to do with your perfect notion of time, when no one tells you
>exactly when to do things?
Ah, now we begin to get down to the meat (although I don't eat the
stuff :)
What *are* the events that might tell a plugin to "do something" ?
The class of events that I imagine to have important time properties
are those that reconfigure the processing net. Turning on a
plugin. Turning it off. Not much else.
When someone tweaks a MIDI CC, I expect the effect to take place right
*now*. When someone twiddles an on-screen control element, I expect
the effect to take place right *now*. I don't see where a notion of
"when to do things" enters into the area of parameter updates.
I consider a plugin to be a little piece of code that generates
samples according to an algorithm and the state of its parameters. It
doesn't change what it does unless you (1) change the algorithm, which
is nonsensical - the plugin *is* the algorithm (+) or (2) change the
parameters. The parameters can be updated in real time. So I can't see
what kind of effects you might be talking about.
Perhaps we have a different notion of what a plugin is ? It doesn't
seem that way, however.
(+) NOTE: this doesn't mean that the plugin can't contain conditional
code. But this is just handled with a parameter update. Consider a
plugin with a switch that toggles between two different choices. Right
now, the parameter that models the switch state is set to 1. Someone
clicks the GUI representation, and we decide to change it to a 2. No
problem: no timestamping needed - we just alter the parameter
asynchronously, and the plugin keeps running.
process (MyClosureType *closure)
{
while (samples_to_generate) {
if (*closure->switch_state == 1) {
... foo ...
} else {
... bar ...
}
}
}
There - we just told the plugin to do something, and it did it. No
events, no timestamps. What am I missing ?
>> >> if a plugin is executing in any given cycle, then its query of
>> >> the current time will always return the same value. that doesn't mean
>> >> there have been no events - its means its busy generating the same
>> >> output buffer (and working on the same input buffer) as everybody
>> >> else who will be executed during that cycle.
>> >
>> >"will be" is very important here.
>>
>> why ?
>They're not executed in parallel == not at the same time. Unless the
>code that "sends" events is blocked by the engine code, events may
>occur in the middle of the cycle - which means that some plug-ins
>will execute before that event and others after it. So, who which
>group does the event reciever belong to...?
Once again, what kind of events are we talking about here ? Things
that reconfigure the net don't get handled until the end of the
control cycle. But there aren't very many events that do that ... Most
of them are just parameter updates. These don't change what the plugin
"does" in the sense that it needs to be told about it. They may well
change the output of the plugin, but it doesn't have to care about
that :)
>I do appreciate your insightful comments, and I have had to do a lot of
>thinking at times to see if I'd really got things right. :-)
Likewise. I am enjoying the challenge of figuring out if Quasimodo's
system really does make as much sense as I think it does, or if I
missed something large, or if I missed something small. Its all good
stuff.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST