Hi Clemens,
For playback, we know how many bytes we had submitted, so we could derive the current position from the USB frame counter, but for capture, we don't know the precise byte count until the HCD has looked at the descriptors.
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?
No, this information isn't returned earlier than the completion callback.
I am lost here, bear with my ignorance of USB... What is this USB frame counter and what would to enable its use, at least for playback where there is scope for lots of power optimizations.
Why more efficient? You cannot avoid double-buffering when a USB packet wraps around the end of the ALSA ring buffer.
What I had in mind is a case where the ring buffer is divided in separate periods, which would each correspond to an integer number of URBs/packets. This way there is _never_ a case of wrap-around and no need for memcpys. It's probably less generic than the current driver but a whole lot simpler/efficient.
- 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.
Please note that URBs are usually not completely filled. For playback, the driver makes URBs shorter so that they end as nearly as possible on or after a period boundary; for capture, we cannot predict sample counts, so the driver just uses one URB per ms.
Well I am precisely preaching for filling the URBs as much as possible to make things simpler for cases where latency doesn't matter. Of course for capture/speech cases latency does matter and I understand the need to do things differently there. -Pierre