Menu
▾
▴
Re: [Lmuse-developer] Fixes to midi sync 'Clock Output'. Please try it now...
|
From: <son...@ii...> - 2009-03-13 04:03:29
|
On Fri Mar 13 14:10 , Tim sent: >I've always had better luck with lower numbers in muse but maybe > I'm wrong. Sometimes it's hard to tell, I get inconsistent results. >BTW What is the polarity of jackd's priority setting? AFAIK the higher the better.. On slower systems this appeared to give better results, on my current system there is no noticeable difference.. > >On March 12, 2009 10:56:55 pm son...@ii... wrote: >> On Thu Mar 12 22:07 , Tim sent: >> >**Please run muse on the command line and let me know if, and how often, >> > you get messages (which I added, permanently, to muse) like this: >> >Dropped 6640 midi out clock(s). curTick:177070 midiClock:70828 div:16 >> > >> >I recoded MidiSeq::processTimerTick(). >> >Tested OK with external synth, with multiple tempo changes >> > in song, and fooling around with global tempo. >> > >> >For best results please try running muse with a HIGH midi thread priority >> > (-P command line option, I believe lower numbers are higher priority - >> > try 1, not zero). >> >> I think this is actually the other way around.. I've had more success with >> higher numbers.. I don't think this works the same as "nice" values... >> >> >AND >> >Make sure the RTC resolution configuration setting is high (8192 best). >> > >> >**Warning: You may be disappointed by the target device's slow drift out >> > out of phase with muse (after about 20 bars or so). >> >Other times, when moving the cursor around and playing, you may >> > have severe phase difference. Try playing from song beginning... >> >Still some tweaking the code may be required, or replacing with >> > something more reliable, as I mentioned before. >> > >> >Tim. >> > >> > >> > >> >--------------------------------------------------------------------- >> >Here are some rambling comments from MidiSeq::processTimerTick(), >> > for those of you too lazy to read the function: >> >--------------------------------------------------------------------- >> >// Keeping in mind how (receiving end) Phase Locked Loops (usually) >> > operate... // Increment as if we had caught the timer exactly on the >> > mark, even if the timer >> >// has passed beyond the mark, or even beyond 2 * div. >> >// If we missed some chances to send clock, resume the count where it >> > would have been, >> >// had we not missed chances. >> >// We can't do anything about missed chances except send right away, and >> > make up >> >// for gained time by losing time in the next count... >> >// In other words, use equalization periods to counter gained/lost time, >> > so that >> >// ultimately, over time, the receiver remains in phase, despite any >> > short dropouts / phase glitches. >> >// (midiClock only increments by div units). >> >// >> >// Tested: With midi thread set to high priority, very few clock dropouts >> >ocurred (P4 1.6Ghz). >> >// But target device tick drifts out of phase with muse tick slowly over >> > time, say 20 bars or so, >> >// I believe because of the frequent major shifts (below). >> >// May need more tweaking, possibly use round with/instead of lrint >> > (above), and/or >> >// do not use equalization periods - set midiClock to fractions of div. >> >// >> >// Another issue: Sync pulses occasionally have a major shift to the left >> > (and seem to affect >> >// the next several pulses). >> >// This couldn't be caused by us sending the sync message here, at that >> > time (look at this block's conditional). >> >// This might be caused by the queue, further down the pipeline, but I >> > thought our queue is in 'direct' mode? >> >// Found some info about a experimental special sync queue by Takashi at >> > alsa (2000). >> >// www . alsa-project . org / ~tiwai / alsa-sync . html >> >// Maybe using that would solve stability issues. >> > >> >-------------------------------------------------------------------------- >> >---- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> > are powering Web 2.0 with engaging, cross-platform capabilities. Quickly >> > and easily build your RIAs with Flex Builder, the Eclipse(TM)based >> > development software that enables intelligent coding and step-through >> > debugging. Download the free 60 day trial. >> > http://p.sf.net/sfu/www-adobe-com >> > _______________________________________________ >> >Lmuse-developer mailing list >> >Lmu...@li... >> >https://lists.sourceforge.net/lists/listinfo/lmuse-developer >> >) >> >> --------------------------------------------------------------------------- >>--- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Lmuse-developer mailing list >> Lmu...@li... >> https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > > >------------------------------------------------------------------------------ >Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >easily build your RIAs with Flex Builder, the Eclipse(TM)based development >software that enables intelligent coding and step-through debugging. >Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >_______________________________________________ >Lmuse-developer mailing list >Lmu...@li... >https://lists.sourceforge.net/lists/listinfo/lmuse-developer >) |