the trick is not only to queue many frames, but also to queue more
than one transaction. This way you assure a constant stream even if
your kext doesn't get a lot of processor attention at one time. So
your code will look like this:
In the completion routine you just restart the transaction.
My best experience is two queue around 64-128 Frames per Transaction
and queue about 8 Transactions ( lots of frames ). This way the
system load will be at a minimum. If Latency is an issue for you than
consider using the LowLatencyRead/Write commands. They will update
the frame list right when a frame completes. This way a different
thread ( in my case i used a high priority thread ( see the VLC
source code for a good reference on how to create really cool high
priority threads ) ) can read out the data according to the frame
lists. Unfortunenateley, there is a bug in high speed isoc read
transactions that won't update your read frame lists ( this bug only
accurs for high speed read transactions ). The bug fix is due for
the next system update and is already out as a developer beta. So you
might want to grab that if you are doing high speed usb and latency
is a issue.
Greetings
Fabian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
