Paul Davis wrote: >>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.
:) That's a great argument to throw at somebody who cannot afford better hardware, don't you think? Not that I would not like to see firm timers in Linux though. tim
