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

[Stéphane Letz]

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