Thread-topic: Isoch read - kIOReturnIsoTooOld never seen on Leopard?
User-agent: Microsoft-Entourage/11.3.6.070618
One of my developers tells me that he never sees kIOReturnIsoTooOld returned
by an isochronous read on Leopard. However, if the read request is for a
time in the past, it is never scheduled. Because we don¹t get an error when
making the request, we wait forever for its completion routine to be called.
When we want to stop reading, we usually simply stop posting reads and wait
a little while for the reads to return on their own. Some of the reads don't
return, so we abort the pipe, and *still* some of the reads don't return.
We want to work around this by asking for the current frame number with
GetBusFrameNumber before posting every read, and ensuring that our posted
request is for some reasonable time in the future. This "should work"
assuming that the thread posting the reads isn't interrupted for any
significant time between the call to GetBusFrameNumber and the call to
ReadIsochPipeAsync.
Our question is this - how expensive is GetBusFrameNumber? We post many
isochronous reads per second.
Obviously we need to do some more investigation before possibly filing a bug
here. I haven't yet deliberately tried to schedule reads in the past to see
what happens.
Incidentally, this problem may have some bearing on a recent posting to this
list:
Date: Wed, 21 Nov 2007 18:42:31 -0500
From: Cobey Gatos <email@hidden>
Subject: Read Completions Under Leopard
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
I have written an audio driver that supports several USB 1.1
devices. When audio is stopped, the driver will wait for all of its
outstanding isoch reads to complete before moving on. I have had no
problem with this code on various systems and machines dating back to
OS 10.2.
I did some testing on an Intel iMac running OS 10.5.1 with the audio
device plugged into a USB 2.0 hub. I found that when audio is stopped
and I stop posting new reads and wait for the outstanding ones to
complete, the completion for the last read will not be called unless
I either unplug the device, or I add a pipe->abort call to my audio
stop routine. I do not have this problem when the device is plugged
directly into the computer's USB port, and I do not have this problem
on the same machine with the same hub running under OS 10.4.11.
I am curious if anyone has any insight into why this occurs, and if
there is any reason I shouldn't call abort() to flush out the pesky
read completion.
Thanks for your help.
Cobey
_______________________________________________
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
This email sent to email@hidden
