Subject: Re: [linux-audio-dev] Re: RFC: Disposable Soft Synth Interface
From: Tim Goetze (tim_AT_quitte.de)
Date: Mon May 03 2004 - 13:35:24 EEST
[Jens M Andreasen]
>I should have included some kind of man page:
>
>> msg[0] = midi_status;
>> msg[1] = midi_data_1;
>> msg[2] = midi_data_2;
>> msg[3] = sample_offset; // counting from most recent rendering.
>
>> Personally I can ignore sample_offset, but to others it is a
>> prerequisite.
>
>... and I realize now that I should not totally ignore sample_offset. I
>would probably try to change the internal status to fit with 64/32/16
>samples, or whatever is the rendering fashion of the day.
>
>And one more thing: The host should do the sorting and interleaving of
>events from those devices it listens to. Not that it will break anything
>if it doesn't, but if it do, then everything will be so much more tight
>and solid. That is to say that the client(s) need not to bother about
>time, except for beeing aware that time might not be 100% linear.
agree about the sorting of events (which btw is mandatory for the
host with run_synth() following <dssi.h>).
however, i insist that the midi_msg() idea deters performance by
forcing the host to split audio blocks (cache coherence and more
indirect function calls). in effect, run_synth() demands less from the
plugin (no MIDI byte stream parser with error correction mechanisms
needed), thus results in more readable event parsing code and leaves
the decision about sub-cycle length to the plugin, which is a good
thing.
it also seems worth noting that forcing an event's audio frame offset
into 8 bits is a bit meagre. it's not uncommon to run at 2+ k frames /
audio cycle, and some interfaces and systems won't go below 512
frames/cycle in the first place. off-line processing may even involve
a lot longer audio cycles.
tim
This archive was generated by hypermail 2b28 : Mon May 03 2004 - 13:38:37 EEST