7 Sep
2009
7 Sep
'09
11:02 p.m.
Hi all,
I'm trying to get my usb midi keyboard (an edirol PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
The OS is debian testing at the moment, but I have had the same problem
on this laptop with both ubuntu jaunty and a fairly recent version of
linux mint.
Does anyone have any idea what might be happening, or what I can do to
narrow down the cause of the problem a bit further?
My /proc/interrupts, lsusb, and lspci are pasted below.
Cheers,
andy baxter
andy@monkey:~$ cat /proc/interrupts
CPU0 CPU1
0: 1207873 1669765 IO-APIC-edge timer
1: 2473 1983 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc0
9: 19517 11123 IO-APIC-fasteoi acpi
12: 25255 22957 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge ide0
16: 380396 233180 IO-APIC-fasteoi uhci_hcd:usb4, yenta
17: 829711 532117 IO-APIC-fasteoi uhci_hcd:usb5, ohci1394,
HDA Intel
18: 0 0 IO-APIC-fasteoi mmc0
19: 2 0 IO-APIC-fasteoi ehci_hcd:usb6
20: 18 17 IO-APIC-fasteoi uhci_hcd:usb1
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 305246 302929 IO-APIC-fasteoi ehci_hcd:usb3
220: 8566 7543 PCI-MSI-edge eth0
221: 27049 24430 PCI-MSI-edge ahci
NMI: 0 0 Non-maskable interrupts
LOC: 426040 660568 Local timer interrupts
RES: 2036860 2297232 Rescheduling interrupts
CAL: 7278 7718 function call interrupts
TLB: 14422 14326 TLB shootdowns
TRM: 0 0 Thermal event interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
MIS: 0
andy@monkey:~$ lsusb
Bus 001 Device 003: ID 0483:2016 SGS Thomson Microelectronics
Fingerprint Reader
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0582:0033 Roland Corp. EDIROL PCR
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 07ab:fcdf Freecom Technologies
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
andy@monkey:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network
Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #2 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface
Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller
(rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or
AGN [Kedron] Network Connection (rev 61)
05:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
05:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
(rev 04)
05:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter (rev 21)
8 Sep
8 Sep
12:20 a.m.
On Tue, Sep 08, 2009 at 02:02:01AM +0100, andy baxter wrote:
I'm trying to get my usb midi keyboard (an edirol
PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
The path from your fingers to your ears is a long one, with many
dependencies, so I'd check each part of the path. A useful method is
bisection.
The path is this;
- fingers,
- keyboard, (Edirol PCR 800),
- USB controller,
- interrupts,
- processor,
- USB controller driver,
- USB MIDI driver,
- ALSA MIDI output,
- qsynth (fluidsynth),
- JACK audio,
- ALSA HDA driver,
- Intel HDA hardware.
Ideally, you'd like to know where the delay begins. Based on your
description of the problem, the delay begins somewhere between the
fingers and qsynth, or in qsynth itself. If it began after qsynth you'd
notice gaps in the audio of notes.
So we can probably exclude the audio path and concentrate on the MIDI
path.
What I'd like you to do is probe at the point just before qsynth, and
see if the MIDI key down events are arriving delayed.
There's several ways of doing this, but I guess two of the simplest are
to;
1. use arecordmidi to capture the events and see if they are delayed,
or;
2. use a software virtual keyboard to inject events into qsynth, and
see if you get the same occasional delays.
Now, what if it is qsynth? fluidsynth will read the entire soundfont
into memory before synthesis begins, and then lock down the memory to
prevent it from being paged out due to other processes' demands. This
locking of memory might fail transparently due to process limits. A
method I use to check for this is to run qsynth as root. You didn't
mention if you do this, so it might be something to try.
Given you have a working system and a non-working system, another thing
you can do is a recursive diff of the /etc trees on each, to look for
any configuration changes you may have made.
--
James Cameron
http://quozl.linux.org.au/
5 a.m.
James Cameron wrote:
On Tue, Sep 08, 2009 at 02:02:01AM +0100, andy baxter
wrote:
Thanks. I had a look at the qsynth settings and found that the sample
rate, buffer size, and buffer count were different from that set in
qjackctl, (also it was using 16 bit samples instead of floats). Changing
all these to the same as jackd seems to have improved the situation, but
not completely cured the problem as far as I can tell. There still seems
to be a very slight delay between hitting the key and hearing a note,
but it's smaller and more consistent than before. It's getting to the
point though that it's hard to tell whether the delay is there or not.
I'll try what you suggested to see if I can improve things a bit more.
Cheers,
andy
I'm trying to get my usb midi keyboard (an
edirol PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
The path from your fingers to your ears is a long one, with many
dependencies, so I'd check each part of the path. A useful method is
bisection.
The path is this;
- fingers,
- keyboard, (Edirol PCR 800),
- USB controller,
- interrupts,
- processor,
- USB controller driver,
- USB MIDI driver,
- ALSA MIDI output,
- qsynth (fluidsynth),
- JACK audio,
- ALSA HDA driver,
- Intel HDA hardware.
Ideally, you'd like to know where the delay begins. Based on your
description of the problem, the delay begins somewhere between the
fingers and qsynth, or in qsynth itself. If it began after qsynth you'd
notice gaps in the audio of notes.
So we can probably exclude the audio path and concentrate on the MIDI
path.
What I'd like you to do is probe at the point just before qsynth, and
see if the MIDI key down events are arriving delayed.
There's several ways of doing this, but I guess two of the simplest are
to;
1. use arecordmidi to capture the events and see if they are delayed,
or;
2. use a software virtual keyboard to inject events into qsynth, and
see if you get the same occasional delays.
Now, what if it is qsynth? fluidsynth will read the entire soundfont
into memory before synthesis begins, and then lock down the memory to
prevent it from being paged out due to other processes' demands. This
locking of memory might fail transparently due to process limits. A
method I use to check for this is to run qsynth as root. You didn't
mention if you do this, so it might be something to try.
Given you have a working system and a non-working system, another thing
you can do is a recursive diff of the /etc trees on each, to look for
any configuration changes you may have made.
7:17 a.m.
andy baxter wrote:
Hi all,
I'm trying to get my usb midi keyboard (an edirol PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
OK, I have tried the following:
- using a program which turns the computer keyboard into a virtual midi
device. This makes the sound much more immediate. Having tried this, the
contrast makes it obvious that there is still a problem with delays from
the edirol keyboard.
- running qsynth using the alsa driver. No difference - when I play from
the edirol keyboard there are still noticeable and annoying delays.
- running qsynth as root (using alsa). Again no difference.
- using zynaddsubfx instead of qsynth (again with alsa). Again, there
are noticeable delays.
This makes me think that the problem is to do with the usb midi driver
or the usb hardware on my new laptop - maybe an interrupts issue? I'm
not sure how to get round this though. I'm wondering if getting a
cardbus usb adapter would help?
andy
7:54 a.m.
On Tue, Sep 08, 2009 at 10:14:24AM +0100, andy baxter wrote:
- using a program which turns the computer keyboard
into a virtual midi
device. This makes the sound much more immediate. Having tried this, the
contrast makes it obvious that there is still a problem with delays from
the edirol keyboard.
Interesting. Let's consider that data path further.
1. flow from keyboard USB device to USB controller,
2. an interrupt,
3. flow from USB controller to processor.
Perhaps another device on the system is preventing the USB interrupt
from being processed in a timely fashion. See if you can quieten
devices one by one and see if the problem changes. For example you can
quieten a graphics driver by switching to the text console and then
resume playing the MIDI keyboard.
General suggestions for a USB flow rate problem ... try different USB
sockets, remove as many USB devices as possible, ensure the cable is
as short as possible, ensure the cable is standards compliant, and if
there is a way to power the device differently (e.g. a DC input socket),
then try it. I've even had particularly strange devices behave better
on a powered hub.
Your lsusb shows the device is attached to a USB 1.1 hub. There is a
Freecom Technologies device attached to a USB 2.0 hub. This might be
because the keyboard is only USB 1.1 complaint, I don't know.
Watch /proc/interrupts while trying to play, and see what counters
increment in the matrix. Here's a fun way ... run this in a terminal
window while playing keys on the MIDI keyboard ...
watch -d --interval=0.1 cat /proc/interrupts
What is the kernel version? You mentioned Debian Testing and Ubuntu
Jaunty.
I've looked at the 2.6.30 sources (latest stable), and the USB device
you showed us in lspci "0582:0033 Roland Corp. EDIROL PCR" is listed in
sound/usb/usbmidi.c and also in sound/usb/usbquirks.h . There was
nothing funny about the quirks.
I've looked at the Ubuntu Jaunty 2.6.28 sources, and usbquirks.h for
this device is no different. usbmidi.c *does* have differences, in that
there have been several fixes in 2.6.30 that might be relevant. Nothing
about the changes looked like an exact match to your problem, but that
could be my inexperience.
I suggest you try downloading and booting from the Ubuntu Karmic Alpha
CD images that are available now. The newer kernel in those images may
change the timing problem for you.
--
James Cameron
http://quozl.linux.org.au/
11:48 a.m.
James Cameron wrote:
On Tue, Sep 08, 2009 at 10:14:24AM +0100, andy baxter
wrote:
I'm using a hand compiled kernel under debian testing - 2.6.26.8 with
the rt16 patch. I also tried a 2.6.29 kernel with rt23, but this didn't
work. (May have been my mistake but I ended up with a problem with
repeating keys and also the jack daemon wouldn't start properly.)
Will try what you've suggested and let you know how it goes.
Many thanks for the time you've spent looking into this.
cheers,
andy
- using a program which turns the computer
keyboard into a virtual midi
device. This makes the sound much more immediate. Having tried this, the
contrast makes it obvious that there is still a problem with delays from
the edirol keyboard.
...
Watch /proc/interrupts while trying to play, and see what counters
increment in the matrix. Here's a fun way ... run this in a terminal
window while playing keys on the MIDI keyboard ...
watch -d --interval=0.1 cat /proc/interrupts
What is the kernel version? You mentioned Debian Testing and Ubuntu
Jaunty.
12:14 p.m.
On Tue, 08 Sep 2009 14:48:27 +0100
andy baxter <andy(a)earthsong.free-online.co.uk> wrote:
James Cameron wrote:
He, so I was not the only one who got the repeating key problems with
2.6.29-rt. I think I had other issues as well.
Now if only 2.6.31-rt was out already :)
I use a keyboard with midi over usb and the output is over a usb
interface, yet I haven't noticed any annoying delay. At the moment jack
is set to 16ms, which of course is more when you measure it, especially
with usb.
But besides saying that it should work I can't really help you :/
Regards,
Philipp
On Tue, Sep 08, 2009 at 10:14:24AM +0100, andy
baxter wrote:
I'm using a hand compiled kernel under debian testing - 2.6.26.8 with
the rt16 patch. I also tried a 2.6.29 kernel with rt23, but this
didn't work. (May have been my mistake but I ended up with a problem
with repeating keys and also the jack daemon wouldn't start properly.)
Will try what you've suggested and let you know how it goes.
Many thanks for the time you've spent looking into this.
cheers,
andy - using a program which turns the computer
keyboard into a virtual
midi device. This makes the sound much more immediate. Having
tried this, the contrast makes it obvious that there is still a
problem with delays from the edirol keyboard.
...
Watch /proc/interrupts while trying to play, and see what counters
increment in the matrix. Here's a fun way ... run this in a
terminal window while playing keys on the MIDI keyboard ...
watch -d --interval=0.1 cat /proc/interrupts
What is the kernel version? You mentioned Debian Testing and Ubuntu
Jaunty.
1:20 p.m.
hollunder(a)gmx.at wrote:
On Tue, 08 Sep 2009 14:48:27 +0100
andy baxter <andy(a)earthsong.free-online.co.uk> wrote:
I also had a problem with the xserver crashing and behaving oddly with
the intel driver, which was only curable by switching to the vesa driver.
James Cameron wrote:
He, so I was not the only one who got the repeating key problems with
2.6.29-rt. I think I had other issues as well.
Now if only 2.6.31-rt was out already :)
On Tue, Sep 08, 2009 at 10:14:24AM +0100, andy
baxter wrote:
I'm using a hand compiled kernel under debian testing - 2.6.26.8 with
the rt16 patch. I also tried a 2.6.29 kernel with rt23, but this
didn't work. (May have been my mistake but I ended up with a problem
with repeating keys and also the jack daemon wouldn't start properly.)
Will try what you've suggested and let you know how it goes.
Many thanks for the time you've spent looking into this.
cheers,
andy
- using a program which turns the computer
keyboard into a virtual
midi device. This makes the sound much more immediate. Having
tried this, the contrast makes it obvious that there is still a
problem with delays from the edirol keyboard.
...
Watch /proc/interrupts while trying to play, and see what counters
increment in the matrix. Here's a fun way ... run this in a
terminal window while playing keys on the MIDI keyboard ...
watch -d --interval=0.1 cat /proc/interrupts
What is the kernel version? You mentioned Debian Testing and Ubuntu
Jaunty.
I use a keyboard with midi over usb and the output is
over a usb
interface, yet I haven't noticed any annoying delay. At the moment jack
is set to 16ms, which of course is more when you measure it, especially
with usb.
What distro and kernel are you using? If all else fails I'll maybe copy
your setup.
andy
2:54 p.m.
James Cameron wrote:
On Tue, Sep 08, 2009 at 10:14:24AM +0100, andy baxter
wrote:
I've tried running qsynth and jackd from the console with no x session
running, and this still doesn't cure the problem. Neither does bringing
down the network interface.
- using a program which turns the computer
keyboard into a virtual midi
device. This makes the sound much more immediate. Having tried this, the
contrast makes it obvious that there is still a problem with delays from
the edirol keyboard.
Interesting. Let's consider that data path further.
1. flow from keyboard USB device to USB controller,
2. an interrupt,
3. flow from USB controller to processor.
Perhaps another device on the system is preventing the USB interrupt
from being processed in a timely fashion. See if you can quieten
devices one by one and see if the problem changes. For example you can
quieten a graphics driver by switching to the text console and then
resume playing the MIDI keyboard.
General suggestions for a USB flow rate problem ...
try different USB
sockets, remove as many USB devices as possible, ensure the cable is
as short as possible, ensure the cable is standards compliant, and if
there is a way to power the device differently (e.g. a DC input socket),
then try it. I've even had particularly strange devices behave better
on a powered hub.
OK. DC power is tricky for me but could try it. I've tried all the
sockets and it makes little or no difference.
Your lsusb shows the device is attached to a USB 1.1
hub. There is a
Freecom Technologies device attached to a USB 2.0 hub. This might be
because the keyboard is only USB 1.1 complaint, I don't know.
Watch /proc/interrupts while trying to play, and see what counters
increment in the matrix. Here's a fun way ... run this in a terminal
window while playing keys on the MIDI keyboard ...
watch -d --interval=0.1 cat /proc/interrupts
I've tried this (nice trick!). It's hard to get precise numbers, but
roughly the interrupt rates are:
int 0 - timer - 700-1000 per sec.
int 17 - sound card - 300-500 per sec.
int 21 - edirol keyboard usb hub - 30-50 per sec.
LOC - local timer - 150-200 per sec.
RES - Rescheduling interrupts - 1000-1500 per sec.
What is the kernel version? You mentioned Debian
Testing and Ubuntu
Jaunty.
2.6.26.8-rt16 on debian testing.
I've looked at the 2.6.30 sources (latest stable),
and the USB device
you showed us in lspci "0582:0033 Roland Corp. EDIROL PCR" is listed in
sound/usb/usbmidi.c and also in sound/usb/usbquirks.h . There was
nothing funny about the quirks.
I've looked at the Ubuntu Jaunty 2.6.28 sources, and usbquirks.h for
this device is no different. usbmidi.c *does* have differences, in that
there have been several fixes in 2.6.30 that might be relevant. Nothing
about the changes looked like an exact match to your problem, but that
could be my inexperience.
I suggest you try downloading and booting from the Ubuntu Karmic Alpha
CD images that are available now. The newer kernel in those images may
change the timing problem for you.
OK will give this a try at some point.
Cheers for the help.
andy
5:14 p.m.
On Tue, 08 Sep 2009 17:10:57 +0100
andy baxter <andy(a)earthsong.free-online.co.uk> wrote:
Rui mentioned in a previous mail that 2.6.26-rt has issues with midi,
so maybe try another kernel? I just heard that 2.6.24 is good.
I haven't tried it myself yet and would also like to have a more recent
one, but if it works..
Regards,
Philipp
What is the
kernel version? You mentioned Debian Testing and Ubuntu
Jaunty.
2.6.26.8-rt16 on debian testing. 
4:30 p.m.
James Cameron wrote:
General suggestions for a USB flow rate problem ...
try different USB
sockets, remove as many USB devices as possible, ensure the cable is
as short as possible, ensure the cable is standards compliant, and if
there is a way to power the device differently (e.g. a DC input socket),
then try it. I've even had particularly strange devices behave better
on a powered hub.
Connect your USB<>MIDI interface directly to your computer, not through
an external USB hub. I have an external USB soundcard; when connected
via my external 7-port hub, audio I/O skips in both directions.
Connecting directly fixed it.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
4:38 p.m.
david wrote:
James Cameron wrote:
It's already plugged directly into one of the laptop's usb ports.
I've
also tried using different ports, but that doesn't seem to make much
difference.
andy
General suggestions for a USB flow rate problem
... try different USB
sockets, remove as many USB devices as possible, ensure the cable is
as short as possible, ensure the cable is standards compliant, and if
there is a way to power the device differently (e.g. a DC input socket),
then try it. I've even had particularly strange devices behave better
on a powered hub.
Connect your USB<>MIDI interface directly to your computer, not through
an external USB hub. I have an external USB soundcard; when connected
via my external 7-port hub, audio I/O skips in both directions.
Connecting directly fixed it.
4:59 p.m.
andy baxter a écrit :
It's already plugged directly into one of the laptop's usb ports. I've
also tried using different ports, but that doesn't seem to make much
difference.
andy
Just an idea. May be the story with nrpacks.
You use snd-usb-audio, right?
modprobe snd-usb-audio nrpacks=1
May be i'm completely wrong.
--
Phil.
5:06 p.m.
Philippe Hezaine wrote:
andy baxter a écrit :
It's already plugged directly into one of the laptop's usb ports.
I've
also tried using different ports, but that doesn't seem to make much
difference.
andy
Just an idea. May be the story with nrpacks.
You use snd-usb-audio, right?
modprobe snd-usb-audio nrpacks=1
May be i'm completely wrong.
Thanks, but this doesn't help either. :-/
9 Sep
9 Sep
3:18 a.m.
Philippe Hezaine wrote:
andy baxter a écrit :
It's already plugged directly into one of the laptop's usb ports. I've
also tried using different ports, but that doesn't seem to make much
difference.
andy
Just an idea. May be the story with nrpacks.
You use snd-usb-audio, right?
modprobe snd-usb-audio nrpacks=1
May be i'm completely wrong.
Hmm, what is "nrpacks"?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
3:17 a.m.
andy baxter wrote:
david wrote:
USB not sharing interrupts with anything?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
James Cameron wrote:
It's already plugged directly into one of the laptop's usb ports.
I've
also tried using different ports, but that doesn't seem to make much
difference. General suggestions for a USB flow rate problem
... try different USB
sockets, remove as many USB devices as possible, ensure the cable is
as short as possible, ensure the cable is standards compliant, and if
there is a way to power the device differently (e.g. a DC input socket),
then try it. I've even had particularly strange devices behave better
on a powered hub.
Connect your USB<>MIDI interface directly to your computer, not
through an external USB hub. I have an external USB soundcard; when
connected via my external 7-port hub, audio I/O skips in both
directions. Connecting directly fixed it.
3:25 a.m.
On Tue, Sep 08, 2009 at 07:17:30PM -1000, david wrote:
USB not sharing interrupts with anything?
Andy's original post contained /proc/interrupts which showed some
sharing was happening. Here's a cut:
16: 380396 233180 IO-APIC-fasteoi uhci_hcd:usb4, yenta
17: 829711 532117 IO-APIC-fasteoi uhci_hcd:usb5, ohci1394, HDA Intel
18: 0 0 IO-APIC-fasteoi mmc0
19: 2 0 IO-APIC-fasteoi ehci_hcd:usb6
20: 18 17 IO-APIC-fasteoi uhci_hcd:usb1
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 305246 302929 IO-APIC-fasteoi ehci_hcd:usb3
Sharing interrupts adds a tiny delay to interrupt handling; if this has
truly become significant, there's a design issue somewhere else.
(Shared interrupts with modern kernels are not a huge problem, since the
drivers check to see if the interrupt they have is legitimate before the
kernel chains on to the next driver. It's the waste of that additional
check that people want to avoid.)
--
James Cameron
http://quozl.linux.org.au/
6:28 a.m.
James Cameron wrote:
On Tue, Sep 08, 2009 at 07:17:30PM -1000, david
wrote:
The usb port I'm using is on INT 21 (uhci_hcd:usb2), which doesn't share
with anything.
andy
USB not sharing interrupts with anything?
Andy's original post contained /proc/interrupts which showed some
sharing was happening. Here's a cut:
16: 380396 233180 IO-APIC-fasteoi uhci_hcd:usb4, yenta
17: 829711 532117 IO-APIC-fasteoi uhci_hcd:usb5, ohci1394, HDA Intel
18: 0 0 IO-APIC-fasteoi mmc0
19: 2 0 IO-APIC-fasteoi ehci_hcd:usb6
20: 18 17 IO-APIC-fasteoi uhci_hcd:usb1
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 305246 302929 IO-APIC-fasteoi ehci_hcd:usb3
Sharing interrupts adds a tiny delay to interrupt handling; if this has
truly become significant, there's a design issue somewhere else.
(Shared interrupts with modern kernels are not a huge problem, since the
drivers check to see if the interrupt they have is legitimate before the
kernel chains on to the next driver. It's the waste of that additional
check that people want to avoid.)
7:19 a.m.
andy baxter wrote:
James Cameron wrote:
Hmmm. Which video driver are you using (maybe you already mentioned it)?
If using Intel, try VESA, or viceversa, just in case it's the video
driver doing something?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Tue, Sep 08, 2009 at 07:17:30PM -1000, david
wrote:
The usb port I'm using is on INT 21 (uhci_hcd:usb2), which doesn't share
with anything. USB not sharing interrupts with anything?
Andy's original post contained /proc/interrupts which showed some
sharing was happening. Here's a cut:
16: 380396 233180 IO-APIC-fasteoi uhci_hcd:usb4, yenta
17: 829711 532117 IO-APIC-fasteoi uhci_hcd:usb5,
ohci1394, HDA Intel
18: 0 0 IO-APIC-fasteoi mmc0
19: 2 0 IO-APIC-fasteoi ehci_hcd:usb6
20: 18 17 IO-APIC-fasteoi uhci_hcd:usb1
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 305246 302929 IO-APIC-fasteoi ehci_hcd:usb3
Sharing interrupts adds a tiny delay to interrupt handling; if this has
truly become significant, there's a design issue somewhere else.
(Shared interrupts with modern kernels are not a huge problem, since the
drivers check to see if the interrupt they have is legitimate before the
kernel chains on to the next driver. It's the waste of that additional
check that people want to avoid.)
9:13 a.m.
On Wed, September 9, 2009 11:54, andy baxter wrote:
david wrote:
what happened to my notes? stop banging your head on the wall. try another
kernel, any but 2.6.26-rt. you can even try 2.6.26 vanilla. just stay away
from 2.6.26-rt if you want midi back
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Hmmm. Which video driver are you using (maybe you already mentioned
it)? If using Intel, try VESA, or viceversa, just in case it's the video
driver doing something?
Have just tried this and it doesn't help.
9:26 a.m.
Rui Nuno Capela wrote:
what happened to my notes? stop banging your head on
the wall. try another
kernel, any but 2.6.26-rt. you can even try 2.6.26 vanilla. just stay away
from 2.6.26-rt if you want midi back
I'm trying 2.6.24.7-rt at the moment, but it isn't working right with my
intel HDA sound card (it doesn't pick up all the mixer channels.)
andy
10 Sep
10 Sep
5:45 p.m.
andy baxter wrote:
david wrote:
And I'm plumb out of ideas.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
Hmmm. Which video driver are you using (maybe you already mentioned
it)? If using Intel, try VESA, or viceversa, just in case it's the
video driver doing something?
Have just tried this and it doesn't help.
andy 
11 Sep
11 Sep
6:01 a.m.
If you record something from the keyboard with arecordmidi, and later
play it back to qsynth with aplaymidi, are the delays in the .mid file
(always the same) or do they occur with qsynth?
Best regards,
Clemens
8 Sep
8 Sep
2:15 p.m.
andy baxter wrote:
Hi all,
I'm trying to get my usb midi keyboard (an edirol PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
Can anyone recommend an online guide to building a realtime audio
capable kernel? I may have missed some important details when compiling
the kernel I'm using (I just took the debian defaults and switched on
the realtime patch I had applied). E.g. I remember the system timer is
set at 250Hz.
andy
4 p.m.
On Tuesday 08 September 2009 18:15:33 andy baxter wrote:
E.g. I remember the system timer is
set at 250Hz.
andy
If I remember correctly this needs to be changed to 1000 Hz (when you
configure your kernel). It seems to affect the accuracy of MIDI timing, so it
might partially be responsible for the issue you have with MIDI.
Thanks
Paul
4:37 p.m.
Paul Remmers wrote:
On Tuesday 08 September 2009 18:15:33 andy baxter
wrote:
I just changed this and it hasn't fixed the problem.
I'm going to work through this page:
http://tapas.affenbande.org/wordpress/?page_id=40
and see if that helps, but any other suggestions welcome.
andy
E.g. I remember the system timer is
set at 250Hz.
andy
If I remember correctly this needs to be changed to 1000 Hz (when you
configure your kernel). It seems to affect the accuracy of MIDI timing, so it
might partially be responsible for the issue you have with MIDI.
5 p.m.
andy baxter wrote:
Paul Remmers wrote:
Have tried this (basically setting correct realtime scheduling
priorities for all the processes and IRQs involved in the midi / audio
chain), and there's still a problem.
Really not sure where to go from here except trying another distro or
moving back to my old laptop for midi stuff.
andy
On Tuesday 08 September 2009 18:15:33 andy baxter
wrote:
I just changed this and it hasn't fixed the problem.
I'm going to work through this page:
http://tapas.affenbande.org/wordpress/?page_id=40
and see if that helps, E.g. I remember the system timer is
set at 250Hz.
andy
If I remember correctly this needs to be changed to 1000 Hz (when you
configure your kernel). It seems to affect the accuracy of MIDI timing, so it
might partially be responsible for the issue you have with MIDI.
9:49 p.m.
Can anyone recommend an online guide to building a
realtime audio
capable kernel? I may have missed some important details when compiling
the kernel I'm using (I just took the debian defaults and switched on
the realtime patch I had applied). E.g. I remember the system timer is
set at 250Hz.
andy
http://forums.debian.net/viewtopic.php?f=16&t=17035&sid=01133a9068e…
HTH
Norv
__________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/
9 Sep
9 Sep
2:28 p.m.
andy baxter wrote:
Hi all,
I'm trying to get my usb midi keyboard (an edirol PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
I've tried kernel 2.6.24.7-rt27, and this is no better with the midi
timing than any of the others (but has a problem with my intel HDA /
Analog devices onboard sound card). Thinking of trying just copying the
kernel and modules from my old laptop (which is running ubuntu hardy I
think) to see if that cures it.
andy
3:42 p.m.
andy baxter wrote:
andy baxter wrote:
Have tried this too - no luck. :-/
(The kernel was ubuntu 8.04, vmlinuz-2.6.24-24-rt)
andy
Hi all,
I'm trying to get my usb midi keyboard (an edirol PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
I've tried kernel 2.6.24.7-rt27, and this is no better with the midi
timing than any of the others (but has a problem with my intel HDA /
Analog devices onboard sound card). Thinking of trying just copying the
kernel and modules from my old laptop (which is running ubuntu hardy I
think) to see if that cures it.
10 Sep
10 Sep
2:17 a.m.
On Wed, Sep 09, 2009 at 06:42:04PM +0100, andy baxter wrote:
Have tried this too - no luck. :-/
Don't discount the possibility of hardware failure. Have you access to
identical hardware that you can try out? Is the processor running cool?
Certain processors can slow down if they become hot. Can you run
memtest without errors?
--
James Cameron
http://quozl.linux.org.au/
12 Sep
12 Sep
7:37 a.m.
I've been asking for help on the linux-audio-user list with a midi
timing problem and had many helpful suggestions but still not managed to
solve the problem, so I am cross-posting to alsa-user.
I've been trying for a week or two to get my roland edirol PCR keyboard
working with my good laptop, which is a thinkpad X61s (dual core 1400
MHz). There is a problem with midi timing - when I play notes on the
keyboard into fluidsynth, the notes are slightly delayed. The delay is
small (around 0.1s ?) but enough to be annoying. On my old laptop (a
dell 1400 Mhz single core), it works fine. I am using the keyboard
through its built in usb midi interface. I am running debian testing,
but have also tried ubuntu jaunty, which has the same problem.
The things I have tried so far (with no luck) are:
- compiling different -rt kernels. So far none of these has made a
difference, including when I just copied the kernel and modules from my
old laptop (which is running ubuntu hardy) across to the new one.
- setting realtime priorities for all the processes and interrupts
involved in the audio/midi chain. (according to instructions on this
page: http://tapas.affenbande.org/wordpress/?page_id=40 )
- running fluidsynth without jackd. (straight to alsa).
- setting the fluidsynth sample rate and other parameters to the same as
jackd.
- using another synth. (zynaddsubfx)
- running the system with no X server or ethernet.
- swapping the usb-midi lead from the keyboard to a different usb port.
- someone suggested using 'modprobe snd-usb-audio nrpacks=1'.
None of these have cured the problem. All I can think of doing now is to
move back to my old laptop for midi stuff (which is a hassle and also
annoying because I bought the new one partly because I thought it would
be good for music), or to try some other hardware solution, like running
the keyboard from a power supply and using a midi cable with a seperate
usb midi card.
Before I do this, it would be good to know if anyone on alsa-user has
any suggestions?
Thanks,
andy baxter.
andy baxter wrote:
Hi all,
I'm trying to get my usb midi keyboard (an edirol PCR 800) working with
my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running
with 8 msec latency and no xruns using an onboard intel HDA sound card.
When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output,
the notes are triggered with a slight (<0.1s?), and variable time delay.
Sometimes the note plays immediately on pressing the key; sometimes
there is a noticeable delay. This does not happen when I use the same
setup on my old laptop (a 1400 Mhz single core dell).
The OS is debian testing at the moment, but I have had the same problem
on this laptop with both ubuntu jaunty and a fairly recent version of
linux mint.
Does anyone have any idea what might be happening, or what I can do to
narrow down the cause of the problem a bit further?
My /proc/interrupts, lsusb, and lspci are pasted below.
Cheers,
andy baxter
andy@monkey:~$ cat /proc/interrupts
CPU0 CPU1
0: 1207873 1669765 IO-APIC-edge timer
1: 2473 1983 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc0
9: 19517 11123 IO-APIC-fasteoi acpi
12: 25255 22957 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge ide0
16: 380396 233180 IO-APIC-fasteoi uhci_hcd:usb4, yenta
17: 829711 532117 IO-APIC-fasteoi uhci_hcd:usb5, ohci1394,
HDA Intel
18: 0 0 IO-APIC-fasteoi mmc0
19: 2 0 IO-APIC-fasteoi ehci_hcd:usb6
20: 18 17 IO-APIC-fasteoi uhci_hcd:usb1
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 305246 302929 IO-APIC-fasteoi ehci_hcd:usb3
220: 8566 7543 PCI-MSI-edge eth0
221: 27049 24430 PCI-MSI-edge ahci
NMI: 0 0 Non-maskable interrupts
LOC: 426040 660568 Local timer interrupts
RES: 2036860 2297232 Rescheduling interrupts
CAL: 7278 7718 function call interrupts
TLB: 14422 14326 TLB shootdowns
TRM: 0 0 Thermal event interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
MIS: 0
andy@monkey:~$ lsusb
Bus 001 Device 003: ID 0483:2016 SGS Thomson Microelectronics
Fingerprint Reader
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0582:0033 Roland Corp. EDIROL PCR
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 07ab:fcdf Freecom Technologies
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
andy@monkey:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network
Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
Controller #2 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface
Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller
(rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or
AGN [Kedron] Network Connection (rev 61)
05:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
05:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
(rev 04)
05:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter (rev 21)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
15 Sep
15 Sep
9:44 a.m.
andy baxter wrote:
when I play notes on the keyboard into fluidsynth, the
notes are
slightly delayed. The delay is small (around 0.1s ?) but enough to be
annoying.
Is the delay constant or random?
If you monitor the keyboard's output with aseqdump at the same time, do
you see the same delay when the notes are printed?
Best regards,
Clemens
17 Sep
17 Sep
4:17 p.m.
Clemens Ladisch wrote:
andy baxter wrote:
The delay is variable - sometimes the note will sound almost
immediately, but usually there is a slight delay.
I've tried with aseqdump, and as far as I can tell there is no delay -
'note on' seems to appear at the same moment that I press the key.
I've also tried using zynaddsubfx instead of qsynth / fluidsynth, and
the delay is still there.
Which seems odd - I would have expected that if aseqdump was not showing
a delay then the problem must be with qsynth. Maybe there's some library
or code snippet that zyn and qsynth both share?
I'm wondering if it would help to install the whole of ubuntu hardy on
my new laptop and see if that cures the problem (that's what my old
laptop is running, which works fine.)
andy
when I play notes on the keyboard into
fluidsynth, the notes are
slightly delayed. The delay is small (around 0.1s ?) but enough to be
annoying.
Is the delay constant or random?
If you monitor the keyboard's output with aseqdump at the same time, do
you see the same delay when the notes are printed?
Best regards,
Clemens
18 Sep
18 Sep
9:08 a.m.
On Thu, 17 Sep 2009 19:17:26 +0100
andy baxter <andy(a)earthsong.free-online.co.uk> wrote:
Clemens Ladisch wrote:
I don't remember whether you said if it's the same with a sequencer.
I just thought I could point you to a little app that shows midi jitter.
With that you could play some monotonous repetitive stuff from a
sequencer and see if there are huge delays or breakouts.
The test, originally to test the sequencers, is described here:
http://tapas.affenbande.org/wordpress/?page_id=56
The app midi_timer-1.tgz can be found on this page:
http://tapas.affenbande.org/wordpress/?page_id=40
the delta-thingy might be most useful.
Philipp
andy baxter wrote:
The delay is variable - sometimes the note will sound almost
immediately, but usually there is a slight delay.
I've tried with aseqdump, and as far as I can tell there is no delay
- 'note on' seems to appear at the same moment that I press the key.
I've also tried using zynaddsubfx instead of qsynth / fluidsynth, and
the delay is still there.
Which seems odd - I would have expected that if aseqdump was not
showing a delay then the problem must be with qsynth. Maybe there's
some library or code snippet that zyn and qsynth both share?
I'm wondering if it would help to install the whole of ubuntu hardy
on my new laptop and see if that cures the problem (that's what my
old laptop is running, which works fine.)
andy when I play notes on the keyboard into
fluidsynth, the notes are
slightly delayed. The delay is small (around 0.1s ?) but enough to
be annoying.
Is the delay constant or random?
If you monitor the keyboard's output with aseqdump at the same
time, do you see the same delay when the notes are printed?
Best regards,
Clemens
19 Sep
19 Sep
1:43 p.m.
New subject: [Alsa-user] midi triggering delay
andy baxter wrote:
The delay is variable - sometimes the note will sound almost
immediately, but usually there is a slight delay.
I've tried with aseqdump, and as far as I can tell there is no delay -
'note on' seems to appear at the same moment that I press the key.
I've also tried using zynaddsubfx instead of qsynth / fluidsynth, and
the delay is still there.
Which seems odd - I would have expected that if aseqdump was not showing
a delay then the problem must be with qsynth. Maybe there's some library
or code snippet that zyn and qsynth both share?
I'm wondering if it would help to install the whole of ubuntu hardy on
my new laptop and see if that cures the problem (that's what my old
laptop is running, which works fine.)
I've just tried this (installing hardy), and if anything the problem is
worse. So it seems like some kind of hardware incompatibility. Somebody
pointed out that the main difference between this machine and my old one
is the dual core processor. I tried using schedtool to run jackd and
qsynth on the same processor; this seemed to improve the situation
slightly (though it's hard to tell as the delay is quite small and
variable), but not enough that I can use this machine with the midi
keyboard.
Would really appreciate some help with this from the developers if
anyone can spare the time - I am happy to do any necessary diagnostic
work at this end.
andy
22 Sep
22 Sep
6:45 a.m.
andy baxter wrote:
The delay is variable - sometimes the note will sound
almost
immediately, but usually there is a slight delay.
I've tried with aseqdump, and as far as I can tell there is no delay -
'note on' seems to appear at the same moment that I press the key.
Delays aren't as apparent visually. Could you record something with
arecordmidi, then play it to the synth with aplaymidi? When doing this,
are the delays the same when you play it repeatedly?
I've also tried using zynaddsubfx instead of
qsynth / fluidsynth, and
the delay is still there.
Which seems odd - I would have expected that if aseqdump was not showing
a delay then the problem must be with qsynth. Maybe there's some library
or code snippet that zyn and qsynth both share?
Could you try with another synth, e.g., Timidity?
Best regards,
Clemens
5594
days inactive
5609
days old
linux-audio-user@lists.linuxaudio.org
37 comments
9 participants
participants (9)
-
andy baxter -
Clemens Ladisch -
david -
hollunder＠gmx.at -
James Cameron -
Norval Watson -
Paul Remmers -
Philippe Hezaine -
Rui Nuno Capela