[alsa-devel] USB Audio questions

[Pierre-Louis Bossart]

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