Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: .n++k (Knos_AT_free.fr)
Date: Wed Jul 24 2002 - 16:41:49 EEST
/wrote Paul Davis
| i believe that relative nanosleep is better than absolute sleep for
| the simple reason that its how you would avoid drift in
| practice. consider a JACK callback:
|
| process (jack_nframes_t nframes)
| {
| jack_transport_info_t now;
|
| /* find out the transport time of the first audio frame
| we are going to deal with
| */
|
| jack_get_transport_info (client, &now);
|
| /* get the set of MIDI events that need to be
| delivered during the period now.position to
| now.position + nframes
| */
|
| event_list = get_pending_midi_events
| (now.position, now.position + nframes);
|
| foreach event in event_list {
| queue_midi_event (event);
| }
|
| ... anything else ...
| }
|
By the way, I remember talks around here or jack's mailing list on the
issue of non constant frame number passed to the process callback... I
don't remember if anything was decided, but i was thinking it would be
nice to leave it bounded but non-constant, just for being able to
design an app like this:
core_process(...)
{
/* get midi input events */
foreach event in event_list {
process(/* zone spawned until event */);
handle_event(event);
}
}
Does that sound like a decent design?
(For performance reasons one would probably need to coalesce nearbie
midi events, but at least there you can control the jitter.. i'm not
even convinced this would be needed)
Maybe a libjackmidi could standardize such an api..
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 17:18:43 EEST