Re: [linux-audio-dev] Audio/Midi system - RT prios..

From: <torbenh@email-addr-hidden>
Date: Sun Jan 01 2006 - 14:18:09 EET

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:
> > On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul Davis wrote:
> > > On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
> > > > 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.
> >
> > 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.
>
> 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.

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
Received on Sun Jan 1 16:15:04 2006

This archive was generated by hypermail 2.1.8 : Sun Jan 01 2006 - 16:15:05 EET