On Fri, 30 Dec 2005 15:17:04 +0000 GMT "Chris Cannam" <[EMAIL PROTECTED]> wrote:
Hi Chris, > > and midi events are not queued > > for future delivery but always delivered immediately. > > but this isn't -- Rosegarden always queues events > from a non-RT thread and lets the ALSA sequencer > kernel layer deliver them. (Thru events are delivered > directly, with potential additional latency because of > the lower priority used for the MIDI thread.) In > principle this should mean that only the priority of > the receiving synth's MIDI thread is significant for > the timing of sequenced events. Hi, i tested Rosegarden running with the system timer as timing source (RTC is a bit broken atm on -rt kernels for me), and i do not get satisfactory results. I used my ughsynth again (which is heavy on the cpu which makes the problems just clearer) with its midi thread at priority 95. Here's example output with rosegarden producing a supposedly steady stream of 16th notes at 120 bpm: note on, frame_time: 205200106 next event: 744 next event: 746 diff: 5998 note on, frame_time: 205206104 next event: 599 next event: 600 diff: 6042 note on, frame_time: 205212146 next event: 497 next event: 498 diff: 6157 note on, frame_time: 205218303 next event: 510 next event: 511 diff: 6140 note on, frame_time: 205224443 next event: 506 next event: 507 diff: 6145 note on, frame_time: 205230588 next event: 507 next event: 508 diff: 5511 note on, frame_time: 205236099 next event: 898 next event: 899 diff: 6000 note on, frame_time: 205242099 next event: 754 next event: 755 diff: 5998 note on, frame_time: 205248097 next event: 608 next event: 609 diff: 6034 note on, frame_time: 205254131 next event: 498 next event: 499 diff: 6153 note on, frame_time: 205260284 next event: 507 next event: 508 diff: 6141 note on, frame_time: 205266425 next event: 504 next event: 505 diff: 6148 note on, frame_time: 205272573 next event: 507 next event: 509 diff: 5521 note on, frame_time: 205278094 next event: 908 next event: 910 next event: 510 which is again in the range as with my test program and ughsynth having a low midi thread prio. This is clearly audible, too: http://affenbande.org/~tapas/rosegarden_ughsynth.ogg this is the rosegardenfile used for this: http://affenbande.org/~tapas/test16th.rg This would imply to me, that either the way the events are scheduled in rosegarden is buggy (unlikely as it works fine when there's less audio load on the system) or that the event queue delivery by ALSA is somehow happening with only SCHED_OTHER priority as well. I have not yet found an option for ALSA to configure this. > - ALSA sequencer uses kernel timers by default and > of course they only run at 100 or 250Hz in many > kernels. In my case i have compiled the kernel to use a system timer frequency of 1000hz. It would be interesting to know though what priority the ALSA event queue handling gets. I also stumbled across some problems with sleep() and especially waking up when the sleep time has expired in the course of writing my rt_watchdog program. Sometimes the high prio SCHED_FIFO thread wasn't woken up as long as a lower SCHED_FIFO prio thread hugged the cpu even when the sleep time of the high prio thread was long expired.. Ingo told me back then that there's extra kernel threads for the timing subsystem which need to be setup to high prios too for this to work correctly. Haven't really investigated further into this. I need to write another small test app that uses sleep based timing and a high prio, too, to drive ughsynth. Will report what results i get. > - ALSA sequencer can sync to RTC, but the > associated module (snd-rtctimer) appears to hang > some kernels solid when loaded or used. I don't have > much information about that, but I can probably find > out some more. I have never bothered to try this either. > - ALSA sequencer can sync to a soundcard clock, > but this induces jitter when used with JACK and has > caused confusion for users who find themselves > inadvertently sync'd to an unused soundcard (the > classic "first note plays, then nothing" symptom). > The biggest advantage of course is not having to run > an RT MIDI timing thread. My impression is that this > aspect of MusE (which does that, I think) causes > as many configuration problems for its users as using > ALSA sequencer queue timers does for Rosegarden's. > > Any more thoughts on this? >From my point of view just setting up a RT midi thread driven by RTC and with a sufficiently high prio for dispatching midi events immediately is the best way. As it seems to work well, at least for my small test case. Further testing needs to be done though. I will report back. I haven't really tried muse. Will do so if i find the time though.. Flo -- Palimm Palimm! http://tapas.affenbande.org
