24 Sep
2009
24 Sep
'09
9:57 a.m.
Greetings,
I've been experimenting with MIDI control from one machine to another. I
checked the timing of a single note played simultanesouly by instances
of QSynth on both machines and was surprised to hear a very noticeable
flamming. I then replaced the MidiSport 2x2 with my Edirol UA25 and the
flamming disappeared. Both are USB interfaces, btw. MIDI routing between
the machines is handled by a Yamaha MJC8 and has never been problematic
with that box.
So, my question(s): Is the MidiSport just poorly designed and is there a
further condition or module option that can correct the timing delay
from that unit ?
Best,
dp
24 Sep
24 Sep
10:09 a.m.
Dave Phillips wrote:
Greetings,
I've been experimenting with MIDI control from one machine to another. I
checked the timing of a single note played simultanesouly by instances
of QSynth on both machines and was surprised to hear a very noticeable
flamming. I then replaced the MidiSport 2x2 with my Edirol UA25 and the
flamming disappeared. Both are USB interfaces, btw. MIDI routing between
the machines is handled by a Yamaha MJC8 and has never been problematic
with that box.
So, my question(s): Is the MidiSport just poorly designed and is there a
further condition or module option that can correct the timing delay
from that unit ?
Best,
dp
Very interesting!
Are you sure that it is just delay? I've got disastrous jitter with my
Swissonic USB device. I would be happy if it's caused by the Swissonic
device. I couldn't check if MIDI would have no jitter when I use the MPU
of the Envy24 of my TerraTec EWX 24/96 sound card, all circuits I tried
on a BreadBoard failed and I also didn't test any other interface.
For me it's good news that one of your USB devices fails, while the
other is fine ;). It gives me hope that just the Swissonic USB device is
bad.
Cheers,
Ralf
12:19 p.m.
Dave Phillips wrote:
I've been experimenting with MIDI control from one
machine to another. I
checked the timing of a single note played simultanesouly by instances
of QSynth on both machines and was surprised to hear a very noticeable
flamming. I then replaced the MidiSport 2x2 with my Edirol UA25 and the
flamming disappeared. Both are USB interfaces, btw. MIDI routing between
the machines is handled by a Yamaha MJC8 and has never been problematic
with that box.
So, my question(s): Is the MidiSport just poorly designed
Yes, having to load firmware is awful, but this should not affect
latency. :)
and is there a further condition or module option that
can correct the
timing delay from that unit ?
No.
It is possible that the devices have different buffer sizes, so that
sending multiple MIDI messages at once is more difficult. Have a look
at the respective values of wMaxPacketSize that are shown in the output
of "lsusb -v". Furthermore, the devices can have different internal
buffers.
Which interface did you use for sending/receiving?
Best regards,
Clemens
12:32 p.m.
Clemens Ladisch wrote:
Dave Phillips wrote:
Hi Clemens,
Thanks for the information. The report from lsusb indicated that these
values:
wMaxPacketSize 0x0020 1x 32 bytes
are the same for the MidiSport and the UA25. However, there's a lot of
information from that report. Is there any other particularly relevant
data I should gather from lsusb ?
Best,
dp
...
So, my question(s): Is the MidiSport just poorly designed
Yes, having to load firmware is awful, but this should not affect
latency. :)
and is there a further condition or module option
that can correct the
timing delay from that unit ?
No.
It is possible that the devices have different buffer sizes, so that
sending multiple MIDI messages at once is more difficult. Have a look
at the respective values of wMaxPacketSize that are shown in the output
of "lsusb -v". Furthermore, the devices can have different internal
buffers.
Which interface did you use for sending/receiving?
Best regards,
Clemens
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
1:03 p.m.
It is possible
that the devices have different buffer sizes, so that
sending multiple MIDI messages at once is more difficult. Have a look
at the respective values of wMaxPacketSize that are shown in the output
of "lsusb -v". Furthermore, the devices can have different internal
buffers.
Hi Clemens,
Thanks for the information. The report from lsusb indicated that these
values:
wMaxPacketSize 0x0020 1x 32 bytes
25 Sep
25 Sep
4:53 a.m.
Dave Phillips wrote:
wMaxPacketSize 0x0020 1x 32 bytes
are the same for the MidiSport and the UA25. However, there's a lot of
information from that report. Is there any other particularly relevant
data I should gather from lsusb ?
No, anything else wouldn't be visible in the descriptors.
It's possible that the MidiSport's firmware uses some stupid algorithm
that doesn't put multiple MIDI messages into one USB packet. In that
case, using the latest snd-usb-audio driver from ALSA 1.0.21 or the
upcoming 2.6.32 kernel might help.
Best regards,
Clemens
12:09 p.m.
Clemens Ladisch wrote:
Dave Phillips wrote:
I'm more inclined now to replace the MidiSport with another UA25. :)
Thanks for the help, Clemens, I might upgrade ALSA. If I do I'll send a
report.
Best,
dp
wMaxPacketSize 0x0020 1x 32 bytes
are the same for the MidiSport and the UA25. However, there's a lot of
information from that report. Is there any other particularly relevant
data I should gather from lsusb ?
No, anything else wouldn't be visible in the descriptors.
It's possible that the MidiSport's firmware uses some stupid algorithm
that doesn't put multiple MIDI messages into one USB packet. In that
case, using the latest snd-usb-audio driver from ALSA 1.0.21 or the
upcoming 2.6.32 kernel might help.
2:26 p.m.
On Friday, September 25, 2009, Clemens Ladisch wrote:
No, anything else wouldn't be visible in the
descriptors.
It's possible that the MidiSport's firmware uses some stupid algorithm
M-Audio MidiSport's firmware is closed source and proprietary. Hard to debug
if the problem is here.
OTOH, there was a GPL firmware for the MidiSport 2x2 and equivalent devices
(ezusbmidi). It has been abandoned, with the indiference of the Linux audio
community, but the sources should be somewhere in the attic.
Regards,
Pedro
24 Sep
24 Sep
1:16 p.m.
Dave Phillips wrote:
Which interface did you use for sending/receiving?
And which USB device is head of the USB devices? Did you change the
ports or did you edit /etc/default/rtirq?
RTIRQ_NAME_LIST="rtc snd usb3 i8042" You can make a special port head of
the USB ports by adding the number of the port.
25 Sep
25 Sep
5:53 p.m.
I ran into a benchmark tool at http://github.com/koppi/alsa-midi-latency-test/
and ran it though my MidiSport 2x2 Anniversary Edition (no firmware upload
required :) ) and Edirol UA-25EX.
Attached are the results on an untuned Debian Testing machine (2.6.30-1-686)
started with 'chrt -f 50 ./src/alsa-midi-latency-test -s 40'
The Edirol sure outperformed the MidiSport - the difference didn't seem huge
though.
(at the time of writing you need to add some symlinks to
/usr/share/automake-1.10/... to make it build right, mailed the author about
that already).
Regards,
Arnout
On Thu, Sep 24, 2009 at 07:56:22AM -0400, Dave Phillips wrote:
I've been experimenting with MIDI control from one
machine to another. I
checked the timing of a single note played simultanesouly by instances
of QSynth on both machines and was surprised to hear a very noticeable
flamming. I then replaced the MidiSport 2x2 with my Edirol UA25 and the
flamming disappeared. Both are USB interfaces, btw. MIDI routing between
the machines is handled by a Yamaha MJC8 and has never been problematic
with that box.
So, my question(s): Is the MidiSport just poorly designed and is there a
further condition or module option that can correct the timing delay
from that unit ?
Best,
dp
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
26 Sep
26 Sep
12:29 a.m.
On Fri, 2009-09-25 at 21:50 +0200, Arnout Engelen wrote:
Attached are the results on an untuned Debian Testing
machine (2.6.30-1-686)
started with 'chrt -f 50 ./src/alsa-midi-latency-test -s 40'
What do you mean by "untuned"? Is this without RT-patches?
The Edirol sure outperformed the MidiSport - the
difference didn't seem huge
though.
What I find most disturbing is the distribution, ranging from better
than perfect to on the edge of unusable. How much of this can be
attributed to the USB-stack?
/jma
7:35 a.m.
On Sat, Sep 26, 2009 at 04:28:42AM +0200, Jens M Andreasen wrote:
Anything I could try to isolate that?
Arnout
On Fri, 2009-09-25 at 21:50 +0200, Arnout Engelen
wrote:
This was without RT-patches. I now installed the 2.6.31-rt11-686-multimedia
from 64studio. Without any changes, this actually seemed to perform somewhat
poorer compared to the stock Debian one.
I did some tweaks:
- increased the rtprio for the USB IRQ handler
- decreased the 'latency_timer' value for my wireless network card and cardbus
slot
- tried to increase 'latency_timer' for the USB controller, but it remained
at 0 - i guess it doesn't support this option
After this, the performance is comparable.
Attached are the results on an untuned Debian
Testing machine (2.6.30-1-686)
started with 'chrt -f 50 ./src/alsa-midi-latency-test -s 40'
What do you mean by "untuned"? Is this without RT-patches? The Edirol
sure outperformed the MidiSport - the difference didn't seem huge
though.
What I find most disturbing is the distribution, ranging from better
than perfect to on the edge of unusable. How much of this can be
attributed to the USB-stack?
9:30 a.m.
Arnout Engelen wrote:
I did some tweaks:
- increased the rtprio for the USB IRQ handler
How can I do this? I only know how to make my Siwssonic USB MIDI device
head of the USB devices by Rui's rtirq.
Is there something I could change for rtirq, to get less jitter for the
USB MIDI device?
#!/bin/bash
#
# Copyright (c) 2004-2007 rncbc aka Rui Nuno Capela.
#
# /etc/default/rtirq
#
# Configuration for IRQ thread tunning,
# for realtime-preempt enabled kernels.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License version 2 or later.
#
# IRQ thread service names
# (space separated list, from higher to lower priority).
# DEFAULT:
# RTIRQ_NAME_LIST="rtc snd usb i8042"
# EDITED TO:
RTIRQ_NAME_LIST="rtc snd usb3 i8042"
# Highest priority.
RTIRQ_PRIO_HIGH=90
# Priority decrease step.
RTIRQ_PRIO_DECR=5
# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0
# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc snd"
# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="softirq-timer"
- decreased the 'latency_timer' value for my
wireless network card and cardbus
slot
- tried to increase 'latency_timer' for the USB controller, but it remained
at 0 - i guess it doesn't support this option
*?*
Ralf
10:10 a.m.
On Sat, Sep 26, 2009 at 01:29:53PM +0200, Ralf Mardorf wrote:
http://irc.esben-stien.name/mediawiki/index.php/Setting_Up_Real_Time_Operat…
Arnout
Arnout Engelen wrote:
I haven't looked into rtirq yet (I really should), but if I understand
correctly rtirq does automatically what I did manually: find out which IRQ
the device you're interested in is connected to, and give that IRQ a
higher rtprio.
To see the current rtprio's of your IRQ's, do:
ps axHo user,lwp,pid,rtprio,ni,command | grep irq
To increase the rtprio of some irq manually:
chrt -f -p <prio> <pid>
- increased the rtprio for the USB IRQ handler
How can I do this? I only know how to make my Siwssonic USB MIDI device
head of the USB devices by Rui's rtirq.
Is there something I could change for rtirq, to get less jitter for the
USB MIDI device? - decreased
the 'latency_timer' value for my wireless network card and cardbus
slot
- tried to increase 'latency_timer' for the USB controller, but it
remained at 0 - i guess it doesn't support this option
*?*
10:26 a.m.
Arnout Engelen wrote:
http://irc.esben-stien.name/mediawiki/index.php/Setting_Up_Real_Time_Operat…
Arnout
On Sat, Sep 26, 2009 at 01:29:53PM +0200, Ralf Mardorf
wrote:
Hi Arnout :)
or you simply change the USB ports ;).
Arnout Engelen wrote:
I haven't looked into rtirq yet (I really should) - increased the rtprio for the USB IRQ handler
How can I do this? I only know how to make my Siwssonic USB MIDI device
head of the USB devices by Rui's rtirq.
Is there something I could change for rtirq, to get less jitter for the
USB MIDI device?
, but if I understand
correctly rtirq does automatically what I did manually: find out which IRQ
the device you're interested in is connected to, and give that IRQ a
higher rtprio.
To see the current rtprio's of your IRQ's, do:
ps axHo user,lwp,pid,rtprio,ni,command | grep irq
To increase the rtprio of some irq manually:
chrt -f -p <prio> <pid>
Thank you :).
Ralf
- decreased the 'latency_timer' value for my
wireless network card and cardbus
slot
- tried to increase 'latency_timer' for the USB controller, but it
remained at 0 - i guess it doesn't support this option
*?*
3:46 p.m.
New subject: rtirq - previously Re: MidiSport vs. UA25
Arnout Engelen wrote:
I haven't looked into rtirq yet (I really should),
but if I understand
correctly rtirq does automatically what I did manually: find out which IRQ
the device you're interested in is connected to, and give that IRQ a
higher rtprio.
To see the current rtprio's of your IRQ's, do:
ps axHo user,lwp,pid,rtprio,ni,command | grep irq
To increase the rtprio of some irq manually:
chrt -f -p <prio> <pid>
This is from my rtirq: "RTIRQ_NAME_LIST="rtc snd usb3 i8042"" RTC
seems
to be IRQ-8, the sound card is IRQ-21 and the USB MIDI device is IRQ-17.
Why are there IRQ-1 and IRQ-12 having higher rtprio than USB?
Is "usb3" for rtirq correct for "SysFS ID: /devices/[snip]/usb2/[snip]?
There seems to be no usb0, that's why I guess it's wrong, but I guess
Rui once has written "usb3".
Is there a reason not to give usb3 a higher rtprio than snd, at least
when I only need a sequencer?
How can I see which devices do use what IRQ? Perhaps IRQ-17 is used by
other devices too.
$ ps axHo user,lwp,pid,rtprio,ni,command | grep IRQ
root 104 104 50 - [IRQ-9]
root 402 402 74 - [IRQ-12]
root 403 403 75 - [IRQ-1]
root 411 411 90 - [IRQ-8]
root 971 971 50 - [IRQ-16]
root 992 992 50 - [IRQ-17] *USB MIDI device*
root 1021 1021 80 - [IRQ-19]
root 1028 1028 50 - [IRQ-22]
root 1383 1383 50 - [IRQ-18]
root 1521 1521 50 - [IRQ-14]
root 2082 2082 50 - [IRQ-7]
root 2101 2101 50 - [IRQ-25]
root 2369 2369 85 - [IRQ-21] *Sound card*
root 4302 4302 50 - [IRQ-4]
1000 14174 14174 - 0 grep IRQ
------------------------------------------------------------------------
*Only Swissonic MIDI USB device is connected*
$ hwinfo --usb
01: USB 00.0: 10a00 Hub
[snip]
02: USB 00.0: 10a00 Hub
[snip]
03: USB 00.0: 10a00 Hub
[snip]
04: USB 00.0: 0000 Unclassified device
[Created at usb.122]
UDI: /org/freedesktop/Hal/devices/usb_device_170b_11_noserial_if0
Unique ID: FKGF.HOkU9LTmHW8
Parent ID: pBe4.PaupGMfzSp8
SysFS ID: /devices/pci0000:00/0000:00:13.1/usb2/2-1/2-1:1.0
SysFS BusID: 2-1:1.0
Hardware Class: unknown
Model: "Unclassified device"
Hotplug: USB
Vendor: usb 0x170b
Device: usb 0x0011
Revision: "0.01"
Driver: "snd-usb-audio"
Driver Modules: "snd_usb_audio"
Speed: 12 Mbps
Module Alias: "usb:v170Bp0011d0001dc00dsc00dp00ic01isc03ip00"
Driver Info #0:
Driver Status: snd_usb_audio is active
Driver Activation Cmd: "modprobe snd_usb_audio"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #6 (Hub)
05: USB 00.0: 10a00 Hub
[snip]
06: USB 00.0: 10a00 Hub
[snip]
07: USB 00.0: 10a00 Hub
[snip]
hwinfo --usb-ctrl
[snip]
24: PCI 13.1: 0c03 USB Controller (OHCI)
[Created at pci.296]
UDI: /org/freedesktop/Hal/devices/pci_1002_4388
Unique ID: 9n5e.Z94ELKUtK5C
SysFS ID: /devices/pci0000:00/0000:00:13.1
SysFS BusID: 0000:00:13.1
Hardware Class: usb controller
Model: "ASUSTeK USB Controller"
Vendor: pci 0x1002 "ATI Technologies Inc"
Device: pci 0x4388
SubVendor: pci 0x1043 "ASUSTeK Computer Inc."
SubDevice: pci 0x81ef
Driver: "ohci_hcd"
Driver Modules: "ohci_hcd"
Memory Range: 0xfe02d000-0xfe02dfff (rw,non-prefetchable)
IRQ: 17 (29 events)
Module Alias: "pci:v00001002d00004388sv00001043sd000081EFbc0Csc03i10"
Driver Info #0:
Driver Status: ohci-hcd is active
Driver Activation Cmd: "modprobe ohci-hcd"
Config Status: cfg=new, avail=yes, need=no, active=unknown
[snip]
------------------------------------------------------------------------
$ hwinfo --sound
09: PCI 306.0: 0401 Multimedia audio controller
[Created at pci.296]
UDI: /org/freedesktop/Hal/devices/pci_1412_1712
Unique ID: Kaa7.J4wu6rKmng4
Parent ID: qscc.ULOo3yhA66C
SysFS ID: /devices/pci0000:00/0000:00:14.4/0000:03:06.0
SysFS BusID: 0000:03:06.0
Hardware Class: sound
Model: "TERRATEC EWX 24/96"
Vendor: pci 0x1412 "VIA Technologies Inc."
Device: pci 0x1712 "ICE1712 [Envy24] PCI Multi-Channel I/O Controller"
SubVendor: pci 0x153b "TERRATEC Electronic GmbH"
SubDevice: pci 0x1130 "EWX 24/96"
Revision: 0x02
Driver: "ICE1712"
Driver Modules: "snd_ice1712"
I/O Ports: 0xcf00-0xcf1f (rw)
I/O Ports: 0xce00-0xce0f (rw)
I/O Ports: 0xcd00-0xcd0f (rw)
I/O Ports: 0xcc00-0xcc3f (rw)
IRQ: 21 (26376 events)
Module Alias: "pci:v00001412d00001712sv0000153Bsd00001130bc04sc01i00"
Driver Info #0:
Driver Status: snd_ice1712 is active
Driver Activation Cmd: "modprobe snd_ice1712"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #16 (PCI bridge)
5533
days inactive
5535
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
6 participants
participants (6)
-
Arnout Engelen -
Clemens Ladisch -
Dave Phillips -
Jens M Andreasen -
Pedro Lopez-Cabanillas -
Ralf Mardorf