usb_get_current_frame_number() returns the current frame pointer.
So at any time I can tell where abouts in that urb the currently playing frame is.
Now, I want to be able to detect over and under runs.
Heh. So does the HCD! And I'm not sure all of them do the same thing there, or that all the information needed for certain kinds of iso device drivers is available.
An overrun happens during recording, whereby the usb fills the urb, but then cannot find a new urb to fill next. If we submit_urb() in such a way that only a few frames are overrun, I should be able to detect overruns using.
(previous_urb->start_frame + previous_urb->number_of_packets == current_urb->start_frame)
If that is untrue, an overrun has occured.
I'm not sure what you're describing there. The HCD fills the urb's transfer buffer for IN, but the device driver does it for OUT. (Record to device...) But it's always the device driver's responsibility to make sure there's no period where a transfer attempt was missed (by queueing enough urbs). Normally, just submit one iso urb from each iso completion callback.
I assume (number_of_packets == number_of_frames) for isoc urbs.
Bad assumption, equivalent to "period == 1msec". Lots of different periods work; all are powers of two units, and sometimes the units are microframes not frames.
Now, I want to maybe find out how much overrun has occured.
number_of_frames_missed = current_urb->start_frame - previous_urb->start_frame - previous_urb->number_of_packets;
But we have a problem. What to do in WRAP_AROUND situations. e.g. current_urb->start_frame = 10 previous_urb->start_frame = 1000 previous_urb->number_of_packets = 30 How many frames were missed??
I know where this is going!
To answer this we will have to have access to the range of values the frame pointer can have, so can we add a new api call.
usb_get_frame_list_size(struct usb_device * dev);
Or how about just a dev->bus->iso_sched_frames? That's known to the HCD as it initializes. If it really needs to be a function, no point in having it more complex than that.
A similar problem occurs finding the underruns on playback.
I'd actually define overruns and underuns differently, and not paying attention to dirction (IN vs OUT):
- Schedule overrun means trying to schedule more than approximately iso_sched_frames into the future.
- Schedule underrun means falling behind in transfer rate, so the endpoint's queue became empty. (What you were calling "overrun" -- I think.)
That's distinct fom things like DMA overrun/underun, or buffer overrun/underrun -- which have different fault codes (in urb status) -- or similar faults with respect to where the ISO data is read/written by the USB device driver.
Summary: -
2 new api calls needed: -
1) usb_get_frame_list_size(struct usb_device * dev);
Returns the range of values that urb->start_frame can have. In order for us to calculated number_of_frames_missed.
How about dev->bus->iso_sched_frames?
2) usb_get_frame_ceiling(struct usb_device * dev);
Returns whatever this ceiling value is you descibe. I need more details on exactly how that will help me with establishing delay and avail values.
If that actually matters, I think it'd be better to determine it by experiment: how many urbs before you overrun? I don't think it'd be a win to settle on a model that's more extensive than "the software's limit can be less than iso_sched_frames" unless you're planning to modify each HCD to conform to tigher specs (and have some way a regression harness could test that).
- Dave
Cheers James
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
