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