On Sun, 11 Oct 2009, Steve Calfee wrote:
> Hi, I hate to throw another issue into this, but I have done userspace
> audio drivers via usb devices in the past and I think Linux does it
> wrong. Since you are dealing with scheduling (although not with ohci
> and uhci which have similar issues), I think it is germane.
>
> If you try a test and slow a host down that is feeding audio, Linux
> will put in a gap (large pop) and then continue with the data. But a
> persons ears are very sensitive to the music timing and it seems like
> the system stutters. This means that the music is going along and then
> there is a pop, a pause and then it picks up again with the original
> music and misses the beat. I believe it should be music, pop, gap, and
> then the music continues as if there was no gap.
>
> I have looked at the USB 2.0 spec and while somewhat vague, section
> 5.12 it says:
> <quote>
> In an isochronous communication system, the transmitter and receiver
> must remain time- and datasynchronized
> to deliver data robustly. The USB does not support transmission retry
> of isochronous data so
> that minimal bandwidth can be allocated to isochronous transfers and
> time synchronization is not lost due to
> a retry delay. However, it is critical that a USB isochronous
> transmitter/receiver pair still remain
> synchronized both in normal data transmission cases and in cases where
> errors occur on the bus. </quote>
>
> What I think this says and what I think matches the definition of
> isochronous transfers (constant time, not guaranteed delivery) is that
> 1) for an iso transfer with either startframe = nextframe
> 2) or with the iso_asap option set,
> Linux should discard whatever frames were "late" and could not be
> scheduled ie mark them done. People who do iso gadgets know that the
> data is not guaranteed, but they DO want the constant timing. Delaying
> a transfer by 10+ (u)frames because the host is slow for whatever
> reason violates the synchronization desired by human ears, eyes and I
> believe the USB 2.0 spec.
I rather agree with you, but your conditions 1) and 2) aren't quite
right. Here's the intention behind the current design:
1. For the first submission to a new stream, if ISO_ASAP isn't set
then we probably ought to pay attention to urb->start_frame, to
allow precise synchronization between streams. But the HCDs
don't do this, partly because it's hard for drivers to set
start_frame to a meaningful value. So essentially the HCDs
behave as though ISO_ASAP is always set.
2. For continuing submissions to an existing stream, the behavior
should depend on whether ISO_ASAP is set. If it is then the
URB should be scheduled for the next feasible slot, even if
that means skipping some slots. This is what Sarah is trying
to do (bearing in mind that for her, "feasible" means beyond
the end of the scheduling threshold).
3. If ISO_ASAP isn't set then the URB should be scheduled for
stream->next_uframe, even if that slot has already expired.
This is what you're asking for.
Unfortunately ehci-hcd does not support 3. uhci-hcd _does_ support it,
as does ohci-hcd (although I'm not sure that ohci-hcd's support is
entirely correct -- and in fact ohci-hcd doesn't support 2).
IMO it wouldn't hurt to fix up all three HCDs to behave consistently
(but then what about all the other controller drivers?). In addition
to the issues mentioned here, there is a question of what to do in case
3 when _all_ the packets in an URB submission are scheduled for slots
that have already expired. In this case we probably should fail the
submission with -ENXIO instead of accepting it and then failing each of
the individual packets.
Alan Stern
--
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
