From: Tim E. R. <ter...@ro...> - 2012-02-01 23:41:59
|
On February 1, 2012 8:56:19 PM Robert Jonsson wrote: > Hi Tim > > 2012/2/1 Tim E. Real <ter...@ro...>: > <...> > > >--- > > > > So as I mention in the change list, when using long-period audio, > > seems ALSA midi is still the best way in MusE. That 1000Hz timer helps. > > But at audio periods of say 32 or or lower, processing in audio thread > > wins. Heck, without realtime my best timer seems to be 250Hz, so audio > > wins even at period size of 128. > > So I came up with an idea to automatically detect and switch from using > > the midi thread, to using the audio thread, for processing ALSA when > > audio period is small enough that it's more advantageous than a > > separate thread with a timer. Thoughts Robert? We talked about this > > kinda thing long ago... > > We did? Perhaps, can't recall :) > I skimmed the changelog, are you saying there are drawbacks to using > the midi-thread for midi timing if you have small audio buffers? Yes. At some point the small-period audio gains the advantage, right? > Having several ways to do it provides nice configurability but also > complexity...as long as we remember this I'm fine. > In any case I vote against doing automatic switching behind the > curtains, it tends to get unpredictable. I'm note sure I like the > automatic timer selection we do now (though I was part of implementing > it). Consider that Rosegarden and I think QTractor allow to select from which timing source midi is driven from. I think they allow alsa timers as well as the audio process to drive midi. It makes sense. Whichever timing source has the best resolution should drive the midi processing. Our timing selection should probably finally 'grow up' like that and present the user with a choice. After all, it's just selecting what drives the midi processing... Just that while I was in there, I found our midi thread kinda 'bogs down' the audio thread slightly. It would be so nice if we didn't have to use it and synchronize the two threads. There is 'danger' in that our midi thread has the ability to make the audio thread wait, if the midi thread was busy. On top of that, we have a 'do while' loop in our ALSA putEvent which could make audio wait. AIUI these are not good practices. At some point I will try to make ALSA driver use our eventFifo ring buffer in order to decouple from audio. Also, the MESS synths do not use the eventFifo, and thus we are forced to use msgPlayMidiEvent from GUI controls, because it absolutely must be synchronized with audio. With large audio buffers, adjusting a midi control (vol, pan sliders etc) is painfully slow. So if I fix this we can finally eliminate msgPlayMidiEvent so that midi GUI controls respond quickly. Oh well, 'till later... Take care Robert. Tim. > > Regards, > Robert > |