14 May
2012
14 May
'12
6:30 p.m.
From: Monty Montgomery <xiphmont(a)gmail.com>
Date: Sun, 13 May 2012 16:40:28 -0400
On Sun, May 13, 2012 at 4:06 PM, Robin Gareus
<robin(a)gareus.org> wrote:
alrighty, i've compiled some kernels and also tested most of what's in the AVLinux
repository, and now i have some interesting data:
two general caveats: neither compiling myself nor whether or not PAE is enabled seems to
matter much.
also, this is all still on my new ThinkPad T520.
3.0.6-avl-5 and 3.0.16-avl-7 are the only two which are really useful for me... my RME
Multiface on ExpressCard is solid at 64x2 under load, and my ART USB Dual Tube Pre seems
solid under load at 128x4 (although the 3.0.16 might need to go to 256x4 -- i haven't
lived with it long enough to know -- i do think the xruns are creeping in earlier on
3.0.16 than on 3.0.6).
3.0.30-avl-8 makes the RME useless -- Jack starts, but crashes almost as soon as i start
any application (even just jack_mixer alone!). with the USB interface, my system locks up
when i start my test puredata patch, even at latencies higher than 128x4.
anything higher than 3.0.30 behaves similarly to 3.0.30 with both cards. i tested up to
3.4.0.rc7.
it's hard to get really accurate numbers without a LOT of time on controlled testing,
which i really don't have right now, but from observations of the system in use, it
seems pretty obvious that there's a breakpoint somewhere between 3.0.16 and 3.0.30, at
which something changed, making both of my interfaces severely less usable. i'm
particularly surprised about the RME hardware, which has always been solid for me on
various systems and kernels over the years.
i don't know whether that gives anybody enough info to tell much of anything, but
perhaps it's useful... for now, i'm running 3.0.6-avl-5-pae in
production/performance.
cheers!
Any hints on how to address this issue, then? If
I understand correctly,
new USB2-class-compliant devices are not an issue, but on modern
machines with only EHCI, USB1-class-compliant devices may or may not
work... right?
The primary problem with EHCI is only bandwidth allocation; it's
inefficient. I'm unaware of any timing problems. That's not to say
they don't exist, I just haven't run into them myself.
Poor bandwidth efficiency aside, I usually see ~ the same latency and
timing behavior on UHCi and EHCI with a TT.
Would forward porting your schedulers be an
option? Has anything of this
been merged into recent kernels?
I'm unlikely to do this unless I need it myself, sorry :-(. Not
enough time, too much to do. And the kernel devs are absolutely right
that replacing a working but inefficient driver with a brand new one
that is faster but will require long-term testing is not something to
be done lightly.
Maybe you can do play some tricks on the EHCI
controller/scheduler: add
an old USB1.1 hub in between the soundcard and the PC... but that's just
a shot in the dark.
You'll still be going through the translator in the root hub.
Monty