1 Jan
2006
1 Jan
'06
8:25 a.m.
On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote:
On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen
wrote:
to remove jitter i would delay all events i recive during one period
calculation by one period. so exact timestamping is very vital.
there are only 2 things a live setup can do with an event received
during calculating the current audio buffer.
1. play as fast as possible... results in midievents jittering to period
boundaries.
2. add some fixed delay so that if the events were received in 10 sample
clocks distance they are injected into the system with a 10 sample time
distance.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul
Davis wrote:
in a low latency *live* system, "timing" doesn't really exist outside of
the current period. there is no concept of "when" that exists beyond the
end of the current period. On Fri, 2005-12-30 at 22:27 +0100, Pedro
Lopez-Cabanillas wrote:
I'd agree with Pedro on this.
1. If things have to be timed accurately, it seem logical to concentrate
this activity at one point. At least then the timing will be consistent,
you can impose priority rules in case of conflict, etc. On Friday 30 December 2005 17:37, Werner Schweer
wrote:
> The ALSA seq api is from ancient time were no realtime threads were
> available in linux. Only a kernel driver could provide usable
> midi timing. But with the introduction of RT threads the
> ALSA seq api is obsolete IMHO.
I don't agree with this statement. IMHO, a design based on raw MIDI ports used
like simple Unix file descriptors, and every user application implementing
its own event schedule mechanism is the ancient and traditional way, and it
should be considered obsolete now in Linux since we have the advanced
queueing capabilities provided by the ALSA sequencer.
low latency apps don't want queuing they just want routing. this is why
the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the
right idea back when he started this, but i agree with werner's
perspective that the queuing facilities are no longer relevant, at least
not for "music" or "pro-audio" applications.