19 Jun
2010
19 Jun
'10
12:24 p.m.
Ichthyostega wrote:
Ralf Mardorf schrieb:
It's said that USB MIDI interfaces should be the better choice. But this
explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ...
Subject: Re: [LAD] Again MIDI jitter - tested with Fons test applications
Date: Sat, 27 Mar 2010 18:26:33 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: fons(a)kokkinizita.net
CC: linux-audio-dev(a)lists.linuxaudio.org
References: <4BADBD42.4030505(a)alice-dsl.net> <20100327164326.GD1545@zita2>
Another stupid question induced by an argument
regarding to MIDI jitter by
Daniel James.
> [snip] I'm sceptical that the realtime kernel is the cause of your MIDI
> problems. If they got this right in the 80's, on computers which could not
> do anything near realtime audio processing, then I think it's more likely
> to be a question of MIDI application design.
At that point we should call back, how that whole story with "realtime"
started. At the begining was a design mismatch. Many things related to
the Linux kernel started out with a kind of "I feel fine" pragmatism.
Which, btw isn't to criticise as it is, because this also accounts
for the freshness and sometime unconventional new approach to some
problems. But with regards to timings, for all of the first decade
of Linux development, there seemed to be a completely different
mental model, which we could summarise as: permormance == throughput,
and timings are only relevant, when you get a network timeout, or
a sluggish response in your application's GUI.
Thus, if we now consider to use a Linux kernel for making music, we must
assess that the whole design isochronously assumed about 1000 times more
headroom as there really is.
Thus, as writing a new Kernel doesn't seem to be an option, this whole
tedious undertaking of the "realtime patches" can be described as an
attempt to fix this "problem" (which was never assumed to be a problem
in the initial design) by hunting down one by one each individual instance
where the existing kernel could possibly be reacting too slow.
Thus, we should rather be surprised, how good these realtime kernels work.
OTOH, is isn't a surprise the machines from the 80s meet these criteria;
their OS software was written with an awareness for a much more limited
processing capability right from start.
Why do people (not only me) report jitter for
external MIDI equipment, but I
couldn't find any report for real-time audio jitter? Resp. what's about async
and disconnecting clients by JACK?
Audio and MIDI are two quite different beasts.
Sound is processed in Blocks, where the individual unity (1 Sample) is
much more fine grained and way below anything which can be discerned by
a human ear. Moreover, Sound as such already exists and 'just' has to
be piped through. To the contrary, MIDI consists of events, which
immediately trigger a reaction, which could be that a piece of software
and at the same time a piece of external hardware starts a processing
cycle. You see, thats a completely different situation and thus it's
obvious, why for these two media the same problem causes so different
symptoms.
OTOH on Windows audio clients don't
disconnect,
just MIDI jitter is an issue too.
IIRC, this was a design decision for JACK. It never tries to conceal
any timeout problem, rather it requires its clients to keep up with
a very tight schedule and comply to very strict rules.
I don't know the MIDI part of Jack well enough to judge, if it was
designed with the same "you're required to comply" policy. And besides,
when the MIDI interface is hooked up via USB, we again face a completely
different situation. USB is a complicated protocol, which multiple
versions and levels and is certainly not designed to get an individual
event transfered reliably with less than 2ms jitter.
There is even the possibility that the USB peers negotiate to use a
lower transfer rate or protocol version transparently, when they
determine the connection can't keep up with the higher speed.
Cheers
Hermann V. Hi Fons :)
fons(a)kokkinizita.net wrote:
Subject: Again MIDI jitter - tested with Fons test applications
Date: Sat, 27 Mar 2010 09:09:38 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf
Mardorf wrote:
Aha, okay this is plausible.
Regular it shifted between 2395 and 2404, but
with a few exceptions,
one time 2302, three times 2304, two times 2305 and two time 2494.
See attachment.
What might cause this exceptions? Could it be access to the RAM by
the graphics? Is there something bad because of the IRQs?
Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal
shift 2494 - 2302 = 192 frames of jitter.
I guess this does mean ...
5.3 ms / 512 frames = 0.010351562 ms/frame
Maximal difference for regular jitter 0.093164062 ms.
Maximal difference for exceptional jitter 1.9875 ms.
... am I wrong?
Wrong once or twice, if twice in such a way that the two
errors cancel out.
First note that the test prints the difference between
events. That means that e.g. if *one* note is 100 samples
late you could see 2400 2500 2300 2400.
The '2300' is just because the previous one was late,
not because this one arrives too early. So you should
divide the jitter as you measure it by two.
Second, 5.33 ms = 256 frames at 48 kHz. But maybe
you
are using 96 kHz ??
So you didn't read the attachment ;), yes I did use 96 KHz.
[snip] When I once tested it by recording I got this result
for ALSA MIDI on
Linux, Cubase runs on Windows on the same machine:
||Cubase|HR tmr|System|PCM pl|PCM ca
------++------+------+------+------+------
500.0 || 493.0| 504.9| 505.6| 503.4| 503.2
1000.0|| 993.4|1005.4|1005.8|1005.3|1006.4
1500.0||1494.5|1503.6|1506.4|1507.4|1507.3
2000.0||1994.8|2003.8|2007.2|2007.9|2009.5
2500.0||2492.4|2504.1|2504.3|2503.6|2503.2
3000.0||2992.9|3006.0|3006.2|3005.9|3007.6
3500.0||3493.7|3502.7|3505.4|3506.5|3509.5
4000.0||3994.6|4003.1|4003.2|4008.8|4009.9
msec +/- 0.1 msec
maxDif|| 4.8| 6.0| 7.2| 8.8| 9.9
minDif|| -2.4| -2.7| -3.2| -3.4| -3.2
--------------+------+------+------+------
Jitter|| 2.4| 3.3| 4.0| 5.4| 6.7
msec +/- 0.2 msec
... as you can see, for Cubase I got this 2ms of jitter. So regarding to
your explanation Herman, Windows + ASIO + Cubase does a good job, just
the USB interface will limit it, while for Linux there seems to be
another issue too, but the USB interface. Btw. Linux HR tmr is a PITA,
just System, PCM pl and PCM ca are usable without issues for all Linux apps.
What could be the cause that Windows just is limited to the USB
interface by 2.4 ms, but Linux comes with 4.0 ms on my machine?
Joshua Boyd on LAD wrote:
On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene Heskett
wrote:
So, that leaves me wondering why no one seems to be trying RTAI for
audio work? Or is someone doing that and I'm just not aware?
Today I tried to do so.
I tried to run JACK2 with -R switch by user and by sudo, the result was
the same as here, when I launched JACK2 without -R switch on 64 Studio
3.0 beta based on Ubuntu Hardy:
$ uname -r
2.6.24-16-rtai
$ jackd -dalsa -dhw:0 -r96000 -p512 -n2
jackdmp 1.9.3
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in non-realtime mode
creating alsa driver ... hw:0|hw:0|512|2|96000|0|0|nomon|swmeter|-|32bit
control open "hw:0" (No such file or directory)
Cannot initialize driver
no message buffer overruns
JackServer::Open() failed with -1
Failed to start server
ALSA seq couldn't start too.
I run the EMC2 / HAL latency-test:
Servo thread (1.0 ms): max interval 999180 ns, max jitter 10949 ns, last
interval 992259 ns
Base thread (25.0 us): max interval 34551 ns, max jitter 9640 ns, last
interval 24887 ns
The same test couldn't be used for my kernel-rt:
$ uname -r
2.6.31.12-rt20
$ latency-test
insmod: can't read '/usr/realtime-2.6.31.12-rt20/modules/rtai_hal.ko':
No such file or directory
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
ERROR: Module hal_lib does not exist in /proc/modules
ERROR: Module rtapi does not exist in /proc/modules
ERROR: Module rtai_math does not exist in /proc/modules
ERROR: Module rtai_sem does not exist in /proc/modules
ERROR: Module rtai_fifos does not exist in /proc/modules
/usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched
[snip]
ERROR: Module rtai_hal does not exist in /proc/modules
Btw. should I commend out the EMC2 memlock when doing audio work again
or doesn't have it an impact?
$ cat /etc/security/limits.conf | grep memlock
# - memlock - max locked-in-memory address space (KB)
@audio - memlock unlimited
# @audio - memlock 2000000
* hard memlock 20480 #EMC2
Cheers!
Ralf
PS: What now? It's my second hardware set up. I just bought a new
computer a long time ago, because the old computer wasn't ok for Linux
too, but I don't have the money to pay for one machine after the other,
until I might have good luck. Both machines are 100% stable for Windows,
for Linux I also get asyncs + distortion when using JACK2. I didn't test
if current JACK1 is ok, or if it would disconnect clients. Don't get me
wrong, I never was a private Windows user, it just were installs for
testings. I'm using Linux only at home.
At my
school we transfered the CAD files per floppy to a DOS box that
controlled the CNC machine, guess that's for the same reason, bad rt
capabilities of newer OSes and machines.
The RTAI works pretty well, I can start a
job, switch away from that window,
and talk to the guys on IRC, or browse the web without hurting the job.
That to me is true multitasking. 
19 Jun
19 Jun
1:33 p.m.
New subject: [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote:
This will go back only to LAD as I'm not subbed to the others, Ralf.
Ichthyostega wrote:
On the face of it, and reading the USB specs, USB would seem to be a poor
choice for midi unless it re-clocks everything.before sending it out the
MIDI port. Usb has a 10 millisecond worst case lag in the specs.
Ralf Mardorf schrieb:
It's said that USB MIDI interfaces should be the better choice. But this
explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ... Another stupid question induced by an argument
regarding to MIDI jitter
by Daniel James.
> [snip] I'm sceptical that the realtime kernel is the cause of your
> MIDI problems. If they got this right in the 80's, on computers which
> could not do anything near realtime audio processing, then I think
> it's more likely to be a question of MIDI application design.
At that point we should call back, how that whole story with "realtime"
started. At the begining was a design mismatch. Many things related to
the Linux kernel started out with a kind of "I feel fine" pragmatism.
Which, btw isn't to criticise as it is, because this also accounts
for the freshness and sometime unconventional new approach to some
problems. But with regards to timings, for all of the first decade
of Linux development, there seemed to be a completely different
mental model, which we could summarise as: permormance == throughput,
and timings are only relevant, when you get a network timeout, or
a sluggish response in your application's GUI.
Thus, if we now consider to use a Linux kernel for making music, we must
assess that the whole design isochronously assumed about 1000 times more
headroom as there really is.
Thus, as writing a new Kernel doesn't seem to be an option, this whole
tedious undertaking of the "realtime patches" can be described as an
attempt to fix this "problem" (which was never assumed to be a problem
in the initial design) by hunting down one by one each individual
instance where the existing kernel could possibly be reacting too slow.
Thus, we should rather be surprised, how good these realtime kernels
work. OTOH, is isn't a surprise the machines from the 80s meet these
criteria; their OS software was written with an awareness for a much
more limited processing capability right from start.
Why do people (not only me) report jitter for
external MIDI equipment,
but I couldn't find any report for real-time audio jitter? Resp. what's
about async and disconnecting clients by JACK?
Audio and MIDI are two quite different beasts.
Sound is processed in Blocks, where the individual unity (1 Sample) is
much more fine grained and way below anything which can be discerned by
a human ear. Moreover, Sound as such already exists and 'just' has to
be piped through. To the contrary, MIDI consists of events, which
immediately trigger a reaction, which could be that a piece of software
and at the same time a piece of external hardware starts a processing
cycle. You see, thats a completely different situation and thus it's
obvious, why for these two media the same problem causes so different
symptoms.
OTOH on Windows audio clients don't
disconnect,
just MIDI jitter is an issue too.
IIRC, this was a design decision for JACK. It never tries to conceal
any timeout problem, rather it requires its clients to keep up with
a very tight schedule and comply to very strict rules.
I don't know the MIDI part of Jack well enough to judge, if it was
designed with the same "you're required to comply" policy. And besides,
when the MIDI interface is hooked up via USB, we again face a completely
different situation. USB is a complicated protocol, which multiple
versions and levels and is certainly not designed to get an individual
event transfered reliably with less than 2ms jitter.
There is even the possibility that the USB peers negotiate to use a
lower transfer rate or protocol version transparently, when they
determine the connection can't keep up with the higher speed.
Cheers
Hermann V.
Subject: Re: [LAD] Again MIDI jitter - tested with Fons test applications
Date: Sat, 27 Mar 2010 18:26:33 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: fons(a)kokkinizita.net
CC: linux-audio-dev(a)lists.linuxaudio.org
References: <4BADBD42.4030505(a)alice-dsl.net>
<20100327164326.GD1545@zita2>
Which could be an interaction with the rtai kernel.
Hi Fons :)
fons(a)kokkinizita.net wrote:
Subject: Again MIDI jitter - tested with Fons test applications
Date: Sat, 27 Mar 2010 09:09:38 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf
Mardorf wrote:
Aha, okay this is plausible.
Regular it shifted between 2395 and 2404, but
with a few exceptions,
one time 2302, three times 2304, two times 2305 and two time 2494.
See attachment.
What might cause this exceptions? Could it be access to the RAM by
the graphics? Is there something bad because of the IRQs?
Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal
shift 2494 - 2302 = 192 frames of jitter.
I guess this does mean ...
5.3 ms / 512 frames = 0.010351562 ms/frame
Maximal difference for regular jitter 0.093164062 ms.
Maximal difference for exceptional jitter 1.9875 ms.
... am I wrong?
Wrong once or twice, if twice in such a way that the two
errors cancel out.
First note that the test prints the difference between
events. That means that e.g. if *one* note is 100 samples
late you could see 2400 2500 2300 2400.
The '2300' is just because the previous one was late,
not because this one arrives too early. So you should
divide the jitter as you measure it by two. Second, 5.33 ms = 256 frames at 48 kHz. But maybe
you
are using 96 kHz ??
So you didn't read the attachment ;), yes I did use 96 KHz.
[snip] When I once tested it by recording I got this
result for ALSA MIDI on
Linux, Cubase runs on Windows on the same machine:
||Cubase|HR tmr|System|PCM pl|PCM ca
------++------+------+------+------+------
500.0 || 493.0| 504.9| 505.6| 503.4| 503.2
1000.0|| 993.4|1005.4|1005.8|1005.3|1006.4
1500.0||1494.5|1503.6|1506.4|1507.4|1507.3
2000.0||1994.8|2003.8|2007.2|2007.9|2009.5
2500.0||2492.4|2504.1|2504.3|2503.6|2503.2
3000.0||2992.9|3006.0|3006.2|3005.9|3007.6
3500.0||3493.7|3502.7|3505.4|3506.5|3509.5
4000.0||3994.6|4003.1|4003.2|4008.8|4009.9
msec +/- 0.1 msec
maxDif|| 4.8| 6.0| 7.2| 8.8| 9.9
minDif|| -2.4| -2.7| -3.2| -3.4| -3.2
--------------+------+------+------+------
Jitter|| 2.4| 3.3| 4.0| 5.4| 6.7
msec +/- 0.2 msec
... as you can see, for Cubase I got this 2ms of jitter. So regarding to
your explanation Herman, Windows + ASIO + Cubase does a good job, just
the USB interface will limit it, while for Linux there seems to be
another issue too, but the USB interface. Btw. Linux HR tmr is a PITA,
just System, PCM pl and PCM ca are usable without issues for all Linux
apps.
What could be the cause that Windows just is limited to the USB
interface by 2.4 ms, but Linux comes with 4.0 ms on my machine?
Joshua Boyd on LAD wrote:
On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene
Heskett wrote:
So, that leaves me wondering why no one seems to be trying RTAI for
audio work? Or is someone doing that and I'm just not aware?
Today I tried to do so.
I tried to run JACK2 with -R switch by user and by sudo, the result was
the same as here, when I launched JACK2 without -R switch on 64 Studio
3.0 beta based on Ubuntu Hardy:
$ uname -r
2.6.24-16-rtai
$ jackd -dalsa -dhw:0 -r96000 -p512 -n2
jackdmp 1.9.3
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in non-realtime mode
creating alsa driver ... hw:0|hw:0|512|2|96000|0|0|nomon|swmeter|-|32bit
control open "hw:0" (No such file or directory)
Cannot initialize driver
no message buffer overruns
JackServer::Open() failed with -1
Failed to start server
ALSA seq couldn't start too. At my
school we transfered the CAD files per floppy to a DOS box that
controlled the CNC machine, guess that's for the same reason, bad rt
capabilities of newer OSes and machines.
The RTAI works pretty well, I can start a job, switch away from that
window, and talk to the guys on IRC, or browse the web without hurting
the job. That to me is true multitasking. I run the EMC2 / HAL latency-test:
Servo thread (1.0 ms): max interval 999180 ns, max jitter 10949 ns, last
interval 992259 ns
Base thread (25.0 us): max interval 34551 ns, max jitter 9640 ns, last
interval 24887 ns
The same test couldn't be used for my kernel-rt:
$ uname -r
2.6.31.12-rt20
$ latency-test
The -rt20 kernel bears little or no resemblance to the rtai version, and
latency-test will not run without its features.
insmod: can't read
'/usr/realtime-2.6.31.12-rt20/modules/rtai_hal.ko':
No such file or directory
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
ERROR: Module hal_lib does not exist in /proc/modules
ERROR: Module rtapi does not exist in /proc/modules
ERROR: Module rtai_math does not exist in /proc/modules
ERROR: Module rtai_sem does not exist in /proc/modules
ERROR: Module rtai_fifos does not exist in /proc/modules
/usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched
[snip]
ERROR: Module rtai_hal does not exist in /proc/modules
Btw. should I commend out the EMC2 memlock when doing audio work again
or doesn't have it an impact?
$ cat /etc/security/limits.conf | grep memlock
# - memlock - max locked-in-memory address space (KB)
@audio - memlock unlimited
# @audio - memlock 2000000
* hard memlock 20480 #EMC2
At only 20k, I doubt it makes much difference, but test anyway.
Cheers!
Ralf
PS: What now? It's my second hardware set up. I just bought a new
computer a long time ago, because the old computer wasn't ok for Linux
too, but I don't have the money to pay for one machine after the other,
until I might have good luck. Both machines are 100% stable for Windows,
for Linux I also get asyncs + distortion when using JACK2. I didn't test
if current JACK1 is ok, or if it would disconnect clients. Don't get me
wrong, I never was a private Windows user, it just were installs for
testings. I'm using Linux only at home.
Being an ardent purist can bite you. As another friend of mine would say,
use what works.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
A program generator creates programs that are more buggy than the program
generator
-- Murphy's Laws of Computation n�3
2:16 p.m.
New subject: [64studio-users] MIDI jitter
Hi Gene :)
Gene Heskett wrote:
Of course, the rtai seems not to be made for audio.
If it's just that 20k are reserved and that here aren't any other
technically issues involved, that shouldn't be a problem. When I used
the on-board graphics I missed 256 MB and it didn't made a difference,
when making music. OTOH I don't have a CNC machine and could remove the
package, but it would be fine to keep it, if I cross a CNC's path, even
if I guess the CNC machines I saw, were not in the supported list. As I
said, they do use pic micro controllers.
No Windows! If needed I'll write to your friend and get that Atari-VGA
interface, get a SMPTE interface again and an anlog audio recorder
again. I also would change the SCSI hard disk in the Lacom interface,
it's a 42 MB Seagate, without any free space and it sometimes fails on
startup. The main problem is, that I don't have the money jet and it's
not that easy to get the money. Another issue is, that I guess it's time
to use modern software, because it also comes with some advantages
compared to 80ies software made for the Atari and to the very old
hardware. E.g. what would happen if one day a chip in the Steinberg
dongle should break?
Cheers!
Ralf
On Saturday 19 June 2010, Ralf Mardorf wrote:
This will go back only to LAD as I'm not subbed to the others, Ralf.
To bad that there isn't a MPU game port any more on modern boards and
that e.g. my Terratec EWX 24/96 Envy24's MPU needs opto-couplers for the
cable, but what ever circuit I build on a brad board, they failed.
Time to mount my old mobo again and to test the game ports MPU with
today Linux, resp. to get a service manual for my Terratec.
Ichthyostega wrote:
On the face of it, and reading the USB specs, USB would seem to be a poor
choice for midi unless it re-clocks everything.before sending it out the
MIDI port. Usb has a 10 millisecond worst case lag in the specs.
Ralf Mardorf schrieb:
It's said that USB MIDI interfaces should be the better choice. But
this
explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ...
Another stupid question induced by an argument
regarding to MIDI jitter
by Daniel James.
> [snip] I'm sceptical that the realtime kernel is the cause of your
> MIDI problems. If they got this right in the 80's, on computers which
> could not do anything near realtime audio processing, then I think
> it's more likely to be a question of MIDI application design.
>
At that point we should call back, how that whole story with
"realtime"
started. At the begining was a design mismatch. Many things related to
the Linux kernel started out with a kind of "I feel fine" pragmatism.
Which, btw isn't to criticise as it is, because this also accounts
for the freshness and sometime unconventional new approach to some
problems. But with regards to timings, for all of the first decade
of Linux development, there seemed to be a completely different
mental model, which we could summarise as: permormance == throughput,
and timings are only relevant, when you get a network timeout, or
a sluggish response in your application's GUI.
Thus, if we now consider to use a Linux kernel for making music, we must
assess that the whole design isochronously assumed about 1000 times more
headroom as there really is.
Thus, as writing a new Kernel doesn't seem to be an option, this whole
tedious undertaking of the "realtime patches" can be described as an
attempt to fix this "problem" (which was never assumed to be a problem
in the initial design) by hunting down one by one each individual
instance where the existing kernel could possibly be reacting too slow.
Thus, we should rather be surprised, how good these realtime kernels
work. OTOH, is isn't a surprise the machines from the 80s meet these
criteria; their OS software was written with an awareness for a much
more limited processing capability right from start.
Why do people (not only me) report jitter for
external MIDI equipment,
but I couldn't find any report for real-time audio jitter? Resp. what's
about async and disconnecting clients by JACK?
Audio and MIDI are two quite different beasts.
Sound is processed in Blocks, where the individual unity (1 Sample) is
much more fine grained and way below anything which can be discerned by
a human ear. Moreover, Sound as such already exists and 'just' has to
be piped through. To the contrary, MIDI consists of events, which
immediately trigger a reaction, which could be that a piece of software
and at the same time a piece of external hardware starts a processing
cycle. You see, thats a completely different situation and thus it's
obvious, why for these two media the same problem causes so different
symptoms.
OTOH on Windows audio clients don't
disconnect,
just MIDI jitter is an issue too.
IIRC, this was a design decision for JACK. It never tries to conceal
any timeout problem, rather it requires its clients to keep up with
a very tight schedule and comply to very strict rules.
I don't know the MIDI part of Jack well enough to judge, if it was
designed with the same "you're required to comply" policy. And besides,
when the MIDI interface is hooked up via USB, we again face a completely
different situation. USB is a complicated protocol, which multiple
versions and levels and is certainly not designed to get an individual
event transfered reliably with less than 2ms jitter.
There is even the possibility that the USB peers negotiate to use a
lower transfer rate or protocol version transparently, when they
determine the connection can't keep up with the higher speed.
Cheers
Hermann V.
Subject: Re:
[LAD] Again MIDI jitter - tested with Fons test applications
Date: Sat, 27 Mar 2010 18:26:33 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: fons(a)kokkinizita.net
CC: linux-audio-dev(a)lists.linuxaudio.org
References: <4BADBD42.4030505(a)alice-dsl.net>
<20100327164326.GD1545@zita2>
Which could be an interaction with the rtai kernel.
Hi Fons :)
fons(a)kokkinizita.net wrote:
Subject: Again MIDI jitter - tested with Fons test applications
Date: Sat, 27 Mar 2010 09:09:38 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf
Mardorf wrote:
> Regular it shifted between 2395 and 2404, but with a few exceptions,
> one time 2302, three times 2304, two times 2305 and two time 2494.
> See attachment.
> What might cause this exceptions? Could it be access to the RAM by
> the graphics? Is there something bad because of the IRQs?
>
> Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal
> shift 2494 - 2302 = 192 frames of jitter.
>
> I guess this does mean ...
> 5.3 ms / 512 frames = 0.010351562 ms/frame
> Maximal difference for regular jitter 0.093164062 ms.
> Maximal difference for exceptional jitter 1.9875 ms.
> ... am I wrong?
>
Wrong once or twice, if twice in such a way that the two
errors cancel out.
First note that the test prints the difference between
events. That means that e.g. if *one* note is 100 samples
late you could see 2400 2500 2300 2400.
The '2300' is just because the previous one was late,
not because this one arrives too early. So you should
divide the jitter as you measure it by two.
Aha, okay this is plausible.
Second, 5.33 ms = 256 frames at 48 kHz. But maybe
you
are using 96 kHz ??
So you didn't read the attachment ;), yes I did use 96 KHz.
[snip]
When I once tested it by recording I got this
result for ALSA MIDI on
Linux, Cubase runs on Windows on the same machine:
||Cubase|HR tmr|System|PCM pl|PCM ca
------++------+------+------+------+------
500.0 || 493.0| 504.9| 505.6| 503.4| 503.2
1000.0|| 993.4|1005.4|1005.8|1005.3|1006.4
1500.0||1494.5|1503.6|1506.4|1507.4|1507.3
2000.0||1994.8|2003.8|2007.2|2007.9|2009.5
2500.0||2492.4|2504.1|2504.3|2503.6|2503.2
3000.0||2992.9|3006.0|3006.2|3005.9|3007.6
3500.0||3493.7|3502.7|3505.4|3506.5|3509.5
4000.0||3994.6|4003.1|4003.2|4008.8|4009.9
msec +/- 0.1 msec
maxDif|| 4.8| 6.0| 7.2| 8.8| 9.9
minDif|| -2.4| -2.7| -3.2| -3.4| -3.2
--------------+------+------+------+------
Jitter|| 2.4| 3.3| 4.0| 5.4| 6.7
msec +/- 0.2 msec
... as you can see, for Cubase I got this 2ms of jitter. So regarding to
your explanation Herman, Windows + ASIO + Cubase does a good job, just
the USB interface will limit it, while for Linux there seems to be
another issue too, but the USB interface. Btw. Linux HR tmr is a PITA,
just System, PCM pl and PCM ca are usable without issues for all Linux
apps.
What could be the cause that Windows just is limited to the USB
interface by 2.4 ms, but Linux comes with 4.0 ms on my machine?
Joshua Boyd on LAD wrote:
On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene
Heskett wrote:
Today I tried to do so.
I tried to run JACK2 with -R switch by user and by sudo, the result was
the same as here, when I launched JACK2 without -R switch on 64 Studio
3.0 beta based on Ubuntu Hardy:
$ uname -r
2.6.24-16-rtai
$ jackd -dalsa -dhw:0 -r96000 -p512 -n2
jackdmp 1.9.3
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in non-realtime mode
creating alsa driver ... hw:0|hw:0|512|2|96000|0|0|nomon|swmeter|-|32bit
control open "hw:0" (No such file or directory)
Cannot initialize driver
no message buffer overruns
JackServer::Open() failed with -1
Failed to start server
ALSA seq couldn't start too.
> At my school we transfered the CAD files per
floppy to a DOS box that
> controlled the CNC machine, guess that's for the same reason, bad rt
> capabilities of newer OSes and machines.
>
The RTAI works pretty well, I can start a job, switch away from that
window, and talk to the guys on IRC, or browse the web without hurting
the job. That to me is true multitasking.
So, that leaves me wondering why no one seems to be trying RTAI for
audio work? Or is someone doing that and I'm just not aware?
I run the EMC2
/ HAL latency-test:
Servo thread (1.0 ms): max interval 999180 ns, max jitter 10949 ns, last
interval 992259 ns
Base thread (25.0 us): max interval 34551 ns, max jitter 9640 ns, last
interval 24887 ns
The same test couldn't be used for my kernel-rt:
$ uname -r
2.6.31.12-rt20
$ latency-test
The -rt20 kernel bears little or no resemblance to the rtai version, and
latency-test will not run without its features.
insmod: can't read
'/usr/realtime-2.6.31.12-rt20/modules/rtai_hal.ko':
No such file or directory
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
ERROR: Module hal_lib does not exist in /proc/modules
ERROR: Module rtapi does not exist in /proc/modules
ERROR: Module rtai_math does not exist in /proc/modules
ERROR: Module rtai_sem does not exist in /proc/modules
ERROR: Module rtai_fifos does not exist in /proc/modules
/usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched
[snip]
ERROR: Module rtai_hal does not exist in /proc/modules
Btw. should I commend out the EMC2 memlock when doing audio work again
or doesn't have it an impact?
$ cat /etc/security/limits.conf | grep memlock
# - memlock - max locked-in-memory address space (KB)
@audio - memlock unlimited
# @audio - memlock 2000000
* hard memlock 20480 #EMC2
At only 20k, I doubt it makes much difference, but test anyway.
Cheers!
Ralf
PS: What now? It's my second hardware set up. I just bought a new
computer a long time ago, because the old computer wasn't ok for Linux
too, but I don't have the money to pay for one machine after the other,
until I might have good luck. Both machines are 100% stable for Windows,
for Linux I also get asyncs + distortion when using JACK2. I didn't test
if current JACK1 is ok, or if it would disconnect clients. Don't get me
wrong, I never was a private Windows user, it just were installs for
testings. I'm using Linux only at home.
Being an ardent purist can bite you. As another friend of mine would say,
use what works.
2:56 p.m.
New subject: [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote:
It has been my experience that such dongles have a lifetime of about a year.
Or less.
Story time: Years ago, we setup a graphics system that involved using the
A&B Roll Editing (or something like that name) amiga software to control 2
editing S-VHS vcr's, Panasonic 7750's. That came with a parport dongle,
without which it would not work. And it was a $25,000 package.
They, after lots of argument, and receiving the old dongle, would replace it
when it failed. eventually that program was sold to RVS, Ring Video
Systems, some fly by night down in FL.
The dongle failed again (there was no printer attached to its output port
ever) and they screwed around for 6 months, finally going to the original
authors house to get the last dongle in existence after we threatened to
sue. It lasted about 3 months. By then the hacking business was running
full tilt in the amiga world, so when they said no more dongle, we said
we're gonna hack it, sue us if you dare. We sent it off to one of the
hackers, and had a working system back on-line in 3 days. RVS in turn had
one of their programmers try to take it out, and 3 copies later over about 2
weeks, they failed. And we laughed at them on the phone when the last one
they sent didn't work.
To this day, I believe we only have one dongle protected system at the
station & that was because they said there wasn't one, but there was. We
simply do not consider for purchase, any system that uses a dongle for copy
protection. And we are not exactly silent when we tell some vendor, sorry,
you use a trouble prone technology so we will not even consider your
product/equipment. When we are writing checks for $100k and up for the new
digital stuff, we are justifiably being picky. If the vendor doesn't like
it, the exit door is that way, come back when you can offer us something
that Just Works(TM). Its been remarkably effective at separating out the
rectums in the business.
Hi Gene :)
[huge snip]
Being an
ardent purist can bite you. As another friend of mine would
say, use what works.
No Windows! If needed I'll write to your friend and get that Atari-VGA
interface, get a SMPTE interface again and an anlog audio recorder
again. I also would change the SCSI hard disk in the Lacom interface,
it's a 42 MB Seagate, without any free space and it sometimes fails on
startup. The main problem is, that I don't have the money jet and it's
not that easy to get the money. Another issue is, that I guess it's time
to use modern software, because it also comes with some advantages
compared to 80ies software made for the Atari and to the very old
hardware. E.g. what would happen if one day a chip in the Steinberg
dongle should break? Cheers!
Ralf
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Undetectable errors are infinite in variety, in contrast to detectable
errors, which by definition are limited
-- SNAFU Equations (JB's Scholastic Laws) n�3
3:35 p.m.
New subject: [64studio-users] MIDI jitter
Gene Heskett wrote:
On Saturday 19 June 2010, Ralf Mardorf wrote:
It has been my experience that such dongles have a lifetime of about a year.
Or less.
Story time: Years ago, we setup a graphics system that involved using the
A&B Roll Editing (or something like that name) amiga software to control 2
editing S-VHS vcr's, Panasonic 7750's. That came with a parport dongle,
without which it would not work. And it was a $25,000 package.
They, after lots of argument, and receiving the old dongle, would replace it
when it failed. eventually that program was sold to RVS, Ring Video
Systems, some fly by night down in FL.
The dongle failed again (there was no printer attached to its output port
ever) and they screwed around for 6 months, finally going to the original
authors house to get the last dongle in existence after we threatened to
sue. It lasted about 3 months. By then the hacking business was running
full tilt in the amiga world, so when they said no more dongle, we said
we're gonna hack it, sue us if you dare. We sent it off to one of the
hackers, and had a working system back on-line in 3 days. RVS in turn had
one of their programmers try to take it out, and 3 copies later over about 2
weeks, they failed. And we laughed at them on the phone when the last one
they sent didn't work.
To this day, I believe we only have one dongle protected system at the
station & that was because they said there wasn't one, but there was. We
simply do not consider for purchase, any system that uses a dongle for copy
protection. And we are not exactly silent when we tell some vendor, sorry,
you use a trouble prone technology so we will not even consider your
product/equipment. When we are writing checks for $100k and up for the new
digital stuff, we are justifiably being picky. If the vendor doesn't like
it, the exit door is that way, come back when you can offer us something
that Just Works(TM). Its been remarkably effective at separating out the
rectums in the business.
> Cheers!
>
> Ralf
>
The Steinberg dongle seems to be ok, since it's from the 80ies or
beginning 90ies and was used for several years without getting broken.
But exactly because it's that old I fear it could break one day.
I 'guess' that I also could get cracked versions of Cubase for the
Atari, but while the dongle version is 100% stable and the latest
version ever made for the Atari, there aren't cracks for the latest
version and the cracks I know were '99%' stable.
For Windows there are dongle hacks available by torrent, they do work
'99,9999999999999%' ok and can be used with cracks, 'I heard'. Dunno if
they would work with bought software too, this might be interesting for
people who bought the original and wish to use it on wine.
I 'guess' I could get all I need for Windows as a crack, but I don't
like cracks and I can't pay for legal versions and I don't wish to have
USB dongles. Btw. I don't like the 'philosophy' of Microsoft.
While bus dongles using oldish gate chips, are less damageable, I don't
trust USB micro controllers.
When I was young I tuned my motorbikes and cracked software and used
software other people cracked. Juvenile law isn't valid for me today,
just one reason not to use cracks.
While open sources might not be important to everybody, people also
might not care about malign US major corporation, at least keeping our
own slates clean is a reason to get Linux more capable for music too.
2 cents,
Ralf
Hi Gene :)
[huge snip]
Being an
ardent purist can bite you. As another friend of mine would
say, use what works.
No Windows! If needed I'll write to your friend and get that Atari-VGA
interface, get a SMPTE interface again and an anlog audio recorder
again. I also would change the SCSI hard disk in the Lacom interface,
it's a 42 MB Seagate, without any free space and it sometimes fails on
startup. The main problem is, that I don't have the money jet and it's
not that easy to get the money. Another issue is, that I guess it's time
to use modern software, because it also comes with some advantages
compared to 80ies software made for the Atari and to the very old
hardware. E.g. what would happen if one day a chip in the Steinberg
dongle should break?
3:58 p.m.
New subject: [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote:
Gene Heskett wrote:
[...]
The Steinberg dongle seems to be ok, since it's
from the 80ies or
beginning 90ies and was used for several years without getting broken.
But exactly because it's that old I fear it could break one day.
I 'guess' that I also could get cracked versions of Cubase for the
Atari, but while the dongle version is 100% stable and the latest
version ever made for the Atari, there aren't cracks for the latest
version and the cracks I know were '99%' stable.
Since most of those dongles back then were themselves protected by grinding
the part numbers off the chip, that damage to the expoxy-B covering is
probably largely responsible for their short life, both from the instant
heating caused by the grinding, but also from moisture migrating into the
assembly through the damaged epoxy-B coating.
For Windows there are dongle hacks available by
torrent, they do work
'99,9999999999999%' ok and can be used with cracks, 'I heard'. Dunno if
they would work with bought software too, this might be interesting for
people who bought the original and wish to use it on wine.
I 'guess' I could get all I need for Windows as a crack, but I don't
like cracks and I can't pay for legal versions and I don't wish to have
USB dongles. Btw. I don't like the 'philosophy' of Microsoft.
While bus dongles using oldish gate chips, are less damageable, I don't
trust USB micro controllers.
When I was young I tuned my motorbikes and cracked
software and used
software other people cracked. Juvenile law isn't valid for me today,
just one reason not to use cracks.
And when I was a juvenile, transistors had not been invented yet. ;-)
While open sources might not be important to everybody,
people also
might not care about malign US major corporation, at least keeping our
own slates clean is a reason to get Linux more capable for music too.
Naw, I'm not the least bit allergic to tweaking the M$ nose. :) Their
little 'easter eggs' that cause the loss of an important file that can only
be replaced by purchasing a new copy of the os, in this case NT-4.0, have
bit me enough times that I have no respect for M$ for about 20 years now.
My limited experience with XP showed that it did work, but never felt like a
true os to me, just patches to DOS. Their most stable was 95, it ran for 46
days at a time, till the tick counter rolled over. Reboot on day 45 and
everything was cool. I would have to assume that DOS-6.22 also suffered
from that, we had one of those that crashed about every month & a half but
never had the clues to point a finger at that. Just one of those things...
2 cents,
Mine too. But I'd imagine the list people are about to police us, this is
sort of off topic. ;(
Ralf
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Q: How do you fix all Windows bugs at once?
A: Type DELTREE C:\WINDOWS
3:38 p.m.
New subject: [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote:
Hi Gene :)
Gene Heskett wrote:
Of course, the rtai seems not to be made for audio.
If it's just that 20k are reserved and that here aren't any other
technically issues involved, that shouldn't be a problem. When I used
the on-board graphics I missed 256 MB and it didn't made a difference,
when making music. OTOH I don't have a CNC machine and could remove the
package, but it would be fine to keep it, if I cross a CNC's path, even
if I guess the CNC machines I saw, were not in the supported list. As I
said, they do use pic micro controllers.
No Windows! If needed I'll write to your friend and get that Atari-VGA
interface, get a SMPTE interface again and an anlog audio recorder
again. I also would change the SCSI hard disk in the Lacom interface,
it's a 42 MB Seagate, without any free space and it sometimes fails on
startup. The main problem is, that I don't have the money jet and it's
not that easy to get the money. Another issue is, that I guess it's time
to use modern software, because it also comes with some advantages
compared to 80ies software made for the Atari and to the very old
hardware. E.g. what would happen if one day a chip in the Steinberg
dongle should break?
I don't even know if my atari setup, still in the boxes, has one of those.
It does have about 75 pounds of docs for musical related things with it
though. Too bad there is a rather big pond between us as I wouldn't mind
carrying it back up the stairs & helping someone load his car up if I could
get my $50 back.
On Saturday 19 June 2010, Ralf Mardorf wrote:
This will go back only to LAD as I'm not subbed to the others, Ralf.
To bad that there isn't a MPU game port any more on modern boards and
that e.g. my Terratec EWX 24/96 Envy24's MPU needs opto-couplers for the
cable, but what ever circuit I build on a brad board, they failed.
Time to mount my old mobo again and to test the game ports MPU with
today Linux, resp. to get a service manual for my Terratec.
Ichthyostega wrote:
On the face of it, and reading the USB specs, USB would seem to be a
poor choice for midi unless it re-clocks everything.before sending it
out the MIDI port. Usb has a 10 millisecond worst case lag in the
specs. Ralf Mardorf schrieb:
> Another stupid question induced by an argument regarding to MIDI
> jitter by Daniel James.
>
>> [snip] I'm sceptical that the realtime kernel is the cause of your
>> MIDI problems. If they got this right in the 80's, on computers
>> which could not do anything near realtime audio processing, then I
>> think it's more likely to be a question of MIDI application design.
At that point we should call back, how that whole story with
"realtime" started. At the begining was a design mismatch. Many things
related to the Linux kernel started out with a kind of "I feel fine"
pragmatism. Which, btw isn't to criticise as it is, because this also
accounts for the freshness and sometime unconventional new approach to
some problems. But with regards to timings, for all of the first
decade of Linux development, there seemed to be a completely different
mental model, which we could summarise as: permormance == throughput,
and timings are only relevant, when you get a network timeout, or a
sluggish response in your application's GUI.
Thus, if we now consider to use a Linux kernel for making music, we
must assess that the whole design isochronously assumed about 1000
times more headroom as there really is.
Thus, as writing a new Kernel doesn't seem to be an option, this whole
tedious undertaking of the "realtime patches" can be described as an
attempt to fix this "problem" (which was never assumed to be a problem
in the initial design) by hunting down one by one each individual
instance where the existing kernel could possibly be reacting too
slow.
Thus, we should rather be surprised, how good these realtime kernels
work. OTOH, is isn't a surprise the machines from the 80s meet these
criteria; their OS software was written with an awareness for a much
more limited processing capability right from start.
> Why do people (not only me) report jitter for external MIDI
> equipment, but I couldn't find any report for real-time audio jitter?
> Resp. what's about async and disconnecting clients by JACK?
Audio and MIDI are two quite different beasts.
Sound is processed in Blocks, where the individual unity (1 Sample) is
much more fine grained and way below anything which can be discerned
by a human ear. Moreover, Sound as such already exists and 'just' has
to be piped through. To the contrary, MIDI consists of events, which
immediately trigger a reaction, which could be that a piece of
software and at the same time a piece of external hardware starts a
processing cycle. You see, thats a completely different situation and
thus it's obvious, why for these two media the same problem causes so
different symptoms.
> OTOH on Windows audio clients don't disconnect,
> just MIDI jitter is an issue too.
IIRC, this was a design decision for JACK. It never tries to conceal
any timeout problem, rather it requires its clients to keep up with
a very tight schedule and comply to very strict rules.
I don't know the MIDI part of Jack well enough to judge, if it was
designed with the same "you're required to comply" policy. And
besides, when the MIDI interface is hooked up via USB, we again face a
completely different situation. USB is a complicated protocol, which
multiple versions and levels and is certainly not designed to get an
individual event transfered reliably with less than 2ms jitter.
There is even the possibility that the USB peers negotiate to use a
lower transfer rate or protocol version transparently, when they
determine the connection can't keep up with the higher speed.
Cheers
Hermann V.
It's said that USB MIDI interfaces should be the better choice. But
this explains a lot. Dunno how to read Fons JACK MIDI jitter test, but
... Subject:
Re: [LAD] Again MIDI jitter - tested with Fons test
applications Date: Sat, 27 Mar 2010 18:26:33 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: fons(a)kokkinizita.net
CC: linux-audio-dev(a)lists.linuxaudio.org
References: <4BADBD42.4030505(a)alice-dsl.net>
<20100327164326.GD1545@zita2>
Which could be an interaction with the rtai kernel. Hi Fons :)
fons(a)kokkinizita.net wrote:
> On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf Mardorf wrote:
>> Regular it shifted between 2395 and 2404, but with a few exceptions,
>> one time 2302, three times 2304, two times 2305 and two time 2494.
>> See attachment.
>> What might cause this exceptions? Could it be access to the RAM by
>> the graphics? Is there something bad because of the IRQs?
>>
>> Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal
>> shift 2494 - 2302 = 192 frames of jitter.
>>
>> I guess this does mean ...
>> 5.3 ms / 512 frames = 0.010351562 ms/frame
>> Maximal difference for regular jitter 0.093164062 ms.
>> Maximal difference for exceptional jitter 1.9875 ms.
>> ... am I wrong?
>
> Wrong once or twice, if twice in such a way that the two
> errors cancel out.
>
> First note that the test prints the difference between
> events. That means that e.g. if *one* note is 100 samples
> late you could see 2400 2500 2300 2400.
>
> The '2300' is just because the previous one was late,
> not because this one arrives too early. So you should
> divide the jitter as you measure it by two.
Aha, okay this is plausible.
> Second, 5.33 ms = 256 frames at 48 kHz. But maybe you
> are using 96 kHz ??
So you didn't read the attachment ;), yes I did use 96 KHz.
[snip]
Subject: Again MIDI jitter - tested with Fons test applications
Date: Sat, 27 Mar 2010 09:09:38 +0100
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
When I once tested it by recording I got this
result for ALSA MIDI on
Linux, Cubase runs on Windows on the same machine:
||Cubase|HR tmr|System|PCM pl|PCM ca
------++------+------+------+------+------
500.0 || 493.0| 504.9| 505.6| 503.4| 503.2
1000.0|| 993.4|1005.4|1005.8|1005.3|1006.4
1500.0||1494.5|1503.6|1506.4|1507.4|1507.3
2000.0||1994.8|2003.8|2007.2|2007.9|2009.5
2500.0||2492.4|2504.1|2504.3|2503.6|2503.2
3000.0||2992.9|3006.0|3006.2|3005.9|3007.6
3500.0||3493.7|3502.7|3505.4|3506.5|3509.5
4000.0||3994.6|4003.1|4003.2|4008.8|4009.9
msec +/- 0.1 msec
maxDif|| 4.8| 6.0| 7.2| 8.8| 9.9
minDif|| -2.4| -2.7| -3.2| -3.4| -3.2
--------------+------+------+------+------
Jitter|| 2.4| 3.3| 4.0| 5.4| 6.7
msec +/- 0.2 msec
... as you can see, for Cubase I got this 2ms of jitter. So regarding
to your explanation Herman, Windows + ASIO + Cubase does a good job,
just the USB interface will limit it, while for Linux there seems to be
another issue too, but the USB interface. Btw. Linux HR tmr is a PITA,
just System, PCM pl and PCM ca are usable without issues for all Linux
apps.
What could be the cause that Windows just is limited to the USB
interface by 2.4 ms, but Linux comes with 4.0 ms on my machine?
Joshua Boyd on LAD wrote:
On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene
Heskett wrote:
>> At my school we transfered the CAD files per floppy to a DOS box
>> that controlled the CNC machine, guess that's for the same reason,
>> bad rt capabilities of newer OSes and machines.
>
> The RTAI works pretty well, I can start a job, switch away from that
> window, and talk to the guys on IRC, or browse the web without
> hurting the job. That to me is true multitasking.
So, that leaves me wondering why no one seems to be trying RTAI for
audio work? Or is someone doing that and I'm just not aware?
Today I tried to do so.
I tried to run JACK2 with -R switch by user and by sudo, the result was
the same as here, when I launched JACK2 without -R switch on 64 Studio
3.0 beta based on Ubuntu Hardy:
$ uname -r
2.6.24-16-rtai
$ jackd -dalsa -dhw:0 -r96000 -p512 -n2
jackdmp 1.9.3
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in non-realtime mode
creating alsa driver ...
hw:0|hw:0|512|2|96000|0|0|nomon|swmeter|-|32bit control open "hw:0" (No
such file or directory)
Cannot initialize driver
no message buffer overruns
JackServer::Open() failed with -1
Failed to start server
ALSA seq couldn't start too. I run the
EMC2 / HAL latency-test:
Servo thread (1.0 ms): max interval 999180 ns, max jitter 10949 ns,
last interval 992259 ns
Base thread (25.0 us): max interval 34551 ns, max jitter 9640 ns,
last interval 24887 ns
The same test couldn't be used for my kernel-rt:
$ uname -r
2.6.31.12-rt20
$ latency-test
The -rt20 kernel bears little or no resemblance to the rtai version, and
latency-test will not run without its features.
insmod: can't read
'/usr/realtime-2.6.31.12-rt20/modules/rtai_hal.ko':
No such file or directory
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
ERROR: Module hal_lib does not exist in /proc/modules
ERROR: Module rtapi does not exist in /proc/modules
ERROR: Module rtai_math does not exist in /proc/modules
ERROR: Module rtai_sem does not exist in /proc/modules
ERROR: Module rtai_fifos does not exist in /proc/modules
/usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched
[snip]
ERROR: Module rtai_hal does not exist in /proc/modules
Btw. should I commend out the EMC2 memlock when doing audio work again
or doesn't have it an impact?
$ cat /etc/security/limits.conf | grep memlock
# - memlock - max locked-in-memory address space (KB)
@audio - memlock unlimited
# @audio - memlock 2000000
* hard memlock 20480 #EMC2
At only 20k, I doubt it makes much difference, but test anyway. Cheers!
Ralf
PS: What now? It's my second hardware set up. I just bought a new
computer a long time ago, because the old computer wasn't ok for Linux
too, but I don't have the money to pay for one machine after the other,
until I might have good luck. Both machines are 100% stable for
Windows, for Linux I also get asyncs + distortion when using JACK2. I
didn't test if current JACK1 is ok, or if it would disconnect clients.
Don't get me wrong, I never was a private Windows user, it just were
installs for testings. I'm using Linux only at home.
Being an ardent purist can bite you. As another friend of mine would
say, use what works. Cheers!
Ralf
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Don't SANFORIZE me!!
30 Jun
30 Jun
1:20 a.m.
New subject: [64studio-users] MIDI jitter
On Sat, Jun 19, 2010 at 7:16 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
To bad that there isn't a MPU game port any more
on modern boards and that
e.g. my Terratec EWX 24/96 Envy24's MPU needs opto-couplers for the cable,
but what ever circuit I build on a brad board, they failed.
Time to mount my old mobo again and to test the game ports MPU with today
Linux, resp. to get a service manual for my Terratec.
http://github.com/koppi/alsa-midi-latency-test gives definite figures
showing MPU-401 and Envy24 based MIDI is much faster than USB midi.
Makes sense given there's no USB stack to traverse, and there's
probably a direct PCI-bus interrupt generated by MIDI data,
orchestrated by the plays-nice-with Linux ICE1712/1724 series (
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf ) which
efficiently implements PCI 2.1 bus-master and burst modes, though I'm
not sure if that would be used or needed for MIDI.
What's interesting to note is that most of the USB MIDI interfaces do
not have consistent latency (Other than the Roland UM2's consistent
2.15ms) whereas MPU-401 (1.13mS) and VT1712 (0.97-1.04mS) have this
consistency. In contrast an M-audio midisport USB has latency ranging
from 3.11-5.38 ms ==> 2ms "jitter" just in the hardware alone, with
the jitter being greater than the total latency of a MPU401 or
ICE1724-based MIDI.
Did I ever mention that firewire and USB are probably the most
bone-headed way of doing low-latency audio ever thought of? It begs
failure both in theory and practice. But since people following
fashion are the quickest lemmings to fall off the cliff
(fashion-following being the losing end of a ponzi scheme), the Linux
community can benefit from their stupidity: With lots of people moving
to USB and Firewire configurations, E-bay is full of used ICE1712 or
ICE1724-based soundcards, many of which have MIDI ports, and some
which have waveblaster headers. For example the VT1712-based $20.00
Terratec DMX6Fire with a front midi port and an internal 26 pin
waveblaster header for my Yamaha db50xg (NEC XR385). Or the
VT1723-based $0.99 Dynex dx-sc51 with a single 26 pin waveblaster MIDI
port (TTL level MIDI in and out).
The only thing lacking on these ten year old designs are a modern A/D
and D/A section and analog section, which is why I started the
following threads on LAU:
http://old.nabble.com/digital-upgrade-of-older-equipment-via-I2S-with-jitte…
http://old.nabble.com/turning-a-consumer-soundcard-into-%22prosumer%22-w--q…
Bottom line: MIDI implementation on the ICE VT1712 is faster than an
MPU-401 and both are faster than the quickest USB implementation:
http://github.com/koppi/alsa-midi-latency-test/blob/master/benchmarks/m-aud…
(ICE vt1712 soundchip, also using realtime prio)
.............................
$ alsa-midi-latency-test -R -i 20:0 -o 20:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
[...]
latency distribution:
1.0 - 1.1 ms: 10000 ##################################################
[...]
best latency was 0.97 ms
worst latency was 1.04 ms, which is great
.............................
http://github.com/koppi/alsa-midi-latency-test/blob/master/benchmarks/mpu40…
..............................
latency distribution:
[...]
1.0 - 1.1 ms: 3714 ##############################
1.1 - 1.2 ms: 6286 ##################################################
[...]
worst latency was 1.13 ms, which is great.
...................................
http://github.com/koppi/alsa-midi-latency-test/blob/master/benchmarks/um2ex…
...................................
latency distribution:
[...]
1.1 - 1.2 ms: 3 #
1.2 - 1.3 ms: 19 #
1.3 - 1.4 ms: 13 #
1.4 - 1.5 ms: 23 #
1.5 - 1.6 ms: 88 #
1.6 - 1.7 ms: 14 #
1.7 - 1.8 ms: 16 #
1.8 - 1.9 ms: 20 #
1.9 - 2.0 ms: 17 #
2.0 - 2.1 ms: 9773 ##################################################
2.1 - 2.2 ms: 13 #
[...]
worst latency was 2.15 ms, which is great.
...................................
-- Niels
http://nielsmayer.com
4:35 a.m.
New subject: [64studio-users] MIDI jitter
On Tue, 2010-06-29 at 18:20 -0700, Niels Mayer wrote:
TTL level MIDI in and out
Assumed it's not broken, than for my Terratec EWX 24/96 there's an issue
for the pin allocation.
Do the ports for most sound cards usually have the common pin
allocation?
My ASUS M2A-VM HDMI has got
1 x PCI Express x16 formerly used for HDMI, now for a GeForce 7200 GS
1 x PCI Express x1 slot unused
2 x PCI one unused, the other for the Terratec EWX 24/96
Mounting an additional sound card won't cause an issue because of an
additional interrupt?
There will be no issues, e.g. for JACK, if I would use the Terratec EWX
24/96 for audio and another sound card for MIDI?
So USB MIDInterfaces are for bulk dump only ;)?
:)
Ralf
6:42 a.m.
New subject: [64studio-users] MIDI jitter
I don't know anything about the terratec as I bought my first (used)
card manufactured by them recently: they're almost mercedes-like in
their overengineering of things (super high quality circuit board and
engineering) and the documentation is always sparse... perhaps there's
a hidden jumper that sets the mode of the header socket?? Just like my
DMX6Fire has a "digital xtension" socket into which you can plugin a
waldorf microwave synth module and i'd love to find out the i2s data
input and output pinouts so as to replace the analog frontend w/ a few
of these http://www.twistedpearaudio.com/digital/wm8804.aspx and gain
extra digital ins/outs in place of not-so-great-sounding analog
front-end (alas using essentially the same components as on the ewx
24/96 on the dmx6fire 24/96, essentially terratec's version of
m-audio's 24/96 and Delta-66). But the built-in, software controlled
switch (envy24control) between TTL-spdif, optical-spdif and coax-spdif
all but makes up for the analog front end... as do the two full-speed
midi ports, one driving my db50xg clone.
http://www.soundonsound.com/sos/apr01/articles/soundcard.asp
## On the circuit board itself is a 16-pin header socket, which connects to a
## supplied cable terminating in a dummy backplate and 15-way D-type connector.
## Into this you can either plug a standard MIDI soundcard adaptor
cable, or a proprietary
## Terratec phono preamp to help transfer vinyl to CD, both of which
are optional extras.
ASUS M2A-VM HDMI... Mounting an additional sound card
won't cause an issue because of an
additional interrupt?
It shouldn't, or at least it hasn't for me using similar hardware
(M2N-68VM for example).
There will be no issues, e.g. for JACK, if I would use
the Terratec EWX
24/96 for audio and another sound card for MIDI?
Just be sure you like the sound of the terratec's weak-sounding bass
assuming it sounds similar to the dmx6fire's using the same parts and
probably design (which could imho easily be modded back to decency,
see sound files for comparison at end of
.http://linuxaudio.org/mailarchive/lau/2010/6/28/170833 )
The other card's MIDI devices should just appear as a separate ALSA
MIDI device. ALSA midi will function independent of whether jack is
running or not, and independent of which soundcard is used for
jack-audio. If you need to have jack-audio work across two cards,
that's another matter entirely: they'd best be the same kind of card,
and have their SPDIF used-up for syncing between them. And I'm
ignoring jack-midi entirely , as I don't use it that much; qjackctl's
patchbay integration of ALSA midi devices makes jack midi a bit
superfluous for my uses.
Niels
http://nielsmayer.com
7:26 a.m.
New subject: [64studio-users] MIDI jitter
On Tue, 2010-06-29 at 23:42 -0700, Niels Mayer wrote:
I don't know anything about the terratec as I
bought my first (used)
card manufactured by them recently: they're almost mercedes-like in
their overengineering of things (super high quality circuit board and
engineering) and the documentation is always sparse... perhaps there's
a hidden jumper that sets the mode of the header socket?? Just like my
DMX6Fire has a "digital xtension" socket into which you can plugin a
waldorf microwave synth module and i'd love to find out the i2s data
input and output pinouts so as to replace the analog frontend w/ a few
of these http://www.twistedpearaudio.com/digital/wm8804.aspx and gain
extra digital ins/outs in place of not-so-great-sounding analog
front-end (alas using essentially the same components as on the ewx
24/96 on the dmx6fire 24/96, essentially terratec's version of
m-audio's 24/96 and Delta-66). But the built-in, software controlled
switch (envy24control) between TTL-spdif, optical-spdif and coax-spdif
all but makes up for the analog front end... as do the two full-speed
midi ports, one driving my db50xg clone.
http://www.soundonsound.com/sos/apr01/articles/soundcard.asp
## On the circuit board itself is a 16-pin header socket, which connects to a
## supplied cable terminating in a dummy backplate and 15-way D-type connector.
## Into this you can either plug a standard MIDI soundcard adaptor
cable, or a proprietary
## Terratec phono preamp to help transfer vinyl to CD, both of which
are optional extras.
I don't like the sound of the Terratec EWX 24/96, but it was for
free ;).
ASUS M2A-VM HDMI... Mounting an additional sound
card won't cause an issue because of an
additional interrupt?
It shouldn't, or at least it hasn't for me using similar hardware
(M2N-68VM for example).
There will be no issues, e.g. for JACK, if I
would use the Terratec EWX
24/96 for audio and another sound card for MIDI?
Just be sure you like the sound of the terratec's weak-sounding bass
assuming it sounds similar to the dmx6fire's using the same parts and
probably design (which could imho easily be modded back to decency,
see sound files for comparison at end of
.http://linuxaudio.org/mailarchive/lau/2010/6/28/170833 ) The other card's MIDI devices should just appear
as a separate ALSA
MIDI device. ALSA midi will function independent of whether jack is
running or not, and independent of which soundcard is used for
jack-audio. If you need to have jack-audio work across two cards,
that's another matter entirely:
No no :)
what ever sound card I should get, I can live with using one duplex
stereo. I would be much more comfortable with 16 audio IOs, but that's
not important regarding to the MIDI jitter issue.
Thank you. Ok, IIUC jackd hw:blabla is for audio, but for ALSA MIDI
there would appear all devices?!
they'd best be the same kind of card,
and have their SPDIF used-up for syncing between them. And I'm
ignoring jack-midi entirely , as I don't use it that much; qjackctl's
patchbay integration of ALSA midi devices makes jack midi a bit
superfluous for my uses.
Niels
http://nielsmayer.com
You say I can use my ElCheapo EWX 24/96 with another ElCheapo for audio,
by any other vendor, just by connecting S/PDIF to sync the channels? I
read about this and I also read about some solutions using my 'roof
gutter soldering iron'?
I had a champagne breakfast, hence I didn't read the links, I just was
curious for your reply. Again, thanx, I'll read the links in the
evening.
FWIW, there aren't jumpers on the Terratec and I guess the used MPU by
the two provided by the EnvyChip is broken. For my old mobo's gameport I
soldered an adapter without TTLs and opto-couplers. This cable wasn't
fine for the Terratec, hence I took my BreadBoard and checked several
circuits, without TTLs, but opto-couplers. While I was a professional
using the soldering iron, today I should get glasses. I damaged the
jack, because I wasn't able to see what I did solder, so I might be the
one who killed the Envy's MPU ;). But maybe they do use some exotic pin
allocation. Referring to you, it's more likely that the MPU was broken
or that I did break it, because my arms were not long enough for my bad
eyes.
Ok, I'll get another ElCheapo just for MIDI and solder a usual adapter
with or without opto-couplers, but by using a magnifier.
The USB MIDI still is usable to dump sounds and it was < 20,-€ at
Thomann.
To be continued.
Ralf
1 Jul
1 Jul
11:31 p.m.
New subject: [64studio-users] MIDI jitter
[[see also latency test results for USB 1.0 devices Emagic MT-4 and
Edirol UM-2, below reply]]
On Wed, Jun 30, 2010 at 12:26 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
You say I can use my ElCheapo EWX 24/96 with another
ElCheapo for audio,
by any other vendor, just by connecting S/PDIF to sync the channels?
I don't think that is possible, except by luck. I meant two of the
same brand/manufacturer cheapo cards with SPDIF ins, e.g.
two or three Delta-66's (nb: no vt17212 midi), to or three Dmx6Fire's
(one vt1712 real midi, one ttl midi), or Audiophile 24/96's (one
vt1712 real midi)....
It is possible that you could do this with multiple cards all using
snd-ice1712 -- because anything's possible and you have the sourcecode
to the drivers... :-)
FWIW, there aren't jumpers on the Terratec and I
guess the used MPU by
the two provided by the EnvyChip is broken. For my old mobo's gameport I
soldered an adapter without TTLs and opto-couplers. This cable wasn't
fine for the Terratec, hence I took my BreadBoard and checked several
circuits, without TTLs, but opto-couplers.
One big issue is that real MIDI is a current-loop interface, with the
optocoupler allowing completely independent circuits to be connected
w/o creating ground loops and less potential to induce noise from
other connected machines. Devices expecting a current-loop are not
going to function properly when given TTL levels. You could probably
fake something up w/ TTL bus-drivers, but what's the point -- there's
probably a zillion game cable ports available for sale uses....
----------------------------------------------------------------------
FYI, regarding MIDI latency: some USB tests first (since the
1712-basedDMX6Fire is now waiting for a machine to house it).
Note that each test doesn't have a lot of variation, but there are
single outliers that indicate the potential for a very occasional few
extra ms of jitter. Note that jitter is additive... in that if you're
trying to come up with worst-case timing specifications, you need to
add all the best cases observed to come up with the overall best case,
and all the worst cases observed to come up with an overall worst
case. As you add layers and multiple devices all "chained" you can
end up with a massive "jitter multiplication effect" where you can't
hear any of the individual worst cases, but they'll all manage to
coalesce into the worst case -- usually just in time for an important
demo/concert/software-release/etc. One of the other properties of
jitter is that it likes to stay dormant until something really
important is going to fail because you didn't take it into account.
Trimming out jitter at the device or OS level is certainly worthwhile
given jitter's additive properties. Add enough worst case hardware
jitters, worst-case kernel latency and jitter, application level
latency and jitter, and you could easily come up with a jitter value
that is within human ranges of perception.
The test confirms that Emagic's USB Midi devices work as well
spec-wise as they do physically (a highly recommended USB MIDI box --
cost about $25.00 on e-bay, vs. $30.00 for the UM-2 with two fewer
output ports).
Using:
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
On host using ASUS M4A78T-E motherboard and AMD
Phenom-II processor
running stock Fedora 12 kernel:
Linux gnulem 2.6.32.14-127.fc12.x86_64 #1 SMP Fri May
28 04:30:39 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
A) Edirol UM-2 ( http://qbik.ch/usb/devices/showdev.php?id=1244 )
(NB: tested using an illegally-long 30-foot USB cable -- that works
fine with the UM-2 slow USB device).
Device: 36:0 UM-2 UM-2 MIDI 1
Command: alsa-midi-latency-test -w -r -R -i 36:0 -o 36:0
Test1)
...
2.5 - 2.6 ms: 1 #
...
2.9 - 3.0 ms: 61 #
3.0 - 3.1 ms: 9938 ##################################################
best latency was 2.46 ms
worst latency was 3.03 ms, which is great.
Test2)
...
2.9 - 3.0 ms: 61 #
3.0 - 3.1 ms: 9938 ##################################################
...
4.0 - 4.1 ms: 1 #
best latency was 2.88 ms
worst latency was 4.00 ms, which is great.
Test3)
...
2.7 - 2.8 ms: 1 #
...
2.9 - 3.0 ms: 60 #
3.0 - 3.1 ms: 9938 ##################################################
...
4.0 - 4.1 ms: 1 #
best latency was 2.69 ms
worst latency was 4.00 ms, which is great.
Test4)
...
2.7 - 2.8 ms: 1 #
...
2.9 - 3.0 ms: 60 #
3.0 - 3.1 ms: 9939 ##################################################
best latency was 2.73 ms
worst latency was 3.03 ms, which is great.
----------------------------------------------------------------------
B) Emagic MT-4 ( http://qbik.ch/usb/devices/showdev.php?id=3171 )
Device: 28:0 MT4 MT4 MIDI 1
Command: alsa-midi-latency-test -w -r -R -i 28:0 -o 28:0
Test1)
...
1.5 - 1.6 ms: 2 #
...
1.9 - 2.0 ms: 42 #
2.0 - 2.1 ms: 9953 ##################################################
2.1 - 2.2 ms: 1 #
...
2.6 - 2.7 ms: 1 #
...
2.9 - 3.0 ms: 1 #
best latency was 1.50 ms
worst latency was 2.88 ms, which is great.
Test2)
...
1.9 - 2.0 ms: 41 #
2.0 - 2.1 ms: 9957 ##################################################
...
3.0 - 3.1 ms: 2 #
best latency was 1.88 ms
worst latency was 3.00 ms, which is great.
Test3)
...
1.5 - 1.6 ms: 1 #
...
1.9 - 2.0 ms: 42 #
2.0 - 2.1 ms: 9956 ##################################################
...
3.0 - 3.1 ms: 1 #
best latency was 1.45 ms
worst latency was 2.99 ms, which is great.
Test4)
...
1.9 - 2.0 ms: 41 #
2.0 - 2.1 ms: 9956 ##################################################
2.1 - 2.2 ms: 1 #
2.2 - 2.3 ms: 1 #
...
3.0 - 3.1 ms: 1 #
best latency was 1.88 ms
worst latency was 2.99 ms, which is great.
-- Niels
http://nielsmayer.com
11:43 p.m.
New subject: [64studio-users] MIDI jitter
On Thu, Jul 1, 2010 at 7:31 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
[[see also latency test results for USB 1.0 devices
Emagic MT-4 and
Edirol UM-2, below reply]]
just for comparison, here are the results for an RME Digiface:
sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000999848 s
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 1.00; 1.00
3; 1.00; 1.00
16; 2.00; 2.00
2530; 2.00; 2.00
9999; 1.00; 2.00
done.
latency distribution:
0.0 - 0.1 ms: 3
#
...
1.0 - 1.1 ms: 9787 ##################################################
...
2.0 - 2.1 ms: 210 #
SUCCESS
best latency was 0.00 ms
worst latency was 2.00 ms, which is great.
2 Jul
2 Jul
10:13 a.m.
New subject: [64studio-users] MIDI jitter
On Thu, Jul 01, 2010 at 07:43:38PM -0400, Paul Davis wrote:
You're both missing an argument after -w. I wonder (but haven't
checked the source) why the tool even starts when you don't provide the
value for the wait time.
Niels, you need to re-evaluate everything, too, your data is also aligned
to USB frames as pointed out by Clemens two days ago.
I use -w 20 -r now, alsa-midi-latency-test then prints out a message like
"interval between measurements: 20.000 .. 40.000 ms".
HTH
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
[[see also
latency test results for USB 1.0 devices Emagic MT-4 and
Edirol UM-2, below reply]]
just for comparison, here are the results for an RME Digiface:
sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0
11:50 a.m.
New subject: [64studio-users] MIDI jitter
On Fri, Jul 2, 2010 at 6:12 AM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote:
On Thu, Jul 01, 2010 at 07:43:38PM -0400, Paul Davis
wrote:
You're both missing an argument after -w. I wonder (but haven't
checked the source) why the tool even starts when you don't provide the
value for the wait time.
New results:
sudo /usr/bin/alsa-midi-latency-test -w 20 -r -R -i 20:0 -o 20:0
[[see
also latency test results for USB 1.0 devices Emagic MT-4 and
Edirol UM-2, below reply]]
just for comparison, here are the results for an RME Digiface:
sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0 alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000999848 s
interval between measurements: 20.000 .. 40.000 ms
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 1.00; 1.00
6; 1.00; 1.00
9999; 1.00; 1.00
done.
latency distribution:
0.0 - 0.1 ms: 4
#
...
1.0 - 1.1 ms: 9996 ##################################################
SUCCESS
best latency was 0.00 ms
worst latency was 1.00 ms, which is great.
1:51 p.m.
New subject: [64studio-users] MIDI jitter
On Friday 02 July 2010, Paul Davis wrote:
Hmm, I'm on mdv-2010-x64 at the moment, what package would I find this test
utility in?
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The man who can smile when something goes wrong has thought of someone he
can blame it on
-- Fundamental Law of Thermodynamics n�3
On Fri, Jul 2, 2010 at 6:12 AM, Adrian Knoth
<adi(a)drcomp.erfurt.thur.de>
wrote:
> On Thu, Jul 01, 2010 at 07:43:38PM -0400, Paul
Davis wrote:
[...]
You're
both missing an argument after -w. I wonder (but haven't
checked the source) why the tool even starts when you don't provide the
value for the wait time.
New results:
sudo /usr/bin/alsa-midi-latency-test -w 20 -r -R -i 20:0 -o 20:0
3 Jul
3 Jul
12:30 p.m.
New subject: [64studio-users] MIDI jitter
On Fri, 2010-07-02 at 09:51 -0400, Gene Heskett wrote:
Hmm, I'm on mdv-2010-x64 at the moment, what
package would I find this test
utility in?
Hi Gene :)
install (debhelper) autotools-dev automake libasound2-dev
$ git clone git://github.com/koppi/alsa-midi-latency-test.git
$ cd alsa-midi-latency-test
$ sh autogen.sh
$ ./configure
# checkinstall (or # make install)
# make clean
Cheers!
Ralf
--
"Suse 11.2 - Proprietärer NVIDIA-Treiber
Beitrag von stachelmaus » 3. Jul 2010, 12:48
Hi :)
für einen selbst gebauten Kernel 2.6.31.6-rt19 x86_64 habe ich den
proprietären NVIDIA Treiber installiert, für den neueren selbst gebauten
Kernel 2.6.33.5-rt23 x86_64 versuche ich nun ausschließlich das Modul zu
bauen, doch es funktionierte bisher nicht.
Der wesentliche Auszug aus /var/log/nvidia-installer.log ist
wahrscheinlich
"[...] test -e include/generated/autoconf.h -a -e
include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/generated/autoconf.h or include/config/auto.conf are
missing.";\
echo " Run 'make oldconfig && make prepare' on kernel src to fix
it.[...]".
Das ausführen von make oldconfig && make prepare hat nichts gebracht,
bzw. existieren die Dateien include/generated/autoconf.h und
include/config/auto.conf im Kernel src samt Inhalten.
Wozu es auch immer gut sein mag, den Kernel 2.6.31.6-rt19 gebootet habe
ich es u.a. mit sh ./NVIDIA*.run -a --no-questions -K
--kernel-name=2.6.33.5-rt23 und den Kernel 2.6.33.5-rt23 gebootet u.a.
mit sh ./NVIDIA*.run -a -K versucht.
Der natürlich nicht aktualisierte Installer für eine GeForce 7200 GS ist
NVIDIA-Linux-x86_64-195.36.15-pkg2.run.
Grüße
Ralf" (http://www.linux-club.de/viewtopic.php?f=48&t=110034)
1:01 p.m.
New subject: [64studio-users] MIDI jitter
PS: Perhaps you need to install git-core too.
2 Jul
2 Jul
9:51 p.m.
New subject: [64studio-users] MIDI jitter
Here's the new results with "-w 20" (nb: "-w" == "-w
0")
On Thu, Jul 1, 2010 at 4:31 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
A) Edirol UM-2 (
http://qbik.ch/usb/devices/showdev.php?id=1244 )
(NB: tested using an illegally-long 30-foot USB cable -- that works
fine with the UM-2 slow USB device).
Device: 36:0 UM-2 UM-2 MIDI 1
sudo alsa-midi-latency-test -w 20 -r -R -i 36:0 -o 36:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
interval between measurements: 20.000 .. 40.000 ms
...
Test1)
2.0 - 2.1 ms: 2 #
2.1 - 2.2 ms: 485 ########################
2.2 - 2.3 ms: 995 #################################################
2.3 - 2.4 ms: 1010 #################################################
2.4 - 2.5 ms: 1007 #################################################
2.5 - 2.6 ms: 976 ################################################
2.6 - 2.7 ms: 1000 #################################################
2.7 - 2.8 ms: 981 ################################################
2.8 - 2.9 ms: 1021 ##################################################
2.9 - 3.0 ms: 950 ##############################################
3.0 - 3.1 ms: 1025 ##################################################
3.1 - 3.2 ms: 547 ###########################
3.2 - 3.3 ms: 1 #
best latency was 2.03 ms
worst latency was 3.19 ms, which is great.
Test2)
2.1 - 2.2 ms: 500 #########################
2.2 - 2.3 ms: 1000 #################################################
2.3 - 2.4 ms: 1003 #################################################
2.4 - 2.5 ms: 1007 #################################################
2.5 - 2.6 ms: 978 ################################################
2.6 - 2.7 ms: 1004 #################################################
2.7 - 2.8 ms: 991 #################################################
2.8 - 2.9 ms: 1010 ##################################################
2.9 - 3.0 ms: 951 ###############################################
3.0 - 3.1 ms: 1018 ##################################################
3.1 - 3.2 ms: 538 ##########################
best latency was 2.07 ms
worst latency was 3.11 ms, which is great.
....................................................................................................................
B) Emagic MT-4 (
http://qbik.ch/usb/devices/showdev.php?id=3171 )
Device: 28:0 MT4 MT4 MIDI 1
sudo alsa-midi-latency-test -w 20 -r -R -i 28:0 -o 28:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
interval between measurements: 20.000 .. 40.000 ms
Test1)
1.2 - 1.3 ms: 1 #
1.3 - 1.4 ms: 727 ###################################
1.4 - 1.5 ms: 1017 #################################################
1.5 - 1.6 ms: 973 ##############################################
1.6 - 1.7 ms: 1007 ################################################
1.7 - 1.8 ms: 981 ###############################################
1.8 - 1.9 ms: 1021 #################################################
1.9 - 2.0 ms: 944 #############################################
2.0 - 2.1 ms: 1019 #################################################
2.1 - 2.2 ms: 1048 ##################################################
2.2 - 2.3 ms: 993 ###############################################
2.3 - 2.4 ms: 268 #############
2.4 - 2.5 ms: 1 #
best latency was 1.18 ms
worst latency was 2.37 ms, which is great.
Test2)
1.2 - 1.3 ms: 3 #
1.3 - 1.4 ms: 710 ##################################
1.4 - 1.5 ms: 1016 ################################################
1.5 - 1.6 ms: 978 ##############################################
1.6 - 1.7 ms: 1001 ################################################
1.7 - 1.8 ms: 995 ###############################################
1.8 - 1.9 ms: 1010 ################################################
1.9 - 2.0 ms: 947 #############################################
2.0 - 2.1 ms: 1023 #################################################
2.1 - 2.2 ms: 1053 ##################################################
2.2 - 2.3 ms: 1004 ################################################
2.3 - 2.4 ms: 260 ############
best latency was 1.19 ms
worst latency was 2.33 ms, which is great.
.......................................................................................................................
-- Niels
http://nielsmayer.com
3 Jul
3 Jul
12:32 p.m.
New subject: [64studio-users] MIDI jitter
On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer wrote:
sudo alsa-midi-latency-test -w 20 -r -R -i 36:0 -o
36:0
Perhaps better without sudo.
--
"Suse 11.2 - Proprietärer NVIDIA-Treiber
Beitrag von stachelmaus » 3. Jul 2010, 12:48
Hi :)
für einen selbst gebauten Kernel 2.6.31.6-rt19 x86_64 habe ich den
proprietären NVIDIA Treiber installiert, für den neueren selbst gebauten
Kernel 2.6.33.5-rt23 x86_64 versuche ich nun ausschließlich das Modul zu
bauen, doch es funktionierte bisher nicht.
Der wesentliche Auszug aus /var/log/nvidia-installer.log ist
wahrscheinlich
"[...] test -e include/generated/autoconf.h -a -e
include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/generated/autoconf.h or include/config/auto.conf are
missing.";\
echo " Run 'make oldconfig && make prepare' on kernel src to fix
it.[...]".
Das ausführen von make oldconfig && make prepare hat nichts gebracht,
bzw. existieren die Dateien include/generated/autoconf.h und
include/config/auto.conf im Kernel src samt Inhalten.
Wozu es auch immer gut sein mag, den Kernel 2.6.31.6-rt19 gebootet habe
ich es u.a. mit sh ./NVIDIA*.run -a --no-questions -K
--kernel-name=2.6.33.5-rt23 und den Kernel 2.6.33.5-rt23 gebootet u.a.
mit sh ./NVIDIA*.run -a -K versucht.
Der natürlich nicht aktualisierte Installer für eine GeForce 7200 GS ist
NVIDIA-Linux-x86_64-195.36.15-pkg2.run.
Grüße
Ralf" (http://www.linux-club.de/viewtopic.php?f=48&t=110034)
3:28 p.m.
New subject: [64studio-users] MIDI jitter
On Saturday 03 July 2010, Ralf Mardorf wrote:
On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer wrote:
Probably, as that will test the user environment.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Q: What do you call the scratches that you get when a female
sheep bites you?
A: Ewe nicks.
sudo alsa-midi-latency-test -w 20 -r -R -i 36:0
-o 36:0
Perhaps better without sudo.
4:12 p.m.
New subject: [64studio-users] MIDI jitter
2010/7/3 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>et>:
On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer wrote:
I was just following Paul Davis' lead (*).
For me, there's probably no need for this, as my user 'npm' has
membership in group jackuser spec'd in /etc/security/limits.conf :
sudo alsa-midi-latency-test -w 20 -r -R -i 36:0
-o 36:0
Perhaps better without sudo. ## Automatically appended by the Planet CCRMA
jack-audio-connection-kit
## NPM changed '*' to @jackuser to limit priority escalation to jackd.
@jackuser - rtprio 99
@jackuser - memlock 4194304
@jackuser - nice -10
And /etc/group has entries like:
jackuser:x:476:npm
rtkit:x:470:npm
Running as root sidesteps the need for such setup, as well as any
permissions issues on the devices under test. From what I can tell,
the only privileged access in the test program is indicated by the
following output from 'alsa-midi-latency-test':
set_realtime_priority(SCHED_FIFO, 99).. done.
.............................
(*):
On Fri, Jul 2, 2010 at 4:50 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
just for comparison, here are the results for an RME
Digiface:
sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0
...
best latency was 0.00 ms
worst latency was 1.00 ms, which is great.
Better if Paul re-ran the test with "-w 20" argument so his fancypants
RME doesn't end up unfairly claiming the 0ms latency title :-) ...
Who will claim the low-latency, low-jitter title in this epic
battle-of-the-geek:
VLSI-implemented midi on the VT1712 or RME's custom FPGA programming??
[[ http://old.nabble.com/Is-RME-HDSPe-AES-supported-by-alsa--td28460997.html
]].
Note that RME's FPGA implemented MIDI and mixer lacks an important
feature we get on cheap vt1712 VLSI implementations:
MIDI control over the built-in digital mixer via envy24control:
http://alsa-tools.sourcearchive.com/documentation/1.0.22-1/midi_8c-source.h…
(yes there's a built-in midi-controllable, 20 channel, 36-bit digital
mixer hidden in that cheap ebay vt1712 --
http://www.via.com.tw/en/products/audio/controllers/envy24/ ).
Digital mixing is an important feature of RME's TotalMix :
http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_sup…
But MIDI control of that mixer seems to be lacking in alsa's hdspmixer
and RME's implementation:
http://www.rme-audio.de/forum/viewtopic.php?id=6105
-- Niels
http://nielsmayer.com
PS: worlds' cheapest digital mixing console, take old/slow computer,
add linux and these:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=230491593275
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260501295877
5:33 p.m.
New subject: [64studio-users] MIDI jitter
There's still an issue with the latest Kernel and my NVIDIA, but on
Tuesday I should be able to compare my USB's to my PCI card's MIDI. I
guess @jackuser - nice -10 for rt has got no impact.
I'm thinking to run the ALSA MIDI latency test without and with hrtimer
(hpet) and without and with glxgears running.
On Sat, 2010-07-03 at 09:12 -0700, Niels Mayer wrote:
2010/7/3 Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>et>:
--
"Suse 11.2 - Proprietärer NVIDIA-Treiber
Beitrag von stachelmaus » 3. Jul 2010, 12:48
Hi :)
für einen selbst gebauten Kernel 2.6.31.6-rt19 x86_64 habe ich den
proprietären NVIDIA Treiber installiert, für den neueren selbst gebauten
Kernel 2.6.33.5-rt23 x86_64 versuche ich nun ausschließlich das Modul zu
bauen, doch es funktionierte bisher nicht.
Der wesentliche Auszug aus /var/log/nvidia-installer.log ist
wahrscheinlich
"[...] test -e include/generated/autoconf.h -a -e
include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/generated/autoconf.h or include/config/auto.conf are
missing.";\
echo " Run 'make oldconfig && make prepare' on kernel src to fix
it.[...]".
Das ausführen von make oldconfig && make prepare hat nichts gebracht,
bzw. existieren die Dateien include/generated/autoconf.h und
include/config/auto.conf im Kernel src samt Inhalten.
Wozu es auch immer gut sein mag, den Kernel 2.6.31.6-rt19 gebootet habe
ich es u.a. mit sh ./NVIDIA*.run -a --no-questions -K
--kernel-name=2.6.33.5-rt23 und den Kernel 2.6.33.5-rt23 gebootet u.a.
mit sh ./NVIDIA*.run -a -K versucht.
Der natürlich nicht aktualisierte Installer für eine GeForce 7200 GS ist
NVIDIA-Linux-x86_64-195.36.15-pkg2.run.
Grüße
Ralf" (http://www.linux-club.de/viewtopic.php?f=48&t=110034)
On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer
wrote:
I was just following Paul Davis' lead (*).
For me, there's probably no need for this, as my user 'npm' has
membership in group jackuser spec'd in /etc/security/limits.conf :
sudo alsa-midi-latency-test -w 20 -r -R -i 36:0
-o 36:0
Perhaps better without sudo. ## Automatically appended by the Planet CCRMA
jack-audio-connection-kit
## NPM changed '*' to @jackuser to limit priority escalation to jackd.
@jackuser - rtprio 99
@jackuser - memlock 4194304
@jackuser - nice -10
And /etc/group has entries like:
jackuser:x:476:npm
rtkit:x:470:npm
Running as root sidesteps the need for such setup, as well as any
permissions issues on the devices under test. From what I can tell,
the only privileged access in the test program is indicated by the
following output from 'alsa-midi-latency-test':
set_realtime_priority(SCHED_FIFO, 99).. done.
.............................
(*):
On Fri, Jul 2, 2010 at 4:50 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
just for comparison, here are the results for an
RME Digiface:
sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0
...
best latency was 0.00 ms
worst latency was 1.00 ms, which is great.
Better if Paul re-ran the test with "-w 20" argument so his fancypants
RME doesn't end up unfairly claiming the 0ms latency title :-) ...
Who will claim the low-latency, low-jitter title in this epic
battle-of-the-geek:
VLSI-implemented midi on the VT1712 or RME's custom FPGA programming??
[[ http://old.nabble.com/Is-RME-HDSPe-AES-supported-by-alsa--td28460997.html
]].
Note that RME's FPGA implemented MIDI and mixer lacks an important
feature we get on cheap vt1712 VLSI implementations:
MIDI control over the built-in digital mixer via envy24control:
http://alsa-tools.sourcearchive.com/documentation/1.0.22-1/midi_8c-source.h…
(yes there's a built-in midi-controllable, 20 channel, 36-bit digital
mixer hidden in that cheap ebay vt1712 --
http://www.via.com.tw/en/products/audio/controllers/envy24/ ).
Digital mixing is an important feature of RME's TotalMix :
http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_sup…
But MIDI control of that mixer seems to be lacking in alsa's hdspmixer
and RME's implementation:
http://www.rme-audio.de/forum/viewtopic.php?id=6105
-- Niels
http://nielsmayer.com
PS: worlds' cheapest digital mixing console, take old/slow computer,
add linux and these:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=230491593275
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260501295877
4 Jul
4 Jul
4:45 p.m.
New subject: [64studio-users] MIDI jitter
On Sat, Jul 03, 2010 at 02:32:19PM +0200, Ralf Mardorf wrote:
[One line of content]
--
"Suse 11.2 - Proprietärer NVIDIA-Treiber
Beitrag von stachelmaus » 3. Jul 2010, 12:48
Hi :)
[this and more than 30 lines of German text about whatever in a signature]
For fuck's sake, stop spamming. Nobody is interested in your bloody
nvidia stupidity or whatever this "text" is about. There's really no
need to include the crap in every mail.
Read the netiquette and only come back iff you could be arsed to change
your signature into something that's at most four lines long.
Damn, where's my prozac?
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
6:45 p.m.
New subject: [64studio-users] MIDI jitter
On Sun, 2010-07-04 at 18:45 +0200, Adrian Knoth wrote:
Damn, where's my prozac?
When you go wild you shouldn't take selective serotonin reuptake
inhibitor, instead try some stimulus retarding tricyclic
antidepressants, if you need antidepressants, but tranquilizer.
I hope the signature is pleasant now and you are able to watch soccer
again and bawl out with the others.
--
http://www.linux-club.de/viewtopic.php?f=48&t=110034
5 Jul
5 Jul
7:16 a.m.
New subject: [64studio-users] MIDI jitter
Niels Mayer wrote:
Here's the new results with "-w 20" (nb:
"-w" == "-w 0")
As long we're optimizing for benchmarks: In recent enough kernel
versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control
"MIDI Input Mode" (the same as the "Light Load" checkbox in the
Windows
driver) which doesn't have much effect in practice but can improve
benchmark behaviour.
For bulk transfers (used by Roland devices in "High Load" mode, and
always by all other devices), the UHCI driver has a feature called FSBR
(full-speed bandwidth reclamation) which makes the controller poll the
device continuously instead of every 1 ms, as long as new input is
available every 10 ms. So to get better benchmark numbers, use "-w 1"
instead of "-w 20". (If your music doesn't have new notes every 10 ms,
this isn't very realistic, but it can improve latency between the
consecutive notes of a chord.)
Regards,
Clemens
A) Edirol UM-2
best latency was 2.07 ms
worst latency was 3.11 ms, which is great.
7:29 a.m.
New subject: [64studio-users] MIDI jitter
On Mon, 2010-07-05 at 09:16 +0200, Clemens Ladisch wrote:
Niels Mayer wrote:
I noticed that I run my test without the "-R" switch
"alsa-midi-latency-test -i20:0 -o20:0" and Gustin who already used "-w
20 -r" did also miss the "-R" switch, "alsa-midi-latency-test -i 16:0
-o
16:0 -w 20 -r".
alsa-midi-latency-test --help
-R, --realtime use realtime scheduling (default: no)
Did you add "-R"?
Cheers!
Ralf
Here's the new results with "-w 20"
(nb: "-w" == "-w 0")
As long we're optimizing for benchmarks: In recent enough kernel
versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control
"MIDI Input Mode" (the same as the "Light Load" checkbox in the
Windows
driver) which doesn't have much effect in practice but can improve
benchmark behaviour.
For bulk transfers (used by Roland devices in "High Load" mode, and
always by all other devices), the UHCI driver has a feature called FSBR
(full-speed bandwidth reclamation) which makes the controller poll the
device continuously instead of every 1 ms, as long as new input is
available every 10 ms. So to get better benchmark numbers, use "-w 1"
instead of "-w 20". (If your music doesn't have new notes every 10 ms,
this isn't very realistic, but it can improve latency between the
consecutive notes of a chord.)
Regards,
Clemens A) Edirol UM-2
best latency was 2.07 ms
worst latency was 3.11 ms, which is great.
8:14 a.m.
New subject: MIDI jitter - Today for 4 of 4 tests my USB device did pass all tests with success
Today my swissonic USB MIDInterface didn't fail the ALSA MIDI latency
tests.
There are 3 differences.
1. I didn't use 64 Studio 3.0-beta3 and I didn't use 64 Studio 3.3
alpha, but Suse 11.2 were the rt stuff isn't from the repositories, but
self build.
2. Using another kernel version, the kernels for 64 Studio were older
and newer, but the Suse kernel.
3. My PATA HDD is disconnected, it was connected and break some days
ago, but anyway I had timing issues when the drive was new too.
An additional note. Around 4 ms is what I got when I used 64 Studio and
did record audio 'of the MIDI data' and then interpreted the waveforms
visually.
With this visually jitter around 4 ms, the audible result was unusable
to produce music.
Within the next days I'll get a SATA as replacement for the broken PATA
and an opto-coupler adapter for my PCI audio device, then I will run the
ALSA MIDI latency test again and much more important, I will do a test
making music.
I'm very sceptic regarding to the ALSA MIDI latency test, OTOH the PATA
might have caused 7 ms and IIRC 19 ms too and visually interpretation
might mistake because it's hard to find the start of waveforms in the
noise.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI
20:0 USB Device 0x170b:0x11 USB Device 0x170b:0x11 MIDI 1
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i20:0 -o20:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
interval between measurements: 20.000 .. 40.000 ms
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 1.50; 1.50
1; 2.21; 2.21
58; 2.24; 2.24
1614; 2.27; 2.27
9999; 1.60; 2.27
done.
latency distribution:
...
1.2 - 1.3 ms: 186 #########
1.3 - 1.4 ms: 1017
#################################################
1.4 - 1.5 ms: 1034
##################################################
1.5 - 1.6 ms: 968
###############################################
1.6 - 1.7 ms: 966
###############################################
1.7 - 1.8 ms: 1004
################################################
1.8 - 1.9 ms: 1037
##################################################
1.9 - 2.0 ms: 931 #############################################
2.0 - 2.1 ms: 1034
##################################################
2.1 - 2.2 ms: 1024
#################################################
2.2 - 2.3 ms: 788 ######################################
2.3 - 2.4 ms: 11 #
SUCCESS
best latency was 1.20 ms
worst latency was 2.27 ms, which is great.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -i20:0 -o20:0
alsa-midi-latency-test 0.0.3
clock resolution: 0.000000001 s
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 1.52; 1.52
1; 1.80; 1.80
2; 1.85; 1.85
3; 1.85; 1.85
4; 2.69; 2.69
11; 3.82; 3.82
26; 3.85; 3.85
40; 3.96; 3.96
9999; 1.99; 3.96
done.
latency distribution:
...
1.4 - 1.5 ms: 2 #
1.5 - 1.6 ms: 18 #
1.6 - 1.7 ms: 10 #
1.7 - 1.8 ms: 15 #
1.8 - 1.9 ms: 68 #
1.9 - 2.0 ms: 475 ###
2.0 - 2.1 ms: 9204
##################################################
2.1 - 2.2 ms: 111 #
2.2 - 2.3 ms: 45 #
2.3 - 2.4 ms: 13 #
2.4 - 2.5 ms: 6 #
2.5 - 2.6 ms: 19 #
2.6 - 2.7 ms: 1 #
2.7 - 2.8 ms: 1 #
...
3.1 - 3.2 ms: 2 #
3.2 - 3.3 ms: 3 #
3.3 - 3.4 ms: 2 #
3.4 - 3.5 ms: 1 #
...
3.8 - 3.9 ms: 2 #
3.9 - 4.0 ms: 1 #
4.0 - 4.1 ms: 1 #
SUCCESS
best latency was 1.42 ms
worst latency was 3.96 ms, which is great.
Then I run glxgears with the window always on top and repeated the
tests.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i20:0 -o20:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
interval between measurements: 20.000 .. 40.000 ms
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 1.68; 1.68
2; 2.16; 2.16
138; 2.17; 2.17
174; 2.19; 2.19
348; 2.20; 2.20
350; 2.20; 2.20
552; 2.21; 2.21
1708; 2.22; 2.22
3381; 2.24; 2.24
9999; 1.62; 2.24
done.
latency distribution:
...
1.2 - 1.3 ms: 532 ##########################
1.3 - 1.4 ms: 1017
#################################################
1.4 - 1.5 ms: 1010
################################################
1.5 - 1.6 ms: 980
###############################################
1.6 - 1.7 ms: 1001
################################################
1.7 - 1.8 ms: 990
################################################
1.8 - 1.9 ms: 1010
################################################
1.9 - 2.0 ms: 952 ##############################################
2.0 - 2.1 ms: 1026
#################################################
2.1 - 2.2 ms: 1042
##################################################
2.2 - 2.3 ms: 440 #####################
SUCCESS
best latency was 1.16 ms
worst latency was 2.24 ms, which is great.
While glxgears still was running I now moved windows by mouse too.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -i20:0 -o20:0
alsa-midi-latency-test 0.0.3
clock resolution: 0.000000001 s
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 2.07; 2.07
263; 2.10; 2.10
441; 2.11; 2.11
446; 3.76; 3.76
9999; 1.99; 3.76
done.
latency distribution:
...
1.2 - 1.3 ms: 4 #
1.3 - 1.4 ms: 3 #
1.4 - 1.5 ms: 7 #
1.5 - 1.6 ms: 5 #
1.6 - 1.7 ms: 7 #
1.7 - 1.8 ms: 3 #
1.8 - 1.9 ms: 19 #
1.9 - 2.0 ms: 204 #
2.0 - 2.1 ms: 9612
##################################################
2.1 - 2.2 ms: 94 #
2.2 - 2.3 ms: 14 #
2.3 - 2.4 ms: 2 #
2.4 - 2.5 ms: 7 #
2.5 - 2.6 ms: 7 #
2.6 - 2.7 ms: 3 #
2.7 - 2.8 ms: 5 #
2.8 - 2.9 ms: 1 #
...
3.6 - 3.7 ms: 2 #
...
3.8 - 3.9 ms: 1 #
SUCCESS
best latency was 1.22 ms
worst latency was 3.76 ms, which is great.
spinymouse11.2@suse11-2:~> uname -a
Linux suse11-2 2.6.31.6-rt19 #1 SMP PREEMPT RT Wed Nov 18 16:59:26 CET
2009 x86_64 x86_64 x86_64 GNU/Linux
9 Jul
9 Jul
9:03 p.m.
New subject: [64studio-users] MIDI jitter
On Mon, Jul 5, 2010 at 12:16 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
As long we're optimizing for benchmarks: In
recent enough kernel
versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control
"MIDI Input Mode" (the same as the "Light Load" checkbox in the
Windows
driver) which doesn't have much effect in practice but can improve
benchmark behaviour.
Note that for kernel 2.6.32.14-127.fc12.x86_64, and for
## snd-card-3 snd-usb-audio ## --> Emagic MT4
## alias snd-card-5 snd-usb-audio ## --> Roland UM-2
##
## amixer -c 5 --> returns nothing
## amixer -c 3 --> returns nothing
Maybe the feature will be present in fedora 13?
For bulk transfers (used by Roland devices in
"High Load" mode, and
always by all other devices), the UHCI driver has a feature called FSBR
(full-speed bandwidth reclamation) which makes the controller poll the
device continuously instead of every 1 ms, as long as new input is
available every 10 ms. So to get better benchmark numbers, use "-w 1"
instead of "-w 20". (If your music doesn't have new notes every 10 ms,
this isn't very realistic, but it can improve latency between the
consecutive notes of a chord.)
Here's results for the Roland UM-2 with the argument suggested:
## sudo alsa-midi-latency-test -w 1 -r -R -i 36:0 -o 36:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
interval between measurements: 1.000 .. 2.000 ms
Test1)
2.1 - 2.2 ms: 488 ########################
2.2 - 2.3 ms: 961 ###############################################
2.3 - 2.4 ms: 1023 ##################################################
2.4 - 2.5 ms: 1030 ##################################################
2.5 - 2.6 ms: 996 ################################################
2.6 - 2.7 ms: 971 ###############################################
2.7 - 2.8 ms: 952 ##############################################
2.8 - 2.9 ms: 1013 #################################################
2.9 - 3.0 ms: 1025 ##################################################
3.0 - 3.1 ms: 1013 #################################################
3.1 - 3.2 ms: 518 #########################
3.2 - 3.3 ms: 6 #
3.3 - 3.4 ms: 1 #
...
3.5 - 3.6 ms: 1 #
3.6 - 3.7 ms: 1 #
...
3.8 - 3.9 ms: 1 #
best latency was 2.08 ms
worst latency was 3.84 ms, which is great.
..........................................
Test2)
...
2.1 - 2.2 ms: 479 #######################
2.2 - 2.3 ms: 944 #############################################
2.3 - 2.4 ms: 1034 #################################################
2.4 - 2.5 ms: 1012 ################################################
2.5 - 2.6 ms: 1006 ################################################
2.6 - 2.7 ms: 985 ###############################################
2.7 - 2.8 ms: 913 ############################################
2.8 - 2.9 ms: 1046 ##################################################
2.9 - 3.0 ms: 1021 #################################################
3.0 - 3.1 ms: 1011 ################################################
3.1 - 3.2 ms: 543 ##########################
3.2 - 3.3 ms: 3 #
...
3.4 - 3.5 ms: 2 #
3.5 - 3.6 ms: 1 #
best latency was 2.07 ms
worst latency was 3.55 ms, which is great.
............................
Last time, with "-w 20":
Test1)
best latency was 2.03 ms
worst latency was 3.19 ms, which is great.
Test2)
best latency was 2.07 ms
worst latency was 3.11 ms, which is great.
-- Niels
http://nielsmayer.com
10 Jul
10 Jul
1:03 p.m.
New subject: [64studio-users] MIDI jitter
Niels Mayer wrote:
On Mon, Jul 5, 2010 at 12:16 AM, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
I forgot to mention that this control appears only when the device's
"Advanced Driver" mode is enabled.
Regards,
Clemens
As long we're optimizing for benchmarks: In
recent enough kernel
versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control
"MIDI Input Mode"
## alias snd-card-5 snd-usb-audio ## --> Roland UM-2
## amixer -c 5 --> returns nothing
30 Jun
30 Jun
7:42 a.m.
New subject: [64studio-users] MIDI jitter
PS:
Don't buy this one
http://www.thomann.de/gb/swissonic_midiusb_1x1.htm
When I bought it, it costs between 19 and 20 €. It's much better when
using it with Windows, but even for Windows it won't fit to the ears of
a musician.
I deeply suspect the USB MIDI device now causing jitter.
12:27 p.m.
New subject: [64studio-users] MIDI jitter
On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels Mayer wrote:
What's interesting to note is that most of the USB
MIDI interfaces do
not have consistent latency (Other than the Roland UM2's consistent
Let me just show you the result from my Midisport USB 2x2 (standard
edition when it was still produced by midiman, not the anniversary
edition):
set_realtime_priority(SCHED_FIFO, 20).. done.
clock resolution: 0.000000001 s
latency distribution:
...
3.1 - 3.2 ms: 1 #
...
3.9 - 4.0 ms: 1 #
4.0 - 4.1 ms: 9903 ##################################################
...
5.0 - 5.1 ms: 95 #
SUCCESS
best latency was 3.13 ms
worst latency was 5.00 ms, which is great.
This is a vanilla 2.6.34 kernel, no realtime patches, no nothing.
adi@hex:~$ cat /proc/asound/timers
G0: system timer : 4000.000us (10000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-1-0: PCM playback 0-1-0 : SLAVE
P0-1-1: PCM capture 0-1-1 : SLAVE
P0-2-1: PCM capture 0-2-1 : SLAVE
Not even HR timers. And yes, this is SMP, and yes, I have the "ondemand"
cpu governor, that is, the evil frequency scaling and the lot. Put
simply, it's a plain Debian unstable system, no latency tuning at all.
Ok, 4ms are not strikingly fast, but it's acceptable and shouldn't
matter in praxis. Especially I don't see any noteworthy jitter.
I'm going to measure the mainline kernels from 2.6.26 to 2.6.34 within
the next days to see if this stability can be accounted to the parts of
the RT patch that have been integrated into mainline.
If this hypothesis is correct, I should see a lot of jitter with older
kernels.
I'll also try to compare it against an onboard MPU-401, a firewire based
device and one or two more USB solutions.
Long story short: Seems things are not black (USB) and white (PCI).
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
12:48 p.m.
New subject: [64studio-users] MIDI jitter
On Wed, Jun 30, 2010 at 02:27:09PM +0200, Adrian Knoth wrote:
Let me just show you the result from my Midisport USB
2x2 (standard
edition when it was still produced by midiman, not the anniversary
edition):
set_realtime_priority(SCHED_FIFO, 20).. done.
clock resolution: 0.000000001 s
I've no idea how this test works, but if it uses the same
interface for TX an RX the results should be treated with
a healthy dose of scepticism.
To be really reliable, the transmitter and receiver should
be on different machines. Measuring absolute latency can
be difficult in the case (but not impossible) but jitter
is easy.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
latency distribution:
...
3.1 - 3.2 ms: 1 #
...
3.9 - 4.0 ms: 1 #
4.0 - 4.1 ms: 9903 ##################################################
...
5.0 - 5.1 ms: 95 #
SUCCESS
best latency was 3.13 ms
worst latency was 5.00 ms, which is great.
1 Jul
1 Jul
8:28 a.m.
New subject: [64studio-users] MIDI jitter
On Wed, 2010-06-30 at 14:48 +0200, fons(a)kokkinizita.net wrote:
I've no idea how this test works, but if it uses
the same
interface for TX an RX the results should be treated with
a healthy dose of scepticism.
Not only because the system is measuring it self, but also because there
is no way to see how much jitter there is for the input and how much
jitter there is for the output. Anyway, hw MIDI jitter is audible here
and my USB device failed the test, so what I hear, is what the test
confirms.
30 Jun
30 Jun
3:28 p.m.
New subject: [64studio-users] MIDI jitter
Adrian Knoth wrote:
The default parameters of this tool are unrealistic; the next MIDI
command is always sent immediately after the previous one has been
received, which tends to align everything to USB frames. Please use
the -w and -r options.
Regards,
Clemens
latency
distribution:
...
3.1 - 3.2 ms: 1 #
...
3.9 - 4.0 ms: 1 #
4.0 - 4.1 ms: 9903 ##################################################
...
5.0 - 5.1 ms: 95 #
1 Jul
1 Jul
9:53 a.m.
New subject: [64studio-users] MIDI jitter
On Wed, Jun 30, 2010 at 05:28:05PM +0200, Clemens Ladisch wrote:
The default parameters of this tool are unrealistic; the next MIDI
command is always sent immediately after the previous one has been
received, which tends to align everything to USB frames. Please use
the -w and -r options.
Absolutely. I already suspected 4ms being correlated to USB frames
(granularity 1ms, right?)
With random wait, it looks like this:
latency distribution:
...
3.1 - 3.2 ms: 1 #
...
3.9 - 4.0 ms: 1 #
4.0 - 4.1 ms: 9903 ##################################################
...
5.0 - 5.1 ms: 95 # latency distribution:
...
3.0 - 3.1 ms: 86 ####
3.1 - 3.2 ms: 986 ##################################################
3.2 - 3.3 ms: 958 #################################################
3.3 - 3.4 ms: 967 #################################################
3.4 - 3.5 ms: 985 ##################################################
3.5 - 3.6 ms: 927 ###############################################
3.6 - 3.7 ms: 966 #################################################
3.7 - 3.8 ms: 938 ################################################
3.8 - 3.9 ms: 980 ##################################################
3.9 - 4.0 ms: 904 ##############################################
4.0 - 4.1 ms: 906 ##############################################
4.1 - 4.2 ms: 45 ##
4.2 - 4.3 ms: 44 ##
4.3 - 4.4 ms: 38 ##
4.4 - 4.5 ms: 28 #
4.5 - 4.6 ms: 37 ##
4.6 - 4.7 ms: 34 ##
4.7 - 4.8 ms: 54 ###
4.8 - 4.9 ms: 34 ##
4.9 - 5.0 ms: 42 ##
5.0 - 5.1 ms: 40 ##
...
5.2 - 5.3 ms: 1 #
Probably still acceptable, given that the majority of packets deviates
by only 1ms.
Does USB have a notion of "ticks" (clock?), that is, frames are sent at
isochronous distances? Or is the host controller free to send a packet
whenever it wants to? Without the latter, 1ms jitter could be the result
of queueing up the data for the next time slot.
TIA
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
8:22 a.m.
New subject: [64studio-users] MIDI jitter
On Wed, 2010-06-30 at 14:27 +0200, Adrian Knoth wrote:
On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels Mayer
wrote:
I'll test PCI as soon as possible too.
Btw. while ports from other computers and my whole MIDI hardware is able
to use my 80ies self-made MIDI thru box, the level of the USB MIDI's
output is to weak to do it (I didn't re-adjust the thru box). Could it
be, that a weak level has impact to the interpretation of the slew rate,
regarding to high and low? Of course without using this box, because it
won't work, I'm thinking of connecting the IOs of the USB MIDI and
running the ALSA latency test.
What's interesting to note is that most of
the USB MIDI interfaces do
not have consistent latency (Other than the Roland UM2's consistent
Let me just show you the result from my Midisport USB 2x2 (standard
edition when it was still produced by midiman, not the anniversary
edition):
set_realtime_priority(SCHED_FIFO, 20).. done.
clock resolution: 0.000000001 s
latency distribution:
...
3.1 - 3.2 ms: 1 #
...
3.9 - 4.0 ms: 1 #
4.0 - 4.1 ms: 9903 ##################################################
...
5.0 - 5.1 ms: 95 #
SUCCESS
best latency was 3.13 ms
worst latency was 5.00 ms, which is great.
This is a vanilla 2.6.34 kernel, no realtime patches, no nothing.
adi@hex:~$ cat /proc/asound/timers
G0: system timer : 4000.000us (10000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-1-0: PCM playback 0-1-0 : SLAVE
P0-1-1: PCM capture 0-1-1 : SLAVE
P0-2-1: PCM capture 0-2-1 : SLAVE
Not even HR timers. And yes, this is SMP, and yes, I have the "ondemand"
cpu governor, that is, the evil frequency scaling and the lot. Put
simply, it's a plain Debian unstable system, no latency tuning at all.
Ok, 4ms are not strikingly fast, but it's acceptable and shouldn't
matter in praxis. Especially I don't see any noteworthy jitter.
I'm going to measure the mainline kernels from 2.6.26 to 2.6.34 within
the next days to see if this stability can be accounted to the parts of
the RT patch that have been integrated into mainline.
If this hypothesis is correct, I should see a lot of jitter with older
kernels.
I'll also try to compare it against an onboard MPU-401, a firewire based
device and one or two more USB solutions.
Long story short: Seems things are not black (USB) and white (PCI).
6:49 p.m.
New subject: [64studio-users] MIDI jitter
On Thursday 01 July 2010, Ralf Mardorf wrote:
On Wed, 2010-06-30 at 14:27 +0200, Adrian Knoth wrote:
Yes, but this is not the cause of the latency you are looking for. And yes,
the current capabilities of the drivers should be brought up to specs to
make sure the data doesn't get a scrambled bit occasionally.
On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels
Mayer wrote:
I'll test PCI as soon as possible too.
Btw. while ports from other computers and my whole MIDI hardware is able
to use my 80ies self-made MIDI thru box, the level of the USB MIDI's
output is to weak to do it (I didn't re-adjust the thru box). Could it
be, that a weak level has impact to the interpretation of the slew rate, What's interesting to note is that most of
the USB MIDI interfaces do
not have consistent latency (Other than the Roland UM2's consistent
Let me just show you the result from my Midisport USB 2x2 (standard
edition when it was still produced by midiman, not the anniversary
edition):
set_realtime_priority(SCHED_FIFO, 20).. done.
clock resolution: 0.000000001 s
latency distribution:
...
3.1 - 3.2 ms: 1 #
...
3.9 - 4.0 ms: 1 #
4.0 - 4.1 ms: 9903
################################################## ...
5.0 - 5.1 ms: 95 #
SUCCESS
best latency was 3.13 ms
worst latency was 5.00 ms, which is great.
This is a vanilla 2.6.34 kernel, no realtime patches, no nothing.
adi@hex:~$ cat /proc/asound/timers
G0: system timer : 4000.000us (10000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-1-0: PCM playback 0-1-0 : SLAVE
P0-1-1: PCM capture 0-1-1 : SLAVE
P0-2-1: PCM capture 0-2-1 : SLAVE
Not even HR timers. And yes, this is SMP, and yes, I have the "ondemand"
cpu governor, that is, the evil frequency scaling and the lot. Put
simply, it's a plain Debian unstable system, no latency tuning at all.
Ok, 4ms are not strikingly fast, but it's acceptable and shouldn't
matter in praxis. Especially I don't see any noteworthy jitter.
I'm going to measure the mainline kernels from 2.6.26 to 2.6.34 within
the next days to see if this stability can be accounted to the parts of
the RT patch that have been integrated into mainline.
If this hypothesis is correct, I should see a lot of jitter with older
kernels.
I'll also try to compare it against an onboard MPU-401, a firewire based
device and one or two more USB solutions.
Long story short: Seems things are not black (USB) and white (PCI). regarding to high and low? Of course without using this
box, because it
won't work, I'm thinking of connecting the IOs of the USB MIDI and
running the ALSA latency test.
Which, because there is the 10ms worst case latency of USB inherent in the
standards and connection, will probably show worst cases of at least that.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Save energy: Drive a smaller shell.
5287
days inactive
5308
days old
linux-audio-dev@lists.linuxaudio.org
38 comments
7 participants
participants (7)
-
Adrian Knoth -
Clemens Ladisch -
fons＠kokkinizita.net -
Gene Heskett -
Niels Mayer -
Paul Davis -
Ralf Mardorf