On Fri, Feb 19, 2010 at 1:36 AM, Pratik Prajapati <pratik.prajapati@xxxxxxxxx> wrote: > Hello, > > I'm doing playback/record with usbaudio on TI musb with ALSA. > > My concern is, in isochronus mode (with CPPI DMA) I see a lot of > interrupts and so ksoftirqd takes up to 30% CPU in addition to Audio > application. And in bulk mode(with CPPI DMA) I see less interrupts and > also ksoftirqd is taking around 15% CPU in addition to the > application. Is there any way by which I can get lesser interrupts in > sochronus mode (with CPPI DMA)? > > my linux is: 2.6.10_mvl401, with > musb_hdrc: version 2.2a/db-0.4.8 [cppi-dma] [host] [debug=1] > musb_hdrc: ConfigData=0x06 (UTMI-8, dyn FIFOs, SoftConn) > musb_hdrc: MHDRC RTL version 1.300 > musb_hdrc: USB Host mode controller at c8002000 using DMA, IRQ 12 > musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 > > I have observed that whether I play 8KHZ audio or 44KHZ audio, I see > iso_frame_desc (packed in urb) ramains of same length, i.e. 176 bytes. > e.g. > I played 8KHZ audio and found that, musb is gets total 4 > iso_frame_desc in each URB. size of each iso_frame_desc is 176 bytes. > I played 44KHZ audio and found that, musb is gets total 4 > iso_frame_desc in each URB. size of each iso_frame_desc is 176 bytes. > In each URB musb gets 4 iso_frame_desc, which is fixed by variable > 'static int nrpacks' in usbaudio.c. > 44100 hz, 16 bit audio, stereo requires 44100*2*2 = 176,400 bytes per second. This means that you must send 176.4 bytes per frame, an uncomfortable number. So the driver will send 9 frames of 176 bytes and 1 frame of 180 bytes every 10 ms. Any other combination will make the music sound "wrong". So for 44.1k audio you should always be sending 10 frames worth in 1764 byte urbs. >From your description about 8khz audio, the stream is being up-sampled by the cpu to 44.1khz playback. 8khz audio is a funny speed, check the device descriptors and see what endpoint speed/sizes it supports. I have seen audio chips that will play 48,000 samples per second, so maybe your chip supports it. If you choose a "natural" playback rate, then the cpu will not have to resample the playback. I don't know about your hardware, but with a USB bus analyzer you can see if proper data is being sent to the audio device. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
