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?
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?
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. 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.
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.
/* 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?
ret = start_urbs(capture, runtime);if (ret)return ret;}- return start_urbs(subs, runtime);
I think you have to wait for the first capture packet to be received before you can start submitting playback URBs.
Hmm, Felix - can you try this? I thought as long as the capture stream doesn't see any data, it just sends out zero-length packets, which should be ok. Or do I miss anything?
Thanks, Daniel