Spencer Russell wrote:
Sorry to cross-post, but i didn't get any response
on LAU, and
was hoping maybe there're some developers that might have a
better idea of what's going on.
A while ago I was having trouble with my US428 hanging my system,
usually directly after I tried to start JACK.
I have a US-224, which is the lesser sister of the US-428. When I bough it
on last May-2004, alsa/linux support was pretty flaky. Then got worse, as
my OHCI based laptop exposed a kernel-crash when openning the audio pcm
device. It was probably this very one that was aunting you before. After
some attention and furious alsa-bugtracker exchange, Karten Wiese has been
able to solve this, even tought he's got no OHCI hardware near him.
The OHCI issue has been solved since snd-usb-usx2y >= 0.8.6. Since then
your US-428 should work without major troubles.
Then Karsten did it again. He crafted a special jackd alsa/usx2y backend
which enabled the so-called raw-usb mode of operation. And it was just
yesterday I have proposed the merge into the official alsa backend driver
on the jackit-devel list. With this new experimental stuff, one can run
jackd in realtime with pretty lowest-latency parameters, without aural
artifacts (i.e. crackling). AFAICT this is a greatest breakthrough on the
USB audio arena, so I would think twice about getting rid of your US428 ;)
So I downloaded the 2.6.10-rc2 source, applied the
mm3, usx2y-0.8.7,
and rt2 patches, used make-kpkg to make a nice debian-friendly package,
and installed the kernel and modules. I also got the realtime-lsm
module, and the package that has the scripts to set it up all
nice and easy. So I boot it up, and aside from my touchpad not
working, everything looks good. So I tail -f /var/log/messages,
and plug in my US428. It seems to load the firmware and start
us428control the way it's supposed to, and I can even start jack
and run the xmms-jack out plugin and listen to music through it.
Seems to work great. But as soon as I start ardour, I get this:
So it worked eh? So you're in the right track. Now remember that the
Ingo's RT kernel is highly experimental. However, in my own experience,
you must have your RT-preempt kernel fine tuned to get the best and stable
results, and this is no less true when working with the USB US-X2Y.
Believe me. I know. I've been there ;)
So my recipe goes like this:
1. Have REALTIME_PREEMPT on the kernel config.
2. Make sure you have loaded the latest snd-usb-usx2y>=0.8.7.1 (as of
latest alsa-kernel cvs).
3. Tune the RT priorities (SCHED_FIFO) of the time-audio critical IRQ
threads:
90 - timer (IRQ 0)
80 - rtc (IRQ 8)
70 - snd (or whatever your PCI soundcard will hook, usually IRQ 5)
60 - usb (ohci_hcd or uhici_hcd, usually IRQ 10)
You should have schedutils installed (chrt) for this exercise.
4. Load the snd-usb-usx2y with the nrpacks parameter set for:
a. high-stability: nrpacks=4
b. low-latency: nrpacks=1
Anyway, be advised that you can only run the forementioned "rawusb"
mode if you set on this later one (modprobe snd-usb-usx2y nrpacks=1).
Run your jackd command line (or qjackctl;) as usual, but given the above
priority tunning, you should try e.g. jackd -R -P60 ...
kernel: Sequence
Error!(hcd_frame=1152ep=10out;wait=120,frame=124).
kernel: Most propably some urb of usb-frame 120 is still missing.
kernel: Cause could be too long delays in usb-hcd interrupt handling.
and qjackctl up and disapears, and ardour gives an error about
being booted by jack.
This used to happen all the time to me too, but much less frequently if
you follow the above recipe carefully.
but I'm pretty stoked at at least my computer
didn't hang(as it
used to), until I unplug the device, and do some other stuff, and
then it hangs.
This is rather true still, but you gotta give to the experimental status
of the whole thing (which are the RT kernel and specially the
snd-usb-usx2y module). It has been just a couple of months or so that I
got my US224 to work properly on my laptop due to the OHCI crash issue. I
never thought on seeling it back, but pushed some presure in trying to
solve it the open source way, which is all about linux-audio-dev isn't it?
So I guess I'm in a slightly better position than
before, but I'm getting pretty close to selling this, and saving
up for one of the RME pcmcia interfaces.
If you can convince Paul that you'll be using the RME cardbus on linux
(and ardour, of course) he would be pleased to make you an unbeatable
offer. But then we will loose a valuable usx2y user, isn't it?
Good luck
and happy holydays.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org