Message: 1
Date: Thu, 13 Oct 2005 00:17:35 +0200
From: Fabian Renn <email@hidden>
Subject: Re: Usb Digest, Vol 2, Issue 226
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Hello Gordon,
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:
int cnt = 0;
while ( cnt < numTransactions ) {
while ( frameCnt < framesPerTransaction ) {
frameList[cnt][frameCnt].frStatus = 0;
.
.
.
}
cnt++;
usbCompletion[cnt].target = this;
.
.
.
cnt = 0;
while ( cnt < numTransactions ) {
pipe->Read( ... );
cnt++;
}
}
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
------------------------------
