>Paul Davis wrote: > >>>I find that for sending MIDI to an external device, "resolution = RTC >>>Hz" works very well. It is a problem that a realtime audio thread >>>'suffocates' a RTC thread if low-latency is required, and only one >>>processor available. It's very hard to find a clean solution in this >> >>why not just run the RTC thread at a higher priority? or does that >>cause other problems? > >The problem is I write(2) MIDI from within the RTC thread; with the >drivers/hardware we have I see no other way to ensure the bandwidth >is used optimally and that MIDI clock is precise. (Sidenote:) That's >also why I think firm timers don't help much; CC/pitch bursts must be >fed to the interface that way, not to think of sysex. > >When writing to MIDI ports, some (especially the cheap) interfaces >will block in kernel for generous amounts of time. Poll(2)ing for >a write possible condition is not an option, on the AWE for example >this can give up to 30% constant load in kernel. Ouch.
please learn what i consider to be an invaluable lesson: software that uses cheap stuff to do cool things is great. software that tries to cover up the flaws in cheap stuff is a waste of time. the creative MIDI hardware is just so bad, its really pointless trying to make it work like this. just use a card with a decent size FIFO, and then you will find that write(2) will never block unless you are generating more data than was received by the port. >For these reasons, I haven't yet seriously thought of running the RTC >thread at a higher priority, though now I think maybe my stance should >be reevaluated? from the perspective of the audio thread, it doesn't matter the RTC thread blocks, in fact its arguably a good thing. --p
