2012/9/19 Florian Jung <florian.a.jung@...>
> Am 19.09.2012 10:16, schrieb Robert Jonsson:
> > Making ALSA optional, to remove a dependency is well and all, but I worry
> > it means changing the internals in a way that we loose timing, both
> > and jitter.
> > This is mostly just a fear and it's not necessarily true, I just wish us
> > be aware of this risk.
> i still don't fully get the reason why we need such a timer, as long
> we're only using jack devices.
> is there nowadays any need for ALSA devices? i mean, for audio we use
> jack. for midi we are able to use jack as well. jack-midi doesn't give
> us any disadvantages as far as i see this, right?
I am not convinced that using jack-midi is without drawbacks.
To my understanding jack-midi works in the same interval as audio. (Maybe
Tim can validate this as it is fundamental to my worries?)
So with buffers of 1024 bytes at 48khz we would get roundtrip latency up to
20ms (or is that 40ms).
The events will likely be timestamped with high precision so the recorded
events will occur at the right position, but the playing experience will be
But I'm speculating here. I'll setup a test in the coming days to verify
the latency of our current support.
> thus we can muse fully run as jack-only client (which may or may not
> provide _additional_ alsa/ffado/whatever support).
> that means that we mainly orient ourselves on the process()-calls we're
> getting from jack. (jack does all the timing stuff for us)
> there is no need for a timer, we just rely on jack to a) call us with
> exact, constant rate, and b) to not jitter our buffers. both are fulfilled.
> my point is that both (midi-)sequencer-code AND audio code belong in a
> jack-process()-callback. then we can relax and don't have to worry about
> timers. PLUS, we finally can freewheel with midi!
> alsa support does not need to be dropped. we can still offer to use alsa
> devices, possibly implementing a timer again. but my point is, this is
> freeBSD users would just turn off alsa support, then they have a
> jack-only application which runs on every OS jack runs on. (which is:
> every OS.)
> > I'm not sure how this is implemented in jack but running with big buffers
> > won't that directly incur a latency penalty that we are completely immune
> > to with the alsa sequencer support?
> i don't exactly know. but read this:
This only explains that jack does not add any extra buffering. There are
still buffers that add latency.
> MIDI and audio are not fundamentally different for jack. both are
> "streams" which are routed around. (just MIDI is discrete, not
> continous, but that's functionally equivalent).
> that is, for MIDI, exactly the same restrictions apply as for audio:
> theres exactly $latency added. not more. not less.
> does MusE in its current way add latency to MIDI as well? i'm not sure,
> but i think it does.
Midi in it's purest form in MusE adds very little latency.
Roundtrip midi keyboard -> alsa -> muse -> alsa -> midi output device,
should be just a few ms.
I haven't measured this but if it is working correctly the added latency
should not be much more than the timing source adds. In the case of
alsa-timer at 1000hz (which is what we request), we should get <1ms delay
(maybe it's double that, since it's in and out).
> (my thought for this: we want to keep audio and midi in sync. so we
> anyway WANT the same latency for MIDI like we have for audio.)
> so, we can choose between having jack-latency for audio and alsa-latency
> for MIDI, which we need to synchronize somehow, and having jack-latency
> for both. no need to synchronize.
> please correct me if i'm wrong, but i still think jack is the way to go.
> and if there are disadvantages of jack-midi vs alsa-midi: tell me!
Yep, that was my point :) I'll do some tests clear this up.