Pedro Lopez-Cabanillas wrote:
There aren't synchronization capabilities in ALSA sequencer 1.0, but I don't know why. You can ask in ALSA-devel mailing list.
Thanks for the clarification. I've dl'ed and looked at the latest ALSA source; and indeed, while there are some #defines for MTC-driven sequencer queues, no actual code.
Does the above make any sense? :) Has anyone else sketched out approaches to implementing MTC slave support in RG?
It is very interesting, but without ALSA sequencer support for slave synchronization it seems undoable to me.
All may not be lost. While a sequencer queue can only be driven off ALSA's internal timers, it can have its skew adjusted on the fly. The skew is set as a 16-bit number. 0x1000 is "normal", 0x2000 is "run at double speed", 0x0800 is "half speed".
In order for MTC to be useful (as opposed to being a "perfect" implementation), all that is needed is some way for the sequencer to get in synch with the MTC/SMPTE time stream and stay there (or close enough). And given an MTC source like a digital recorder, the two clocks will be almost synched merely by being started at the same time: they will drift out of sync slowly.
So, if the initial MTC "Full message" sets the song pointer and the first "quarter-frame" message thereafter starts the sequencer running (as per MTC spec), then at the point of next full timecode (2 frames later) we can measure the disparity between MTC clock and ALSA clock. The ALSA clock can then be skewed by an amount proportional to the disparity. In another two frames time, we check again, and so forth until the ALSA clock is sufficiently close to the MTC clock (allowing for latencies), at which point we set the skew back to 0x1000. Thereafter, staying in synch should merely involve small tweaks of the skew (to 0x1001 or 0x0fff for short periods) in a sort of feedback arrangement, which should be close enough to be a useable solution.
Some experimentation would be needed to find the best "skew factor" to be used during the initial "getting in synch" phase, but I would imagine
that a 2-bar pre-roll period would be enough in practise.
If this method worked well, then it might be possible to fold it into ALSA itself and thus reinstate the native MTC sync support. That would be nice as then all ALSA-based Linux sequencing sw would benefit..
Well, it looks like I've talked myself into taking this further. :-)
I am in the process of re-wiring the studio and commissioning a new PC for it; then I'll be able to try some actual coding experiments.
Question: - is the convention to post patches to the devel-list, or to SF's own patches facility?
Vince
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Rosegarden-devel mailing list [EMAIL PROTECTED] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
