On Tue, Aug 16, 2011 at 8:37 AM, Clemens Ladisch clemens@ladisch.de wrote:
Pierre-Louis Bossart wrote:
- Is there any good reason why the max number of packets per urb defaults to
8?
Not really. It is an attempt to compromise between interrupt frequency and the latency resulting from packet queueing.
Ah, I thought there is a limit of frames per urb that is the same than subframes per packet on USB. That's not the case then?
- 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?
Only the URB completion callback tells us about finished packets.
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.
Wouldn't it be possible to not count what we submitted but look at the playback packets that return from the HCD and move the hwptr there? That information is presumably closer to the actual hardware position than the time when we queue.
Daniel