[alsa-devel] Tascam US-428 USB Problems

[Michael Bourgeous]

On 8/16/07, Karsten Wiese <fzu at wemgehoertderstaat.de> wrote:
> Am Donnerstag, 16. August 2007 schrieb Michael Bourgeous:
> >
> > I hope this reaches the Tascam driver developer...  I have a Tascam
> > US-428 which worked great with my Athlon XP, but does not work at all
> > with my new system, an Athlon 64 X2.  I've tried using the regular
>
> Is it also the alsa-driver-1.0.14rc3, that works on the Athlon XP?
> Please try the vesrion on the X2 that works on the XP.

I am using 1.0.14rc3 on both.

> The Athlon 64 X2 is run in 64Bit Mode?

Yes.

> Erm, I only have uniprocessor machines up to now....
> please switch the Athlon 64 X2 to run with one core only and recheck.

I'll have to try this later.

> Please post the lspci of the new machine.

00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev f1)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a4)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Contro
ller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f3)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev f2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev f3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTra
nsport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Con
troller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscella
neous Control
01:06.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 04)
01:07.0 Multimedia controller: Teralogic Inc TL880-based HDTV/ATSC tuner (rev 13
)
01:08.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
01:08.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)
05:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7300 GT] (rev
 a1)

On 8/16/07, Karsten Wiese <fzu at wemgehoertderstaat.de> wrote:
> Am Donnerstag, 16. August 2007 schrieb Michael Bourgeous:
> >
> > This leads to question one: Is there any reason to bail out instead of
> > trying to recover from errors?
>
> Audio glitches.

I can appreciate the fact of pro audio that glitchy audio is worse
than no audio, but when the driver bails out, it causes jackd to
crash, and all of the running jackd clients abort without letting me
save settings.  So, in this case, I'd rather be able to save my
settings.  However, I think this may be entirely avoidable in code.
I'll explain more below.

> > question two: what kinds of problems, software or hardware, would lead
> > to a buffer overflow error, and can I fix this in the driver code?
>
> The US-428 is the only device connected to that particular usb-port?

Currently, yes.

> What are the other devices that work?
> Do they also fully utilize usb 1.1 capacity?

My mouse works without dropouts, which obviously doesn't use the full
capacity.  Additionally, a USB mass storage device works, which does
use the full USB 1.1 (or maybe it's 2.0, can't remember).

I have some more information.  I found out that Windows users of the
Tascam experience system BSODs when power management is enabled.  So,
I disabled PowerNow and acpid, and I no longer get the USB error
messages in the syslog or jackd crashes.  This leads me to believe
that something, somewhere in the kernel, is relying upon the CPU cycle
count for timing, and when the CPU switches from 1GHz to 1.8GHz or
2.4GHz, it triggers a buffer overrun.  Whether that's in the usx2y
driver or in the host controller code I don't know.

Still, performance is less than I would expect, with occasional xruns
and hundreds of "delay longer than estimated" messages, when running
at 256 samples latency (the setting I typically use in Windows).  To
the credit of the Linux driver, I'm able to get down to 128 samples (2
periods of 64 frames), but I can only play a few notes at a time in
ZynAddSubFX before it xruns.  Performance is slightly better with
jackdmp, which I modified to fully disable its broken usx2y driver,
but its use is very inconvenient.  I also switched from jackd 102.20
to 103, which doesn't crash when the syslog messages happen.

I'm running a 2.6.20 kernel with full preemption, with the IRQ-xx
process for the USB port set to RT priority 90, SCHED_FIFO.  During
all of these tests, the maximum latency reported in
/proc/sys/preempt_max_latency was 33 usecs.

Mike Bourgeous