James Courtier-Dutton wrote:
I have recently relooked at the uhci11d.pdf doc.
It mentions a table of 1024 frames. Each frame lasts 1 ms. So, it is possible to buffer up an entire 1 second of audio!
Not really. The UHCI driver puts a ceiling in place that's
I cannot find any mention of "ceiling" in the UHCI spec document.
Is it just the linux kernel UHCI driver that puts that ceiling in, and if so we need a new api call to get that value.
less than that, and there's lots of non-UHCI silicon. While OHCI would let you schedule even more frames than that, the EHCI code commonly uses 256 msec (less a ceiling).
The depth of the ISO schedule available on a given USB bus is not currently exposed in the API; don't assume that it's more than 256 msec. (That depth would be easy enough to expose, but nobody's ever needed that information.)
The UHCI hardware has a frame pointer which we could read and match against the urb's we send it. With some calculations I should be able to get a fairly accurate pointer (to nearest 1ms) giving me two resulting values.
All the host controllers have a frame number, and you can call usb_get_current_frame_number() to get it.
A "delay" value which is the time between the currently playing frame, and the time at which a new submitted frame would be played.
A "avail" value which is the amount of frames that are free to be filled in the frame buffer.
...
Are there already function calls to return this "delay" and "avail" values ?
No, but after you submit an urb you'd normally expect urb->start_frame to reflect when it's scheduled. (Though I think that for high speed ISO the units are actually microframes.) Given that and the current frame number, you could calculate those values -- given the ISO schedule size, which you can't currently know.
- Dave
Cheers James
So is the urb->start_frame valid as soon as submit_urb() returns?
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.
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 assume (number_of_packets == number_of_frames) for isoc urbs.
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??
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);
A similar problem occurs finding the underruns on playback.
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.
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.
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
