Hi USB Audio experts, I am trying to prototype an application where the key requirement is playback with minimal power on USB audio accessories while maintaining tight synchronization with video. With the default ALSA USB code, I am getting ~130 interrupts/s due to audio, a fairly high CPU load and a very poor sync, exactly the opposite of my goals... After a careful analysis of the code I found a couple of issues where the help of experts would be welcome:
- Is there any good reason why the max number of packets per urb defaults to 8? This end-ups being the root cause for the large number of interrupts. My headset supports up to 192 bytes/packet, that means 1536 bytes/urb and 125 interrupts/s. Using more packets/urb results in a linear decrease of the interrupt rate.
- Increasing the number of packets/urbs solves my power issue but not the synchronization issue. If I reduce the number of urbs to reduce the interrupt rate, then the accuracy of the hw_pointer is decreased big time and it becomes difficult to synchronize with video. The .pointer routine only keeps track of retired urbs, it seems there's no way to know how many samples were played at a given time? It also makes pulseaudio behave somewhat strangely since the driver only provides an approximate position. In the CAIQ driver code, the .pointer routine seems to rely on a direct register read, a more efficient way to do things. Isn't there a direct way to query the usb core to know how many bytes have been transmitted and make the hw_ptr/delay information independent of the urb buffer size?
- Is there any reason why the driver relies on vmalloc and memcpy? It seems like using physically-contiguous memory would be more efficient, as done in the CAIQ driver? I hacked something to use prealloc_pages/malloc_pages and things seem to work fine.
- The period information is not updated when the urbs are allocated. In my case the period specified was 25ms, but with all the approximations the actual period (number of urbs*buffer_size_per_urb) was 24ms. In short there's a discrepancy between what is known to the application, what is used by the driver and the actual rate of period_elapsed events.
Thanks, -Pierre