[alsa-devel] USB Audio questions

[Pierre-Louis Bossart]

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