Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   64 Studio User (http://www.linux-archive.org/64-studio-user/)
-   -   MIDI jitter (http://www.linux-archive.org/64-studio-user/387575-midi-jitter.html)

Ralf Mardorf 06-18-2010 09:36 AM

MIDI jitter
 
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.

IMO it's a good hint.

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? Does this regard to the
same issue, caused by the hardware combination?

And it's not only for Linux, but for e.g. Windows Cubase too, while
Cubase on the Atari is ok. OTOH on Windows audio clients don't
disconnect, just MIDI jitter is an issue too.

Cheers!

Ralf
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users

Ichthyostega 06-18-2010 10:18 PM

MIDI jitter
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwb8JgACgkQZbZrB6HelLKXxACfXMVLP9KDqq p+kdp5GXwZwAAP
1qQAoPy3ZX3inZsXIoDec6NR+NYrQ2GQ
=34JL
-----END PGP SIGNATURE-----
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users

Ralf Mardorf 06-19-2010 12:23 PM

MIDI jitter
 
Ichthyostega wrote:
> 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@alice-dsl.net>
To: fons@kokkinizita.net
CC: linux-audio-dev@lists.linuxaudio.org
References: <4BADBD42.4030505@alice-dsl.net> <20100327164326.GD1545@zita2>


> Hi Fons :)
>
> fons@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@alice-dsl.net>
To: Linux Audio Developers <linux-audio-dev@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
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.
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users

Ralf Mardorf 06-19-2010 02:16 PM

MIDI jitter
 
Hi Gene :)

Gene Heskett wrote:
> 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:
>>
>>> 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 ...
>>
>
> 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.
>

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.

>> 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@alice-dsl.net>
>> To: fons@kokkinizita.net
>> CC: linux-audio-dev@lists.linuxaudio.org
>> References: <4BADBD42.4030505@alice-dsl.net>
>> <20100327164326.GD1545@zita2>
>>
>>
>>> Hi Fons :)
>>>
>>> fons@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@alice-dsl.net>
>> To: Linux Audio Developers <linux-audio-dev@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.
>>
>
> Which could be an interaction with the rtai kernel.
>

Of course, the rtai seems not to be made for audio.

>> 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.
>

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.

>> 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.
>

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
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users

Ralf Mardorf 06-19-2010 03:35 PM

MIDI jitter
 
Gene Heskett wrote:
> On Saturday 19 June 2010, Ralf Mardorf wrote:
>
>> 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?
>>
>
>
> 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
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users

Ralf Mardorf 07-01-2010 08:22 AM

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:
>
> > 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).

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.

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

Ralf Mardorf 07-01-2010 08:28 AM

MIDI jitter
 
On Wed, 2010-06-30 at 14:48 +0200, fons@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.

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

Ralf Mardorf 07-06-2010 12:06 PM

MIDI jitter
 
On Tue, 2010-07-06 at 10:57 +0100, Daniel James wrote:
[snip]
> I notice
> http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_steadyclock
> doesn't mention USB or MIDI at all.
>
> Cheers!
>
> Daniel

Hi all :) hi Daniel :)

I'll read this link tomorrow, I just did a short test, right after the
postman did give me the ordered equipment. Please take a look at all the
tests I did here.

The Terratec's MIDI might be ok, but ...

spinymouse11.2@suse11-2:~> cat .alias
alias cpu-o="su -c"cpufreq-set -gondemand""
alias cpu-p="su -c"cpufreq-set -gperformance""
spinymouse11.2@suse11-2:~> cpu-p
Password:
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
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 -i16:0 -o16:0
> SUCCESS

best latency was 0.98 ms
worst latency was 1.42 ms, which is great.

spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i16:0 -o16:0
> SUCCESS

best latency was 0.99 ms
worst latency was 1.11 ms, which is great.

Then I run glxgears and Firefox with windows always on top and moved the
Firefox window while running the tests.

spinymouse11.2@suse11-2:~> alsa-midi-latency-test -i16:0 -o16:0
> SUCCESS

best latency was 0.98 ms
worst latency was 4.15 ms, which is great.

spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i16:0 -o16:0
> SUCCESS

best latency was 0.99 ms
worst latency was 1.11 ms, which is great.

Then I tested if the hrtimer might change something, I dunno if the test
will use it automatically.

spinymouse11.2@suse11-2:~> su
Password:
suse11-2:/home/spinymouse11.2 # chgrp audio /dev/hpet
suse11-2:/home/spinymouse11.2 # sysctl -w dev.hpet.max-user-freq=64
dev.hpet.max-user-freq = 64
suse11-2:/home/spinymouse11.2 # modprobe snd-hrtimer
suse11-2:/home/spinymouse11.2 # cat /proc/sys/dev/hpet/max-user-freq
64
suse11-2:/home/spinymouse11.2 # exit

Firefox and glxgears still on top of the windows and I moved the Firefox
windows again during the test.

Note that I now used the -R switch for both tests.

pinymouse11.2@suse11-2:~> alsa-midi-latency-test -Ri16:0 -o16:0
> SUCCESS

best latency was 0.99 ms
worst latency was 1.08 ms, which is great.

spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i16:0 -o16:0
> SUCCESS

best latency was 0.99 ms
worst latency was 1.12 ms, which is great.

Just for comparison one test for the Swissonic USB MIDI device, without
running glxgears or Firefox or moving any window. HPET still enabled.

spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i20:0 -o20:0
> SUCCESS

best latency was 1.17 ms
worst latency was 2.23 ms, which is great.

Now a final comment to those tests.

When I used the USB MIDI device + HPET the audible result wasn't usable
for music, but I had the impression that half of the jitter would solve
this issue.
If the results of the test are correct and if nothing would change when
running JACK and doing hard disk recording too, then I guess the PCI
MIDI could be ok.

I don't have much time today, perhaps tonight or tomorrow I'll mount the
new HDD and restore my 64 Studio's. When it's done I'll record some
music and additionally I'll ask Achim, http://achimjaroschek.com/ , to
stress the computer by playing the Roland drums and some hardcore
Classic or hardcore Jazz on the keyboards.
It's not only that he plays with all those music giants like Jasper
van't Hof, Peter Brötzmann etc., but he once throw his Apple through the
window and he always advise me not to make music using the computer
anymore.

I've got a good feeling, that around 1ms (when the -R switch is set)
would be good enough to make music, but again, even if the test says
2.23 ms for the USB device should be great, the USB device is unusable
for serious musicians, it results in music that might be done by am
idiot without any sense for music.

I couldn't use the USB device + HPET even for the simple Pop-Rock I
sometimes make.

Cheers!

Ralf

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

Ralf Mardorf 07-06-2010 02:59 PM

MIDI jitter
 
On Tue, 2010-07-06 at 10:25 -0400, Paul Davis wrote:
> On Tue, Jul 6, 2010 at 8:06 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
> > I've got a good feeling, that around 1ms (when the -R switch is set)
> > would be good enough to make music, but again, even if the test says
> > 2.23 ms for the USB device should be great, the USB device is unusable
> > for serious musicians, it results in music that might be done by am
> > idiot without any sense for music.
>
> you write this as though its some kind of surprise.

Yes, I guess the PCI MIDI is good enough for my needs, but until I
didn't tested it by making music I'm sceptic. And I'm sceptic about 2.23
ms for USB too, anyway the PCI card is always around 1.1 ms, with or
without HPET, with glxgears and moving windows or without. The main
thing for me is that PCI has half of the USB latency for the test, if
this is a real value when JACK is running etc. is less important, as
long the factor between USB and PCI will be 2, 'half as much'. :)

I be hopeful that this issue for my machine is solved now, but until I
didn't recorded some music, I don't believe that it's solved and yes, I
was surprised even if by theory I shouldn't be surprised regarding to
the measured results.

- Ralf


_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

Ralf Mardorf 07-06-2010 03:20 PM

MIDI jitter
 
On Tue, 2010-07-06 at 10:25 -0400, Paul Davis wrote:
> On Tue, Jul 6, 2010 at 8:06 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
> > I've got a good feeling, that around 1ms (when the -R switch is set)
> > would be good enough to make music, but again, even if the test says
> > 2.23 ms for the USB device should be great, the USB device is unusable
> > for serious musicians, it results in music that might be done by am
> > idiot without any sense for music.
>
> you write this as though its some kind of surprise.

Perhaps the Dalai Lama's birthday has impact to prevent MIDI jitter, I
don't believe in esoteric, but I might be wrong ;D.

--
If somebody like to send him congratulations, here's a forum to do it
http://www.avaaz.org/en/ . Apart from the esoteric, that I don't like, I
guess he is an exemplary good politician.

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel


All times are GMT. The time now is 07:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.