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