Hi Robin, On 19-Nov-08, at 8:55 PM, Robin Sheat wrote:
> So, I've been playing with MIDI a bit in the past couple of days, > helping > making sure the impending release of the Hercules driver is as > smooth as > possible (for anyone interested, I expect it to be released in the > very short > term, and Mixxx pretty much completely supports it now). > > I've got a couple of things I want to have a look at given time. > Note that I > haven't even attempted to look at the MIDI code just yet, so this > might be a > little premature, but I figured it was worth seeing if there was any > reason > to not do what I'm planning. > > 1) Apparently we send a MIDI 'system reset' command when Mixxx exits. > According to the MIDI specification, we should really not do this > without a > good reason. I'm thinking of having a 'set all LEDs to off on > startup and > shutdown' routine to replace this. I have no idea about this, you're going to have to poke at the MIDI code to find out what's going on here. Perhaps our new MIDI mapping spec should include a scriptable section for what MIDI commands to send when closing a particular device. I agree that we shouldn't be sending anything crazy like this at exit though. > > > 2) Try logging the MIDI commands sent when music is playing. We send > a command > for every LED, as fast as we can, for the VU meters. This is > probably not a > great deal of load, but it may help the machine just a little bit > (and will > certainly help MIDI debugging) to cache LED state, and only send > commands > when they need to change state. Spewing out many commands is a great > way of > discovering driver issues that appear under stress though, it turns > out :) > Along with caching, perhaps also add a timer to the VU handling code > so that > it doesn't run quite so frequently. Haven't looked at it, so I don't > know if > that's possible yet. I _think_ these MIDI LED commands are getting sent once per audio buffer (so if your latency is 5 ms, then they're getting sent every 5 ms). If you want to make this less frequent, perhaps you can change midiledhandler.cpp to cache it. The cache length should depend on the latency value though, which you can get in the code from a config object thingy. A quick calculation here shows a possible source of the problem: The MIDI baud rate is 38400 bps, and if each MIDI LED command is 16- bits, and is being sent 1000 times/second (1ms latency), then that uses up about half of the MIDI bandwidth we have. If we're sending multiple MIDI commands to trigger the LEDs at 1ms latency, we can easily push past the available MIDI bandwidth and probably cause all sorts of problems. So yes, you shouldn't be able to push more data than the MIDI spec says, regardless of your latency. Patches welcome. :) Thanks, Albert ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
