[alsa-devel] Tascam US-428 USB Problems
Hello,
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 alsa driver, as well as the hwdep audio, and jackd always crashes with a SIGSEGV, with the following message in the kernel log:
[ 2538.003798] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:148: should not be here with counts=42 [ 2538.003806] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:91: active frame status -70. Most probably some hardware problem. n
I did some searching through source code, and found that the frame status of -70 (ECOMM) indicates an OHCI buffer overflow error. As soon as the usx2y driver receives this it bails out of whatever it's doing, and jackd crashes. I've tried changing the usx2y driver to ignore such errors, and while there are audio glitches when such an error occurs, jackd no longer crashes and the audio keeps playing. This leads to question one: Is there any reason to bail out instead of trying to recover from errors?
I've tried all the different USB ports on my motherboard, different USB cables, and running through a hub instead of a direct connection. None of these things helped. Though the usx2y message says "Most probably some hardware problem", I think this is something that is software related, as other USB devices have no problems. So here is 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?
Thanks, Mike Bourgeous
Am Donnerstag, 16. August 2007 schrieb Michael Bourgeous:
Hello,
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 alsa driver, as well as the hwdep audio, and jackd always crashes with a SIGSEGV, with the following message in the kernel log:
[ 2538.003798] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:148: should not be here with counts=42 [ 2538.003806] ALSA /home/nitrogen/src/alsa-driver-1.0.14rc3/usb/usx2y/usbusx2yaudio.c:91: active frame status -70. Most probably some hardware problem. n
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.
The Athlon 64 X2 is run in 64Bit Mode?
Erm, I only have uniprocessor machines up to now.... please switch the Athlon 64 X2 to run with one core only and recheck.
I did some searching through source code, and found that the frame status of -70 (ECOMM) indicates an OHCI buffer overflow error. As soon as the usx2y driver receives this it bails out of whatever it's doing, and jackd crashes. I've tried changing the usx2y driver to ignore such errors, and while there are audio glitches when such an error occurs, jackd no longer crashes and the audio keeps playing. This leads to question one: Is there any reason to bail out instead of trying to recover from errors?
I've tried all the different USB ports on my motherboard, different USB cables, and running through a hub instead of a direct connection. None of these things helped. Though the usx2y message says "Most probably some hardware problem", I think this is something that is software related, as other USB devices have no problems. So here is 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?
Please post the lspci of the new machine.
Karsten
Am Donnerstag, 16. August 2007 schrieb Michael Bourgeous:
I did some searching through source code, and found that the frame status of -70 (ECOMM) indicates an OHCI buffer overflow error. As soon as the usx2y driver receives this it bails out of whatever it's doing, and jackd crashes. I've tried changing the usx2y driver to ignore such errors, and while there are audio glitches when such an error occurs, jackd no longer crashes and the audio keeps playing. This leads to question one: Is there any reason to bail out instead of trying to recover from errors?
Audio glitches.
I've tried all the different USB ports on my motherboard, different USB cables, and running through a hub instead of a direct connection. None of these things helped. Though the usx2y message says "Most probably some hardware problem", I think this is something that is software related, as other USB devices have no problems. So here is 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?
What are the other devices that work? Do they also fully utilize usb 1.1 capacity?
Karsten
On 8/16/07, Karsten Wiese fzu@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@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
Am Freitag, 17. August 2007 schrieb Michael Bourgeous:
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.
Try to only disable cpu speed changes. You can "preselect" fixed speed by doing i.e.: $ echo 1800000>/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq $ echo 1800000>/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq $ echo 1800000>/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq $ echo 1800000>/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq Is that enough to stabilize things?
I think the buffer overrun is caused by the cpu not "cooperating" with the OHCI's DMA during the frequency transitions.
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
USB 1.1 transfers happen at 1ms bounderies. Setting 64Frames/period period interrupts will happen within 1ms or 2ms distances. This jitter alone limits the cpu's usability for the sound app to less than 50%. 128Frames/period causes interrupts every 2 or 3 ms, so you can use <66% of the cpu's cycles. Above is for 2 periods. I set 128Frames/period, 3periods here.
Karsten
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
On 8/17/07, Karsten Wiese fzu@wemgehoertderstaat.de wrote:
Am Freitag, 17. August 2007 schrieb Michael Bourgeous:
Try to only disable cpu speed changes. You can "preselect" fixed speed by doing i.e.: $ echo 1800000>/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq $ echo 1800000>/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq $ echo 1800000>/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq $ echo 1800000>/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq Is that enough to stabilize things?
Yes, this eliminates the error messages in the kernel log. The other big boost in stability came from switching from Ubuntu's jackd 102.20 to jackd 103.0 compiled from source.
Still, performance is less than I would expect, with occasional xruns
USB 1.1 transfers happen at 1ms bounderies. Setting 64Frames/period period interrupts will happen within 1ms or 2ms distances.
I was not aware of the 1ms granularity for USB interrupts. Would USB 2.0 or Firewire offer a better granularity?
I set 128Frames/period, 3periods here.
That seems to be a nice balance for me as well, considering that 64 is out of the question. Thanks for the assistance.
Mike Bourgeous
USB 1.1 transfers happen at 1ms bounderies. Setting 64Frames/period period interrupts will happen within 1ms or 2ms distances.
I was not aware of the 1ms granularity for USB interrupts. Would USB 2.0 or Firewire offer a better granularity?
Technically both operate at down to 1/8ms.
Linux's USB 2.0 ehci driver doesn't go there and limits isochronous transfer granularity at 1ms. I posted a patch to linux-usb-devel, which enables 1/8ms granularity isochronous transfer. There was exactly 0 answer to it. And I was too lazy to follow up on that ;-)
Regarding Firewire: I guess the "new stack" can operate at 1/8ms granularity.
Karsten
participants (2)
-
Karsten Wiese -
Michael Bourgeous