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. > 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. > 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. 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.) Regards, Clemens -- 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
