On Mon, Aug 25, 2014 at 2:14 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote:
> Hi Clemens,
>
> On 08/25/2014 09:15 AM, Clemens Ladisch wrote:
>> Daniel Mack wrote:
>>> a) Linux snd-usb-audio currently pre-calculates the estimated packet
>>> sizes to expect from a USB device, and will only receive packets that
>>> have the expected size or are smaller.
>>
>> snd-usb-audio allows packets to be 25 % larger.
>
> Yes, but packets can't be larger than *that*.
>
>>> This can be worked around by setting the UAC_EP_CS_ATTR_FILL_MAX in
>>> the UAC2 endpoint descriptor
>>
>> The spec says about this flag (4.10.1.2):
>> | when receiving data from an IN endpoint, the Host software must be
>> | prepared to receive wMaxPacketSize bytes and discard any superfluous
>> | zero bytes in the packet.
>> | Note: This bit can only be used for Type II formatted data. The data
>> | stream must contain enough information (in a header) to
>> | separate the actual data from the padded zero bytes.
>
> Right, I've read this too, and we're not using Type II, so we don't have
> header information to tell us the real payload. The idea was to just use
> an 0 or 512 bytes approach.
>
>>> send 0-byte packets from agdev_iso_complete() if the time passed since
>>> the last completed buffer does not allow for another one to be sent.
>>
>> Audio Formats, 2.1:
>> | To indicate a temporary stop in the isochronous data stream ..., an
>> | in-band Transfer Delimiter needs to be defined. This specification
>> | considers two situations to be a Transfer Delimiter. The first is
>> | a zero-length data packet and the second is the absence of an
>> | isochronous transfer
>>
>> 2.3.1.1:
>> | The goal must be to keep the instantaneous number of audio slots per
>> | virtual frame, ni as close as possible to the average number of audio
>> | slots per virtual frame, nav. [...] If the sampling rate is a constant,
>> | the allowable variation on ni is limited to one audio slot, that is,
>> | ∆ni = 1. This implies that all virtual frame packets must either
>> | contain INT(nav) audio slots (small VFP) or INT(nav) + 1 (large VFP)
>> | audio slots.
>>
>>> This results in very stable timing behavior in my tests.
>>
>> But it increases jitter, and might not work with any other driver.
>
> You're right, that's also my concern.
>
>> f_uac(2) *must* implement some mechanism to control the clock, i.e., the
>> packet sizes. (And this is not part of the standard ALSA API.)
>
> The easiest is probably really to just calculate correct packet sizes
> and stick to them. After all, the actual clock is really arbitrary, we
> just have to pick something that is in the range of the sample rate.
>
> I'll cook up an alternative patch and do some tests with Sebastian off-list.
>
How about configuring bInterval and wMaxPacketSize to get the desired rate?
For ex, 48KHz/2/S16, we need 192bytes/millisec. So we set bInterval=1
(or 4 for HS) and wMaxPacketSize=192 for that configuration. For
44.1KHz/2/S16 we need 176.4bytes/millisec, so we set
wMaxPacketSize=178 and send packets of length in {176, 176, 176,
176,178} pattern.
Regards,
Jassi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
