[alsa-devel] USB Audio questions

[Pierre-Louis Bossart]

Hi Daniel,

> > - 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.
> 
> You cannot use more than 8 subframes per ISO urb, that's what how USB
> is designed. What exactly did you do in you test? Did you increase
> MAX_URBS?

Can you point to a section of the spec where this restriction is
mentioned? Playback works fine with a larger buffer size and less urbs.
If indeed there was such a restriction, then why make does the module
take a parameter to change the max packet number of urb in card.c?

module_param(nrpacks, int, 0644);
MODULE_PARM_DESC(nrpacks, "Max. number of packets per URB.");

To make this work, I increased MAX_PACKS, MAX_QUEUE. See attached
(ugly!) patch. 

> Just to be sure - you're talking about the driver in sound/usb/caiaq,
> right? After a short comparison, I'd say both the caiaq driver and the
> generic driver do more or less the same in regard to the .pointer
> value, as for the output stream, they both increase their internal
> counter when the packet is prepared, shortly before it is submitted to
> the host controller. Increasing the number of URBs. Admittedly, this
> approach is questionable, as a larger number of prepared output
> buffers will actually cause the client believe that more data has
> already been written already. You could try moving the hwptr_done
> increase statement into the retire callback (which is the first place
> we get to know about packets that have been sent to the device)?

To really have a good video synchronization i'd need the ability to
query the number of audio bytes/samples transmitted whenever the video
renderer queries the pipeline clock. That makes A/V sync completely
independent of the sampling rate and the buffer sizes (just like for
HDAudio and most I2S outputs). This information on bytes transmitted is
probably available at a lower level (DMA, etc). If the audio time only
evolves in steps of 8ms, this is a deal-breaker for me. Having a delay
information in terms of ~1ms steps would be enough.

> > - 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.
> 
> Can you show a patch?

Included in the same patch below. I only modified the allocation. It's
ugly as can be, since I don't really prealloc anything. Looks similar to
what is done in your CAIQ code, except that I am a much worse part-time
programmer...
-Pierre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb-plb.patch
Type: text/x-patch
Size: 5873 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20110815/e51d32cc/attachment.patch