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. Thanks, Daniel -- 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
