[alsa-devel] Tascam US122 on Arm
Hi
I am a little irritated that there has been no replies to my questions to this list (http://mailman.alsa-project.org/pipermail/alsa-devel/2007-September/003387.h..., http://mailman.alsa-project.org/pipermail/alsa-devel/2007-September/003083.h...).
Am i on the wrong list? Please tell me if so.
Probably its also that i didn't make clear in my last post that the tascam driver works on arm with my US122 sound card, for ca. 51 seconds. After that i get the following error:
Sequence Error!(hcd_frame=6 ep=8in;wait=65538,frame=2). Most propably some urb of usb-frame 65538 is still missing. Cause could be too long delays in usb-hcd interrupt handling.
I also tried insmod ./2.6.18/kernel/sound/usb/usx2y/snd-usb-usx2y.ko nrpacks=X with X=[1,2,4,8]. I thought that if it is really an CPU performance problem than probably a bigger buffer would eliminate the problem. However the error persisted. Even commenting out /* #define USX2Y_NRPACKS_VARIABLE y */ and setting #define USX2Y_NRPACKS 1 didn't help.
So my question is now, is the 250Mhz ARM really to slow or is there any chance that there is an error in either the usb stack or the driver exposed only on the ARM architecture? Things speaking for the latter are: *Error allways in the 65536-65540 value. *Error happens most of the times after about 50secs.
Since i do not know much about USB any hint is apreciated. ST
On 9/29/07, ST st@iss.tu-darmstadt.de wrote:
So my question is now, is the 250Mhz ARM really to slow or is there any chance that there is an error in either the usb stack or the driver exposed only on the ARM architecture? Things speaking for the latter are: *Error allways in the 65536-65540 value. *Error happens most of the times after about 50secs.
I've had usb-related error messages with the Tascam US-428 on my AMD 64x2 4600. It looks like you've got a 32-bit error code integer being forced into an unsigned 16-bit integer, or some function is returning -1 in a 16-bit integer (which would be 65535 if unsigned), and the driver is putting it in a 32-bit integer without sign extension and incrementing it as though it is the number of the usb frame. Look through the driver code to see where that value is assigned to a variable, and find out what function is doing it. Basically, since it's happening right after the limits of a 16-bit integer, I'd say it's either an overflow error, or an error code is being returned in the wrong kind of variable (signed vs. unsigned). In my case, what solved my USB error messages was disabling PowerNow CPU frequency scaling.
Mike Bourgeous
Hi Micheal
-1 in a 16-bit integer (which would be 65535 if unsigned), and the driver is putting it in a 32-bit integer without sign extension and incrementing it as though it is the number of the usb frame.
Thats an interesting idea. I think i will take a look at the code if this is the case.
Look through the driver code to see where that value is assigned to a variable, and find out what function is doing it. Basically, since it's happening right after the limits of a 16-bit integer, I'd say it's either an overflow error, or an error code is being returned in the wrong kind of variable (signed vs. unsigned). In my case, what solved my USB error messages was disabling PowerNow CPU frequency scaling.
Intresting. I got a different mail http://www.nslu2-linux.org/wiki/Peripherals/AudioAdapter Since i have an 1.0 Soundcard and EHCI ports this is probably one cause of the problem.
Currently i have taken out the call usX2Y_clients_stop(usX2Y); in the function usX2Y_error_sequence and added an subs->completed_urb = urb; to the corresponding else statement. Since them i didn't had any errors reported, but i suspect i did an error somewhere, since the error occured on every playback and now i don't get any usb glitches reported. I will test it a little bit more and get back with some results.
Best regards ST
participants (2)
-
Michael Bourgeous -
ST