On 5/4/06, Lee Revell <rlrevell(a)joe-job.com> wrote: Okay, you're right, should have been more specific. I have the local turned off on my keyboard, so that when I play a note on the keyboard, the MIDI signal passes through MusE, and back to my keyboard's sound generator. The latency I'm referring to is the time between pressing a key on my keyboard and hearing the actual sound. It's a pretty bad lag. Roland RD-700SX, my keyboard/MIDI controller.

On 5/5/06, Lee Revell <rlrevell(a)joe-job.com> wrote: This is a new term to me. What does HZ mean, and how do I grep for it in my kernel config?

On 5/5/06, Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> wrote: Here's mine: CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_MACHZ_WDT=m

On Fri, 2006-05-05 at 12:32 -0500, Josh Lawrence wrote: It's the kernel's internal tick rate and will determine the best achievable MIDI output latency. The default changed from 1000 (1ms ticks) to 250 (2.5 ms ticks) around 2.6.12, over the objections of the linux audio community. grep HZ /boot/config-`uname -r` or zgrep HZ /proc/config.gz if you have those files. It should be 1000 for optimal MIDI latency. I actually discussed this with Joachim from the MuSE team at LAC - we need a way for applications that need a low latency capable kernel to discover whether the kernel is good enough. One option would be to simply make MuSE depend on a "known good for audio" kernel in the package manager which is probably too aggressive, and not reliable enough. A better solution would be to have a simple, user friendly app that does a latency test and reports the results, and if a problem is found would recommend that the user upgrade the kernel, change some config options or file a bug report with their distro. Unfortunately it's a tricky problem, as you can see there's not even a distro independent way to check the kernel config. Lee

Josh Lawrence wrote: I tried to look at MuSE's source to see how it implements MIDI Through, but apparently MuSE doesn't do anything MIDI related.

How did you connect the keyboard to MuSE? Are you using Jack MIDI? Regards, Clemens

On Mon, 2006-05-08 at 22:15 +0100, Robert Jonsson wrote: What is /proc/sys/dev/rtc/max-user-freq set to?

Robert Jonsson wrote: Oops ... It shouldn't be necessary to reschedule the events, they could be sent back out immediately; no timer is needed for that.

Additionally, it seems MusE doesn't use ALSA's timestamps for received events but manually looks at the timer when it comes around to reading the events. This will somewhat degrade the accuracy of received events.

On Tue, 9 May 2006 12:43:29 +0200 Werner Schweer <ws(a)seh.de> wrote: Reducing jitter and providing a constant latency is the softsynth's job, Not MusE's [well, MusE should of course introduce as little extra delay as possible to minimize latency and jitter]. MusE should simply send out the MIDI event as soon as it has received it [we do still talk about MIDI _through_ right now, no?]. If MusE actually added another two JACK cycles, the resulting latency would be four JACK cycles as the softsynth would add another two JACK cycles itself. The only case where MusE would have to care about this would be when itself were a softsynth. Or maybe when playing recorded tracks of which one goes to a hw synth outside the computer and the other goes to a softsynth. In this case it would make sense to delay the MIDI stream that goes to the hw synth outside the computer by two JACK periods because that's the delay the softsynth will have, too, resulting in both being again played in sync. Maybe we have a complete misunderstanding here, though.

Flo