James Courtier-Dutton wrote:
Hello,
Are there any documents regarding how one should use USB ISOC endpoints in linux 2.6 ?
Did you look at the USB API doc you get by "make pdfdocs"?
1) set alternate interface then submit urb, or submit the urb on initialisation, then set alternate interfaces on the fly.
Submitting an urb to an endpoint that's not active is a bad idea ... set the altsetting first.
2) How many urb's should one use per ISOC endpoint. I would assume 2, one being filled by the application, while the other is being output by the usb hardware. Can one use just 1 urb? Should one use more than 2?
Use at least two urbs, or you can't guarantee streaming. Use more than two as necessary ... like if one of them stays out of the endpoint's queue for very long.
As for how deep the queue should be: take your system's worst IRQ latency, and make sure you always have that much traffic queued in the hardware. So with two URBs and 6 msec worst case latency, make each URB hold at least 6 msec of traffic.
Example (from my mailbox this morning!): high bandwith streaming worked fine with 4 msec queue depth, until IDE traffic kicked in. Then some IRQ latencies topped 5 msec, and streaming stopped. The queue depth wasn't deep enough.
There are folk with measurements there, and some kernels which offer latency guarantees, but most current ISO drivers start with queue depths of at least 10 msec.
3) Are ISOC urbs for IN and OUT endpoints linked in any way, or are they separate. E.g.
For linked: submit urb, while the hardware outputs isoc data from the urb, it also files the urb with recorded data and returns urb.
For separate: submit urb, hardware outputs isoc data, and then returns urb.
There's no synchronization between endpoints unless you provide it yourself. The USB spec has some information about the various rate feedback modes, I can't comment on how well they work with Linux.
I cannot find any documentation that might answer these questions, so pointers would be very helpful.
Kerneldoc, the USB 2.0 spec, and existing ISO drivers (audio, video) are good places to start. And keep a basic queue performance model in your head while settling on queue parameters.
- Dave
I will look at the kernel docs as you suggest. (just need to emerge jadetex first. :-) )
I have looked at existing usb audio drivers, but linux usb audio(oss or alsa) is fairly flakey at the moment, so I really want to know how the usb developers think it SHOULD be done instead of baseing my work on other peoples possibly wrong code.
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!
If I was to fill this entire buffer with 1 second, it would make sense to me if I could establish which frame was currently being played.
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.
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.
e.g. Currently playing frame 10, we already have frames 10 to 20 in the buffer. If an urb was submitted now, it would start filling from frame 20 onwards. Result: delay = 10ms, avail = 1024 - 10 = 1014.
Are there already function calls to return this "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
