Re: Jack MIDI timestamping Was: Re: [linux-audio-dev] What parts of Linux audio simply suck ?

From: Stéphane Letz <letz@email-addr-hidden>
Date: Mon Jun 20 2005 - 17:01:58 EEST

Le 20 juin 05 à 14:33, Benno Senoner a écrit :

> Stéphane Letz wrote:
>
>
>>
>>
>> Good question....
>>
>> I would say that one the may problem is that jack MIDI does not
>> has the concept of time-stamps in the "future" . The Jack MIDI
>> "events" are received in real-time (similar to what MidiShare does
>> with the Receive callback concepts) but have also to be delivered
>> in real-time.
>> In the absence of any scheduling mechanism, I don't think the
>> MidiShare API could be re-built on top of the underlying Jack MIDI
>> buffer transports system.
>>
>
> I did not look at the jack midi API yet but what do you mean with
> time-stamps in future ?
> timestamped MIDI events relative to the current audio fragment or
> in future in general, eg deliver this midi event
> in 100000 samples starting from the current position ?
>
> I think it's probably enough that jack provides the former.
> eg my audio fragment is 128 frames
> note on ch 1, note 60 velocity 100 at frame 20
> note on ch 1, note 64 velocity 80 at frame 100
>
> so the timestamp is always between 0 and 127 (fragmentsize).
>
> AFAIK VST does it what way and sequencers are perfectly fine with
> that scheme.
>
> I don't believe the future timestamping (with timestamp >
> fragmentsize) provides many advantages
> since it leads to long queues and poor interactivity.
> Eg if I want to modify the midi data in real time the first
> approach works better since the latency
> of the modifications to the midi data becoming audible will be only
> 1-2 audio fragments.
>
> I think that the argument of needing a kernel based midi API that
> timestamps event is the future because
> the user space processes cannot provide decent timing is moot these
> days because of the excellent RT performance
> of Linux and that often sound generation is internal (eg virtual
> midi instruments/samplers) so having
> jack that handles midi+audio can provide better timing (sample
> accuracy) than the ALSA sequencer and simplifies
> the programming of virtual midi synths/samplers. (no RT midi
> sensing thread etc).
> Look at VST: 2 simple callbacks: processEvents() and process() to
> implement sample accurate virtual instruments.
>
> Thought ?
>
> cheers,
> Benno

I was only answering to the initial question of wether a MidiShare
like API (where event scan have future timestamps, to be delivered at
their due time to clients by the mean of a scheduler) could be built
on top of the jack Midi API the way it is designed. And the answer is
probably not.

Stephane
Received on Mon Jun 20 20:15:11 2005

This archive was generated by hypermail 2.1.8 : Mon Jun 20 2005 - 20:15:12 EEST