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 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
------------------------------------------------------- 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
