30 Dec
2005
30 Dec
'05
4:27 p.m.
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.
You guys are talking here about MIDI timing, considering only the event
scheduling point of view, as if Rosegarden or MusE were simple MIDI players.
Of course, playing beats on time is a required feature. But my bigger concern
about MIDI timing issues is when you are *recording* events. Here is where
ALSA queues, providing accurate timestamps for incoming events, are so good.
It could be the absolute winner if problems like the audio synchronization
and slave MTC synchronization were solved likewise.
Regards,
Pedro
30 Dec
30 Dec
5:08 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
On Friday 30 December 2005 17:37, Werner Schweer
wrote:
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.
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. You guys are talking here about MIDI timing,
considering only the event
scheduling point of view, as if Rosegarden or MusE were simple MIDI players.
Of course, playing beats on time is a required feature. But my bigger concern
about MIDI timing issues is when you are *recording* events. Here is where
ALSA queues, providing accurate timestamps for incoming events, are so good.
better than an RT user space thread? sure. by a few microseconds.
It could be the absolute winner if problems like the
audio synchronization
and slave MTC synchronization were solved likewise.
what problems? JACK demonstrates perfect audio sync in the only sensible
way there is (the same way every other system does it); several JACK
clients have MTC slave capabilities, including ardour, and it has
nothing whatsoever to do with the ALSA sequencer.
5:58 p.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
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:
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.
2. Translating from data having an implicit or explicit timestamp
associated with it, to a physical signal having a real physical time is
something that belongs at the system or even hardware level, just as it
does for audio.
When you are dealing with midi in software, it should just be timetagged
data, just as audio samples are. The only place where the timing matters
is when midi is output on a real electrical midi port.
Trying to deliver e.g. note-on events from a software sequencer to a soft
synth exactly 'on time' is a waste of effort - what the synth needs to know
is not 'when' on some physical time scale the note starts, but at which
sample it should start. In other words, the note-on event needs a timestamp
that can be converted easily to a frame time.
--
FA
On Friday 30 December 2005 17:37, Werner Schweer
wrote:
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. 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.
31 Dec
31 Dec
8:02 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
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:
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:
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. 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. 2. Translating from data having an implicit or
explicit timestamp
associated with it, to a physical signal having a real physical time is
something that belongs at the system or even hardware level, just as it
does for audio.
When you are dealing with midi in software, it should just be timetagged
data, just as audio samples are. The only place where the timing matters
is when midi is output on a real electrical midi port.
Trying to deliver e.g. note-on events from a software sequencer to a soft
synth exactly 'on time' is a waste of effort - what the synth needs to know
is not 'when' on some physical time scale the note starts, but at which
sample it should start. In other words, the note-on event needs a timestamp
that can be converted easily to a frame time.
well, clearly, yes. but the point of the ALSA sequencer's queuing
abilities (as distinct from its routing abilities) is really to schedule
stuff "far off" in the future. my claim is that live applications never
need scheduling beyond the of the end of the current period. as a
result, for this class of applications, most of the ALSA sequencer's
capabilities are redundant, which is compounded because it currently has
no way of providing sufficiently accurate scheduling (to be fair, at the
moment neither does user space).
10:55 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote:
In a live situation, yes. In that case there is no point at all to try
and deliver events with sub-cycle accuracy, except to a physical port.
For a soft-synth you don't even know _when_ in the cycle its audio code
will be called. So all events should be available at the start of the
cycle, and if you need sub-cycle precision or minimal jitter, be
timetagged.
On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen
wrote:
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. well, clearly, yes. but the point of the ALSA
sequencer's queuing
abilities (as distinct from its routing abilities) is really to schedule
stuff "far off" in the future. my claim is that live applications never
need scheduling beyond the of the end of the current period. as a
result, for this class of applications, most of the ALSA sequencer's
capabilities are redundant, which is compounded because it currently has
no way of providing sufficiently accurate scheduling (to be fair, at the
moment neither does user space).
Whatever system becomes available to user space can be used by ALSA as
well, so ALSA will never be in a worse situation than any app.
Even in a live context you may want to schedule e.g. MTC events in the
near (but more than 1 cycle ahead) future. Having a central scheduler
you could arrange for them to have priority over anything else. This
would be quite difficult to do when for example one app is scheduling
its MTC events and anothor produces a stream of control events going
to the same port.
--
FA
1 Jan
1 Jan
7:25 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
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. 
8:45 a.m.
New subject: [linux-audio-dev] Audio/Midi system - RT prios..
On Sun, 1 Jan 2006 13:18:09 +0100
torbenh(a)gmx.de 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.
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.
Of course in my original post i assumed that softsynths use this second
scheme (with exactly one period extra delay) otherwise all the hassle
with midi thread priorities would be void anyways:
"Anyways, one more thing to note is for this to work nicely, the
softsynth needs to have an extra midi handling thread that is also
running with a priority in the 90s range, so it can timestamp the event
properly when it arrives."
"The interesting number is the "diff" output as it tells us the
difference of the previous midi event timestamp to the current one.The
"next" field is the offset into the currently to-be-processed period."
Only implicitly so, but let's assume the scheme you mentioned as given
from now on. Paul's post was a bit ambiguous though i must admit.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
6782
days inactive
6784
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Florian Schmidt -
fons adriaensen -
Paul Davis -
Pedro Lopez-Cabanillas -
torbenh＠gmx.de