Bad MIDI performance : 10ms latency instead of the expected 1-1.5ms

Bad MIDI performance : 10ms latency instead of the expected 1-1.5ms

[Benno Senoner]

Hi folks,

I finished my MIDI performance tests:  ( DISAPPOINTING  :-(  )

I did basically the following:
connected the external MIDI-out of my AWE64 to the MIDI-in port with a MIDI
cable.
Then I wrote a little app which opens the midi device in O_RDWR mode
and then does
time1=gettime() 
- write 3 bytes to the midi device ( to simulate a Note-on cmd)
- read back the data
time2=gettime()
prints out the timediff

I tested both a 2.2.5 and a 2.2.10 kernel , same results.

I wrote this to measure the MIDI output-to-input delay.
I tried both with blocking I/O and non-blocking I/O.
Unfortunately I get bad values in both modes:
about 11.5ms , and this is exactly the MIDI transfer time (1.3ms) plus
10ms = 1 jiffie.
If I run the test on a HZ\x1000 kernel I get about 2ms.

11ms is not acceptable to implement realtime MIDI processing apps,
like soft-synths, virtual midi-thru boxes (or via sequencers), midi-filters etc.


Does anyone know if there is a way to get the values down to the effective
transfer time. ?

 ( are there lowlatency serial flags similar to those of the
regular serial devices ?)

You can get my mididelay benchmark here:

http://www.gardena.net/benno/linux/audio/mididelay0.1.tgz

Do you get better values on ALSA ?

comments ?

PS: Paul: I was wrong about not being able to open the midi device in
O_NONBLOCK.


regards,
Benno.

Benno Senoner
E-Mail: sbenno@gardena.net
Linux scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

Re: Bad MIDI performance : 10ms latency instead of the expected

[Jaroslav Kysela]

On Thu, 26 Aug 1999, Benno Senoner wrote:

> On Thu, 26 Aug 1999, Jaroslav Kysela wrote:
>  
> > > I wrote this to measure the MIDI output-to-input delay.
> > > I tried both with blocking I/O and non-blocking I/O.
> > > Unfortunately I get bad values in both modes:
> > > about 11.5ms , and this is exactly the MIDI transfer time (1.3ms) plus
> > > 10ms = 1 jiffie.
> > > If I run the test on a HZ\x1000 kernel I get about 2ms.
> > 
> > MPU401 is very bad hardware for transmit, because it doesn't use interrupt
> > to determine that Tx FIFO is free. Some vendors offers large FIFOs
> > (8,12,16 bytes), but unfortunately guys at Creative designed SB AWE with
> > 2 byte FIFO.
> 
> Hmm .. so you are saying that this is a HARDWARE limitiation ?
> How does Windoze manage this ?

Did you see W$ sources? I didn't.

> > This doesn't explain why your latencies are so big for OSS/Free, because
> > OSS/Free code uses polling mode (busy loop for transmit).
> 
> What is the main drawback of this ?
> What happens when I send a block of 3000 bytes to the midi device under
> OSS/Free ?
> A 100% CPU usage for 1sec ?
> I can't believe this.

Try it.

linux/drivers/sound/mpu401.c:

        /*
         * Sometimes it takes about 30000 loops before the output becomes ready
         * (After reset). Normally it takes just about 10 loops.
         */

        for (timeout = 30000; timeout > 0 && !output_ready(devc); timeout--);

> > ALSA uses system timer to avoid busy loop, but the performance depends on
> > your HZ value:
> > 
> > 100Hz, 2 byte FIFO = 200bytes/sec
> > 100Hz, 8 byte FIFO = 1600bytes/sec
> > 100Hz, 12 byte FIFO = 2400bytes/sec
> > 100Hz, 16 byte FIFO = 3200bytes/sec
> 
> 200bytes/sec is just rudiculous , how do you plan to drive an external synth
> with that little MIDI bandwidth ?

I need a timer around 2000Hz for some good code. I won't support polling
mode (busy loop) in any case.

> Many songs uses up much of the 3000 bytes/sec bandwidth, especially
> when there are many  controller/pitchbend events present.
> 
> Do you know if the RX FIFO of the MPU401 has the same problem (no interrupt) or
> is there an interrupt present ?

No, MPU401 has Rx interrupt.

> Does this mean that sequencers running under Windows have the same problems
> as we in Linux on the AWE64 ?

I don't know, how is this problem solved under W$.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

Re: Bad MIDI performance : 10ms latency instead of the expected 1-1.5ms

[Benno Senoner]

On Thu, 26 Aug 1999, Jaroslav Kysela wrote:
 
> > I wrote this to measure the MIDI output-to-input delay.
> > I tried both with blocking I/O and non-blocking I/O.
> > Unfortunately I get bad values in both modes:
> > about 11.5ms , and this is exactly the MIDI transfer time (1.3ms) plus
> > 10ms = 1 jiffie.
> > If I run the test on a HZ\x1000 kernel I get about 2ms.
> 
> MPU401 is very bad hardware for transmit, because it doesn't use interrupt
> to determine that Tx FIFO is free. Some vendors offers large FIFOs
> (8,12,16 bytes), but unfortunately guys at Creative designed SB AWE with
> 2 byte FIFO.

Hmm .. so you are saying that this is a HARDWARE limitiation ?
How does Windoze manage this ?

> 
> This doesn't explain why your latencies are so big for OSS/Free, because
> OSS/Free code uses polling mode (busy loop for transmit).

What is the main drawback of this ?
What happens when I send a block of 3000 bytes to the midi device under
OSS/Free ?
A 100% CPU usage for 1sec ?
I can't believe this.

> 
> ALSA uses system timer to avoid busy loop, but the performance depends on
> your HZ value:
> 
> 100Hz, 2 byte FIFO = 200bytes/sec
> 100Hz, 8 byte FIFO = 1600bytes/sec
> 100Hz, 12 byte FIFO = 2400bytes/sec
> 100Hz, 16 byte FIFO = 3200bytes/sec

200bytes/sec is just rudiculous , how do you plan to drive an external synth
with that little MIDI bandwidth ?
Many songs uses up much of the 3000 bytes/sec bandwidth, especially
when there are many  controller/pitchbend events present.

Do you know if the RX FIFO of the MPU401 has the same problem (no interrupt) or
is there an interrupt present ?

Is there no other way to make the MIDI response better, without increasing HZ
to 1000 ?

Does this mean that sequencers running under Windows have the same problems
as we in Linux on the AWE64 ?
Or does Windows a "sane" busywaiting all the time ?  :-)
With these big midi delays you can't simply use your PC to act as a midi-tru
box, playing an external synth via masterkeyboard connected to the midi-in.  

> 
> Not affected hardware:
> 
> 	GUS soundcards
> 	AudioPCI chips (ES1370/1371/1373)

If this is true, then I will throw away my AWE64 and buy an AudioPCI
:-)



regards,
Benno.

Re: Bad MIDI performance : 10ms latency instead of the expected

[Alan Cox]

> > 200bytes/sec is just rudiculous , how do you plan to drive an external synth
> > with that little MIDI bandwidth ?
> 
> I need a timer around 2000Hz for some good code. I won't support polling
> mode (busy loop) in any case.

Then your code will never be usable. Some hardware sucks, you have to do
limited polling with a timer backoff. A well tuned polling loop will often
work out nicely providing you are careful. Remember with irqs on you are
just like busy in userspace no worse. You can even do

	while(poll_input()=0)
	{
		if(current->need_resched())
			schedule();
	}

sort of stuff

Re: Bad MIDI performance : 10ms latency instead of the expected

[Alan Cox]

> > 		if(current->need_resched())
> > 			schedule();
> > 	}
> Do you think there are some benefits by inserting the re-schedule in the
> drivers/sound/mpu401.c file ? ( less CPU usage)
> 
> for (timeout = 30000; timeout > 0 && !output_ready(devc); timeout--);
> 
> But since the FIFO is only 2 bytes long = 600usecs, 
> the schedule() could cause a MIDI bandwidth decrease,
> but would keep CPU load down , right ?
> Why was the MPU401 code not tuned that way ?

Hannu tuned MPU401, Im not precisely sure how he tuned it, but it should
be sufficiently short the need_resched check isnt needed

Re: Bad MIDI performance : 10ms latency instead of the expected 1-1.5ms

[Benno Senoner]

On Thu, 26 Aug 1999, Jaroslav Kysela wrote:
>> > A 100% CPU usage for 1sec ?
> > I can't believe this.
> 
> Try it.
> 
> linux/drivers/sound/mpu401.c:
> 
>         /*
>          * Sometimes it takes about 30000 loops before the output becomes ready
>          * (After reset). Normally it takes just about 10 loops.
>          */
> 
>         for (timeout = 30000; timeout > 0 && !output_ready(devc); timeout--);

arrgh, really bad !

 > > 200bytes/sec is just rudiculous , how do you plan to drive an external synth
> > with that little MIDI bandwidth ?
> 
> I need a timer around 2000Hz for some good code. I won't support polling
> mode (busy loop) in any case.

Yes, is there some free timer available in Linux to perform this job ?
It would be nice to be able to use the full MIDI bandwidth without eating
all the CPU power.

> 
> > Many songs uses up much of the 3000 bytes/sec bandwidth, especially
> > when there are many  controller/pitchbend events present.
> > 
> > Do you know if the RX FIFO of the MPU401 has the same problem (no interrupt) or
> > is there an interrupt present ?
> 
> No, MPU401 has Rx interrupt.
Fortunately ! , this means you can still use your PC as a realtime synth/sampler
when played through a MIDI masterkeyboard

> 
> > Does this mean that sequencers running under Windows have the same problems
> > as we in Linux on the AWE64 ?
> 
> I don't know, how is this problem solved under W$.
> 
> 						Jaroslav
certainly in a sub-optimal way.
:-)

regards,
Benno.

Re: Bad MIDI performance : 10ms latency instead of the expected

[Jaroslav Kysela]

On Thu, 26 Aug 1999, Alan Cox wrote:

> > > 200bytes/sec is just rudiculous , how do you plan to drive an external synth
> > > with that little MIDI bandwidth ?
> > 
> > I need a timer around 2000Hz for some good code. I won't support polling
> > mode (busy loop) in any case.
> 
> Then your code will never be usable. Some hardware sucks, you have to do
> limited polling with a timer backoff. A well tuned polling loop will often
> work out nicely providing you are careful. Remember with irqs on you are
> just like busy in userspace no worse. You can even do
> 
> 	while(poll_input()=0)
> 	{
> 		if(current->need_resched())
> 			schedule();
> 	}
> 
> sort of stuff

Is possible to create some thread for this loop inside kernel module?
I don't want to suspend the application execution due to a broken
hardware. I did some tests with 2.2 kernels (using kernel_thread()) and
I've not been successful.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

Re: Bad MIDI performance : 10ms latency instead of the expected

[Alan Cox]

> Is possible to create some thread for this loop inside kernel module?

There is no point

> I don't want to suspend the application execution due to a broken
> hardware. I did some tests with 2.2 kernels (using kernel_thread()) and
> I've not been successful.

It is cheaper for the application thread to spin briefly in kernel space
than to schedule other threads.

Re: Bad MIDI performance : 10ms latency instead of the expected

[Benno Senoner]

On Thu, 26 Aug 1999, Alan Cox wrote:
> > > 200bytes/sec is just rudiculous , how do you plan to drive an external synth
> > > with that little MIDI bandwidth ?
> > 
> > I need a timer around 2000Hz for some good code. I won't support polling
> > mode (busy loop) in any case.
> 
> Then your code will never be usable. Some hardware sucks, you have to do
> limited polling with a timer backoff. A well tuned polling loop will often
> work out nicely providing you are careful. Remember with irqs on you are
> just like busy in userspace no worse. You can even do
> 
> 	while(poll_input()=0)
> 	{
> 		if(current->need_resched())
> 			schedule();
> 	}
> 
> sort of stuff

Do you think there are some benefits by inserting the re-schedule in the
drivers/sound/mpu401.c file ? ( less CPU usage)

for (timeout = 30000; timeout > 0 && !output_ready(devc); timeout--);

But since the FIFO is only 2 bytes long = 600usecs, 
the schedule() could cause a MIDI bandwidth decrease,
but would keep CPU load down , right ?
Why was the MPU401 code not tuned that way ?

regards,
Benno.

Re: Bad MIDI performance : 10ms latency instead of the expected 1-1.5ms

[Peter Enderborg]

[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]

Benno Senoner wrote:

> On Thu, 26 Aug 1999, Jaroslav Kysela wrote:
>
> > > I wrote this to measure the MIDI output-to-input delay.
> > > I tried both with blocking I/O and non-blocking I/O.
> > > Unfortunately I get bad values in both modes:
> > > about 11.5ms , and this is exactly the MIDI transfer time (1.3ms) plus
> > > 10ms = 1 jiffie.
> > > If I run the test on a HZ=1000 kernel I get about 2ms.
> >
> > MPU401 is very bad hardware for transmit, because it doesn't use interrupt
> > to determine that Tx FIFO is free. Some vendors offers large FIFOs
> > (8,12,16 bytes), but unfortunately guys at Creative designed SB AWE with
> > 2 byte FIFO.
>
> Hmm .. so you are saying that this is a HARDWARE limitiation ?
> How does Windoze manage this ?
>
> >
> > This doesn't explain why your latencies are so big for OSS/Free, because
> > OSS/Free code uses polling mode (busy loop for transmit).
>
> What is the main drawback of this ?
> What happens when I send a block of 3000 bytes to the midi device under
> OSS/Free ?
> A 100% CPU usage for 1sec ?
> I can't believe this.
>
> >
> > ALSA uses system timer to avoid busy loop, but the performance depends on
> > your HZ value:
> >
> > 100Hz, 2 byte FIFO = 200bytes/sec
> > 100Hz, 8 byte FIFO = 1600bytes/sec
> > 100Hz, 12 byte FIFO = 2400bytes/sec
> > 100Hz, 16 byte FIFO = 3200bytes/sec
>
> 200bytes/sec is just rudiculous , how do you plan to drive an external synth
> with that little MIDI bandwidth ?
> Many songs uses up much of the 3000 bytes/sec bandwidth, especially
> when there are many  controller/pitchbend events present.
>
> Do you know if the RX FIFO of the MPU401 has the same problem (no interrupt) or
> is there an interrupt present ?
>
> Is there no other way to make the MIDI response better, without increasing HZ
> to 1000 ?
>
> Does this mean that sequencers running under Windows have the same problems
> as we in Linux on the AWE64 ?
> Or does Windows a "sane" busywaiting all the time ?  :-)
> With these big midi delays you can't simply use your PC to act as a midi-tru
> box, playing an external synth via masterkeyboard connected to the midi-in.
>
> >
> > Not affected hardware:
> >
> >       GUS soundcards
> >       AudioPCI chips (ES1370/1371/1373)
>
> If this is true, then I will throw away my AWE64 and buy an AudioPCI
> :-)
>
> regards,
> Benno.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

Im the only one that have problems with perfomance while receiving midi data ?
It is droping a lot of events. Oss don't drop so mush, but alsa is useless. Is it
SMP problem ? Low irq responce times ? I have a SB PCI 128 and a hoontech
and have the same problem with both. (The hoontech is only avalible with alsa
driver)


--
foo!



[-- Attachment #2: Card for Peter Enderborg --]
[-- Type: text/x-vcard, Size: 153 bytes --]

begin:vcard 
n:Enderborg;Peter
x-mozilla-html:FALSE
org:;
adr:;;;;;;
version:2.1
email;internet:pme@ufh.se
x-mozilla-cpt:;0
fn:Peter Enderborg
end:vcard