On September 20, 2012 3:28:10 PM Robert Jonsson wrote: 2012/9/20 Tim E. Real <[email protected]>
On September 19, 2012 3:18:19 PM Robert Jonsson wrote: Hi Luis 2012/9/19 Luis Garrido <[email protected]> > > Robert and Luis are both right. > Jack Midi offers the advantage of frame-precision, but with large > Jack buffers there is midi latency. And there's nothing you can > do about it, just like audio latency, for 'live' playing. > With pure Jack midi you could be waiting up to *two* periods - > one record and one playback cycle. Not good. > A separate ALSA or other timer on the record side offers *some* > immunity to this. > In theory the latency could be halved - reduced to nothing on the > record side but still there's Jack midi playback latency you can't > get around. > In fact live players using large Jack audio buffers may be better served > by using only ALSA for /both/ record and playback. But of course then > there's the audio latency... > So that's why I argued against completely removing ALSA support. > > > > Yes, I see. It's good we mostly know the drawbacks! > For serious midi usage (with hardware synths) using jack-midi is definitely a step backwards so we need to keep the ALSA option. > Making ALSA optional is fine by me though, as long as it does not mean the support for good timing is lost. > When I record I usually use small audio buffers so the impact on myself is not so big. > > > I even spoke of a hybrid system in which we use Jack midi, > but at large buffer sizes we automatically choose between Jack > and the ALSA or other timer for the best timing. Thus satisfying 'live' > realtime performers. > > > > I'd argue against that, I think it's better to leave this choice to the user. If needed we can improve information to the user to make a qualified choice. > > So having ALSA and a separate timer is very important. > Whether it be ALSA or HP or RTC, it's good to have one. > That's why I was so hesitant to force the -A switch, hope it was > a good idea... > > > > Yeah. We'll give it a bit more time. If needed we can change it again.. > > > Regards, > Robert > Still one must take all of this with a grain of salt. If you are intending to use both audio and midi and are running large Jack periods, you're gonna have audio latency anyway, so using ALSA for the midi is only going to help somewhat. On the other hand, if you intend to use only midi, chances are you will be able to run much lower Jack periods, because with audio there is much more time needed for plugins, apps etc whereas with midi it is unlikely there will will be any time-consuming midi plugins. A period of 256 or less is acceptable, not easily noticed. I should point out that with Jack midi, there is recorded latency in MusE, similar to the audio latency which I've been discussing and added the 'wave offset' feature for. That is, if you run 2048 Jack period, your recorded midi tracks are going to have 2048 sample latency! This is why I added an experimental flag _AUDIO_USE_TRUE_FRAME_ settable in audio.h, which automatically eliminates this latency in the Jack midi module when recording. But I had intended for it to also automatically control audio latency, but that turned out to be /much/ more difficult and I had to be satisfied with my simpler 'wave offset' adjustment for now. So perhaps I'll take another look and maybe just enable _AUDIO_USE_TRUE_FRAME_ for Jack midi for now, while I wrap my brain around what needs to be done on the much more complex audio side. I uh, suppose it could be argued that we could add a corresponding 'note offset' adjustment, but I don't think it'll be required - the _AUDIO_USE_TRUE_FRAME_ flag /should/ be able to handle Jack midi latency automatically without user intervention IIRC. Tim. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
