[alsa-devel] Need expert's advice - Fast Track Ultra (8R) dropping samples

[Clemens Ladisch]

Daniel Mack wrote:
> On Fri, Oct 15, 2010 at 09:23:15AM +0200, Clemens Ladisch wrote:
> > Daniel Mack wrote:
> > > > > I have an untested patch ready which should add support for implicit
> > > > > feedback, but I'm uncertain about the condition when to activate this
> > > > > mode.
> > 
> > For UAC2 devices, when the descriptors say so.
> > For UAC1 devices, never (because UAC1 does not have this mode).
> 
> Yes, but UAC1 also doesn't support other things like high speed
> transfers in the specs, still the Linux driver supports it, right?

Mostly with quirks.  Devices marked as UAC1 would not work in Windows
if they required anything not implemented in all more or less current
Windows versions; I don't know if any such device actually exists.

The Linux driver support is a default that is hoped to work with most
quirky devices, to reduce the amount of quirk code.  In the particular
case of UAC1 high speed support, I just added what the Audigy 2 NX
happened to do, because that was the device I had, and the extensions
to UAC1 looked plausible.

> I think we can interpret the ISO endpoint usage bits for this, and if a
> UAC1 device sets them, it should be ok for the Linux driver. Or is there
> any other detail in the spec we could use for judging?

For practical purposes, we cannot start the capture stream without it
being requested by a program when there is more than one possible sample
format/rate for it.

> > >  static int snd_usb_audio_next_packet_size(struct snd_usb_substream *subs)
> > >  {
> > > +		frames = min(capture->frame_count, subs->maxframesize);
> > > +		capture->frame_count -= frames;
> > 
> > This assumes that both streams are running continuously, and you have to
> > make sure to start them at the same time to prevent the frame_count from
> > overflowing or underflowing. 
> 
> The caputure stream must be running continuously, yes. Otherwise, the
> driver can't know how many data it should send.

If the capture stream was started some time before the playback stream,
the counter will be quite huge, and the driver will send lots of
maximum-sized packets, which will eventually overflow the device's
buffer.

If some capture packet gets lost due to an error, the playback stream
will try to compensate for that perceived lower rate.  Since this
protocol does not have sample counters, we cannot work around this; the
best idea probably is to stop the stream (xrun).  It's also possible for
a playback packet to get lost; we cannot do anything about that.

> But the counter can't actually underflow; if there is no more data to
> be sent, the counter will drop to zero, which makes the output stream
> send zero-length packets.

Using a default rate for the initial packets might make more sense.

(The audio output of the TUSB3200 chip will lock up if it gets several
zero-length packets, but that thing is full-speed and adaptive.)

> > In my UA-101 driver, I ensure that the
> > buffer fill level is the same for both streams by submitting each
> > playback packet with the same frame count as the corresponding capture
> > packet; but I'm not sure which algorithm is more robust in practice.
> 
> Yes, I do exactly the same in my proprietary driver for the Native
> Instruments devices, but it seems harder to implement in the generic
> driver. The problem I see with my current approach is that the jitter is
> higher - we now always send the maximum frame size or zero length.

This is called "blocking mode" in FireWire audio, and most FW devices
use it.  There the jitter doesn't matter as much because the packet
frequency is always 8 kHz.

> > > +		/* if this stream is in implicit feedback mode, start the
> > > +		 * capture stream now as the playback stream relies on the
> > > +		 * amount of data we see on the capture IN endpoint.
> > > +		 */
> > > +		if (subs->stream->implicit_feedback && !capture->running) {
> > > +			int ret;
> > > +			capture->ops.retire = retire_paused_capture_urb;
> > 
> > set_interface?
> 
> You mean usb_set_interface()? Why should that be neccessary?

To tell the device that the capture interface is supposed to send data.
Furthermore, any specification-compliant device has a zero-sized
endpoint, or no endpoint at all, in the default alternate setting.


Regards,
Clemens