I'm not forwarding every mail from LAD, but this one might be important
too. Run it with the -w and -r option, perhaps this might be the right
way to do it.
On Thu, Jul 01, 2010 at 07:43:38PM -0400, Paul Davis 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
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
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
07-04-2010, 04:53 AM
OK, I finally got my midisport 2x2 working (I also have a 1x but I do not
have the right cable or connector for it) and thus was able to compare the
results to the midi controller in my RME.
I have put the raw results below along with the command line I used. It
seems that there is an order of magnitude difference between the two.
Just like with audio interfaces in general, USB sucks (actually USB sucks
in general, it is just good enough for the tasks it is commonly used for).
Also note that I pasted the complete results from both tests (the RME test
produced significantly shorter output due to the tighter distribution of
results).
Both tests were completed on the same machine, one after the other.
The system is a now modest AMD 4400+ X2 (939 pin dual core @ 2.2Ghz) with
3 GiB of DDR RAM and an old and slow SATA drive (Seagate Barracuda 7200.8
family). The sound device is an RME 9652 PCI. The video device is an
ATI Radeon Xpress 200G Series integrated into the motherboard.
### First the RME results ###
$ alsa-midi-latency-test -i 16:0 -o 16:0 -w 20 -r
> alsa-midi-latency-test 0.0.3
> 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
best latency was 2.95 ms
worst latency was 34.96 ms, which is too much. Please check
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
07-04-2010, 06:14 AM
Ralf Mardorf
On Sat, 2010-07-03 at 22:53 -0600, gustin@echostar.ca wrote:
> ### First the RME results ###
> $ alsa-midi-latency-test -i 16:0 -o 16:0 -w 20 -r
> > SUCCESS
>
> best latency was 0.96 ms
> worst latency was 4.04 ms, which is great.
> ### Next are the midisport results ###
> $ alsa-midi-latency-test -i 28:1 -o 28:1 -w 20 -r
> > FAIL
>
> best latency was 2.95 ms
> worst latency was 34.96 ms, which is too much. Please check
Theoretically it could be, that the order of the tests had influenced
the tests. I will run my tests 3 or 4 times and in addition I will run
glxgears or a real benchmark test while running the ALSA MIDI latency
test, e.g.
"Real Benchmarks
All in one
* Phoronix Test Suite offers Unigine, Gtkperf, and a ton of other
tests all in one - [1]
OpenGL
* Unigine Sanctuary & Tropics Demos - [2]
GTK
* Gtkperf - offered by any major distribution's
repository." (http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark)
When we make music, we not only send and receive by the MIDI port while
just a little program is running. We also will have a sequencer GUI,
access to the hard disk drives, perhaps we run JAMin, it stress the
computer because of math.
OTOH I bet the the RME always would be ok, while the Midisport always
would fail, anyway the results might vary in value.
A drummer forum on German
http://www.drummerforum.de/forum/46746-midi-vorteile-bei-audiointerface-oder-pci-soundkarte-gegen%C3%BCber-midi-usb-interface.html ... one asked if the other one noticed the difference between audio latency and measured MIDI latency, while nobody asked for jitter. Anyway, most people seems to be non-gifted musicians and they don't hear jitter, while musicians seems to tend to say that PCI devices are more stable.
I guess it's the industry making propaganda for USB, when we read USB
should be the better choice, while musicians seem to experience that PCI
is the better choice, anyway, even PCI might not be good enough.
Cheers!
Ralf
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
07-05-2010, 08:15 AM
Ralf Mardorf
-------- Forwarded Message --------
From: Ralf Mardorf <ralf.mardorf@alice-dsl.net>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Linux Audio Developers <linux-audio-dev@lists.linuxaudio.org>
Subject: Re: [LAD] [64studio-users] MIDI jitter
Date: Mon, 05 Jul 2010 09:29:12 +0200
On Mon, 2010-07-05 at 09:16 +0200, Clemens Ladisch wrote:
> Niels Mayer wrote:
> > Here's the new results with "-w 20" (nb: "-w" == "-w 0")
> >
> >> A) Edirol UM-2
> >
> > best latency was 2.07 ms
> > worst latency was 3.11 ms, which is great.
>
> 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
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
_______________________________________________
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
07-05-2010, 08:15 AM
Ralf Mardorf
-------- Forwarded Message --------
From: Ralf Mardorf <ralf.mardorf@alice-dsl.net>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Linux Audio Developers <linux-audio-dev@lists.linuxaudio.org>
Subject: MIDI jitter - Today for 4 of 4 tests my USB device did pass all
tests with success
Date: Mon, 05 Jul 2010 10:14:21 +0200
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
------- Comment #4 from vapier@gentoo.org 2010-07-05 19:39 0000 -------
lemme clarify further: dont bother submitting ebuilds for any package in
OSS-QM. we arent interested.
--
Configure bugmail: https://bugs.gentoo.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
----- End forwarded message -----
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
07-05-2010, 11:29 PM
Enrico Weigelt
Hi folks,
does he speak for all of you ?
----- Forwarded message from bugzilla-daemon@gentoo.org -----
From: bugzilla-daemon@gentoo.org
Subject: [Bug 326991] Testing release of sys-libs/zlib-1.2.5.3 from unofficial sources (???)
To: weigelt@metux.de
Reply-To: DO NOT REPLY <devnull@localhost.invalid>
Date: Mon, 5 Jul 2010 19:39:48 +0000 (UTC)
DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
whose email is mentioned below. To comment on this bug, please visit:
------- Comment #4 from vapier@gentoo.org 2010-07-05 19:39 0000 -------
lemme clarify further: dont bother submitting ebuilds for any package in
OSS-QM. we arent interested.
--
Configure bugmail: https://bugs.gentoo.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
----- End forwarded message -----
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
07-05-2010, 11:29 PM
Enrico Weigelt
Hi folks,
does he speak for all of you ?
----- Forwarded message from bugzilla-daemon@gentoo.org -----
From: bugzilla-daemon@gentoo.org
Subject: [Bug 326991] Testing release of sys-libs/zlib-1.2.5.3 from unofficial sources (???)
To: weigelt@metux.de
Reply-To: DO NOT REPLY <devnull@localhost.invalid>
Date: Mon, 5 Jul 2010 19:39:48 +0000 (UTC)
DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
whose email is mentioned below. To comment on this bug, please visit:
------- Comment #4 from vapier@gentoo.org 2010-07-05 19:39 0000 -------
lemme clarify further: dont bother submitting ebuilds for any package in
OSS-QM. we arent interested.
--
Configure bugmail: https://bugs.gentoo.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
----- End forwarded message -----
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
07-05-2010, 11:43 PM
Albert Hopkins
On Tue, 2010-07-06 at 01:29 +0200, Enrico Weigelt wrote:
> Hi folks,
>
>
> does he speak for all of you ?
>