USB Bandwith issue on IMX8M Mini

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB Bandwith issue on IMX8M Mini

2,441 Views
tyler_ward
Contributor III

I am encountering an issue using a USB sound card based on the cmedia CM6206 IC when used on the IMX8M Mini dev board running the example yocto build with some additional packages. When used on the IMX board i get the following dmesg errors indicating a lack of usb bandwidth.  

[ 7842.124001] retire_capture_urb: 1242 callbacks suppressed
[ 7847.126543] retire_capture_urb: 1241 callbacks suppressed
[ 7852.129241] retire_capture_urb: 1240 callbacks suppressed
[ 8131.025107] kauditd_printk_skb: 313 callbacks suppressed
[ 8131.025113] audit: type=1006 audit(1564672351.145:9): pid=4524 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=8 res=1
[ 8468.600276] retire_capture_urb: 1231 callbacks suppressed
[ 8491.603052] usb 1-1: cannot submit urb 0, error -28: not enough bandwidth
[ 8504.029087] retire_capture_urb: 586 callbacks suppressed
[ 8509.034814] retire_capture_urb: 1231 callbacks suppressed
[ 8514.042949] retire_capture_urb: 1242 callbacks suppressed
[ 8519.050003] retire_capture_urb: 1242 callbacks suppressed
[ 9180.893566] kauditd_printk_skb: 741 callbacks suppressed

The suppressed callbacks and not enough bandwidth errors are from different test applications. I have tested on other boards (an Intel based up board and an arm based odroid c2) and I don't get the errors shown above. Have other people encountered this issue and is there a solution for this problem?

Thanks

Tyler

Some additional information:

root@imx8mmevk:~# lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
|__ Port 1: Dev 6, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 6, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 6, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 6, If 3, Class=Human Interface Device, Driver=usbhid, 12M

This one works

arecord -D hw:1,0 -f S16_LE -c 2 -r 48000 | aplay -D hw:1,0 -f S16_LE -c 2 -r 48000

This one does not

arecord -D hw:1,0 -f S16_LE -c 2 -r 48000 | aplay -D hw:1,0 -f S16_LE -c 4 -r 48000

Labels (2)
0 Kudos
5 Replies

2,094 Views
tyler_ward
Contributor III

Some more info on this. We have tested with a professional soundcard (ICE16) which uses a hi speed (480Mb/s) interface rather than the usual full speed (12Mb/s) interfaces used on consumer sound cards e.g. (CM6206) we are trying to connect and don't get the issues discussed above. Both of the cards are using the same kernel modules for the audio backend.

0 Kudos

2,094 Views
diegoadrian
NXP Employee
NXP Employee

Hello,

I apologize for the delay.

Have you tried using the sound card that is on our BSP "WM8524CGEDT"?

Best regards,

Diego.

0 Kudos

2,094 Views
diegoadrian
NXP Employee
NXP Employee

Hello

Can you please try reducing the buffer size for the Alsa card?

To make that, please try the below command.

$ echo x > /proc/asound/card1/pcm0p/sub0/prealloc  Where x is the size of the buffer you want to use.

Hope this could help you.

Best regards,

Diego.

0 Kudos

2,094 Views
tyler_ward
Contributor III

Hi Diego

We don't have a prealloc file in /proc/asound/card1/pcm0p/sub0/ directory however I have adjusted the alsa buffer size both up and down via our software and the arecord/aplay combo to various values and the errors still occur. If i set the buffer size in aplay low enough (512) it then causes the EXDEV error like our software rather than the urb -28 (ENOSPC) error.

Thanks

Tyler

0 Kudos

2,094 Views
tyler_ward
Contributor III

Have done some more debugging and got some more info.

The callbacks suppressed error is due to kernel rate limiting of a non printed debug messages this can be fixed by using the kernel patch given at https://github.com/raspberrypi/linux/issues/535 I have also now got the message causing the print rate limit to print and the error is 

frame 0 active: -18

which is the code for EXDEV

ISO: URB_ISO_ASAP wasn’t specified and all the frames the URB would be scheduled in have already expired.

Therefore this looks to be caused an issue somewhere in the USB stack.

0 Kudos