WWDC2003 Session 503

Transcript

Kind: captions
Language: en
[Applause]
good afternoon this is a gentle
introduction to USB 2 I have been asked
when the harsh introduction to USB 2 is
and I'm really hoping this is when you
don't get and not when you get to do all
of this so which is the backbone okay
sorry No ah that's the right button so
USB to what I'm going to talk about is
what us p 2 is as well as what us to is
not and also what it means to all of you
and a little bit about how it's done and
finally I'll finish up with a little bit
about high speed I saw kpi's so what is
USB to it is US v 2 but it adds high
speed it is the USB to it compatible
with the USB 1.1 specification it
includes almost everything in the USB
1.1 specification it's almost exactly
like the USB that you all know and love
but it adds the high speed this is high
speed yeah it will transfer data at a
raw bit rate or 480 megabits per second
how fast use 480 megabits you ask well
it's 40 times faster than then USB 1.1
full speed and 40 times faster so how
fast is that imagine I presume you're
all going to be going to our our
plugfest on the campus on thursday
evening so you're going to go out so
you're going to go on the bus it will
take about 40 minutes to get to good
Pitino's if that was a high-speed bus
though it would take you one minute so
you can see it's quite a lot faster okay
what uspq is not you
p 2 not us p 2 is not the same thing as
high speed and also USB 2 is not
inefficient there's a lot of confusion
out there in the marketplace
particularly us p 2 and high-speed USB 2
is not a synonym for high speed a USB 2
device can be high speed it can be full
speed it can be low speed however
recently there has been some confusion
about USB to host if the computer says
that it's USB 28 must support high speed
there's no getting around this if the
computer says that is USB to you can
plug in a high-speed peripheral and you
can get 480 megabit per second
communication going okay so that USB 2
includes the full and load speeds that
you're already familiar with these can
be called classic speed although as we
already use classics or other things
it's not really a word we like either
use also the USB the USB implementers
forum the governing body of all this
frowns on you confusing us v2 and high
speed you should not say if you have a
full speed USB to peripheral that it's
USB to you should say that it's just us
be if you were to say that say you've
had a printer and you said on the box
that it is USB to the user will have a
expectation that they plug it in and it
will run faster than the previous USB
printer it won't the views will be upset
you'll get support calls so don't do
that sort of thing its leaves all sorts
of marketing tricks we'd really like you
to not do also USB 2 is not inefficient
there's also some confusion about this
out there USB to the high speed and the
full in low-speed communications are
segregated they never share the same bus
so the full and low speed communications
don't get in the way of the high-speed
communications
there is a theory out there that if you
plug a single USB 1.1 device into a USB
2 system every high speed device on the
system slows down this is not true it is
absolutely not true at all we try and
dispel myths like that there is also
some performance tweaks in US v 2 to
make it work even better than it did
before the bolt packets now all of them
are now 512 bytes instead of the 64
bytes or less what they were previously
this reduces the overhead of protocol to
data so it will run faster and then
there's also things like the niet
handshake and the ping protocol
previously in USD one if you wanted to
send data out to a device and it
couldn't accept it the host would go out
and data and the host would say it would
receive the data and say sorry I
couldn't actually deal with that oh well
and then you'd have to continue sending
all this data until it could and this
could use as an awful lot of bandwidth
doing nothing now the device can say you
send the data out and the device will
say yes thank you i got that data but I
don't have any space for any more it
will say niet as a handshake now niet
actually just means not yet is nothing
to do with the Russian words which looks
similar so in this state the host will
now not speculative send data to the
device it will instead send pings thing
do you have any space of data and if the
devices Mac no I don't all the device
will say ACK yes I do and then you can
scary on sending data so you're not
constantly using up bandwidth doing
nothing ok what does it mean to you in
this case if you're a device developer
if you have a classic speed full or low
speed device and the answer is very
little if you want to make your device a
USB to device for some reasons all you
need to do usually is to change the
version number in the device descriptor
instantly you're a USB to device however
you should be sure to conform to the 1.1
spec because you should be sure to store
requests that you don't know and in
particular usb2 defines a new descriptor
the device qualify descriptor this is
used by the system to ask the device
what can you do if you're plugged in at
the other speed if you if you're a full
speed device you don't support this
because so that you don't support high
speed there is no other speed so if the
system asked this and you gave the wrong
reply the system may think that hey it's
capable of working at the other speed I
shall tell the user plug it into a
different port it will work better the
user is confused so be sure to store
requests that you don't know about you
should be doing this already whoever
does we don't know that sorry ok and a
slight modification is the aiesec
endpoints now must use no data by
default previously this is a very good
idea and the common practice that in the
unconsidered state or in the initially
configured state all the endpoints in a
nighthawk interface would have zero
bandwidth you would then configure it to
use more bandwidth as you go along this
stops a device which is actually plugged
in but idle taking up bandwidth so the
user will plug in a device not use it
plug in the video camera he wants to use
is that oh there's no bandwidth
available the other one is using it even
though the user isn't so be careful with
bandwidth and in particular it's now a
specification that you should not use
any bandwidth by default there are also
some changes to the low speed cabling
requirements if what's written on the
slide actually makes any sense to you
you should be sure to go read chapter
six of the spec and particularly you
should be sure to read the second half
of chapter 6 inspect because the
relevant parts in the first half don't
mention this but the ones in the second
half do now well ok what does it mean to
device developers you have a huge
opportunity you can make your device
work much faster users like this
and by much faster I mean that
transferring and safe or isochronous or
interrupt devices they can now have 24
megabytes a second go if you the obvious
candidate for this sort of thing is
video video usually uses megabit so I
should convert to megabits temporarily
which gives you 183 megabits per second
to use for your video and if you
consider that DV is standard 25 megabits
you have plenty of space for DV
uncompress DV is 125 megabits you can
use uncompress TV you can use your
imagination as to what else you want to
put in all this bandits that you have to
use also both runs much faster now 2224
megabytes per second is pretty typical
transfer rates for bulk so typically now
hard drives go a lot faster and users a
very happy pilot the transfer rate for
bulk is mainly constrained by the host
controller so different host controller
implementations in future may go faster
we think that 30 25 to 45 Meg's and
thirty-five to forty megabytes a second
is not unreasonable for future
controllers in fact I've seen an early
version of one recently which actually
looks like it could manage 39 megabytes
if I could find a hard drive fast enough
to keep up so what does it mean to drive
the developers I presume there's a lot
of driver developers out there hopefully
very little we're here to make your life
easy and for most of you you should do
nothing and it will just work this is
USB once you've got over the fact that
it's running high speed if it even is
running high speed all the rest of the
protocols or more or less the same as
they work on are the same as they were
before with the exception of package
sizes and whatever so in general you
should not care how fast your device is
running just transfer the data is fast
is it going to be thankful that it comes
in that fact don't worry about it
the exception to this of course is i
sock if you're doing i sock everything
has changed all the timings are
different now instead of the 1 1 1
millisecond frames that you had before
you have 125 microseconds micro frames
and you put together eight of these and
you have a good old tradition
traditional frame at one millisecond so
all your timings now have to be in terms
of micro frames not frame if you're
doing hi to be that is of course and in
each one of these micro frames you can
transfer up to 3k of data that adds up
to the twenty four megabytes I'd
mentioned earlier so how is all this
done on the bus we use a new controller
standard the enhanced host controller
interface this is a companion to the
open host controller interface which
runs full speed and high speed low speed
as we did previously there is support
for this enhancer a new driver the e-hdi
driver the e-hdi only works with high
speed as I mentioned the speeds are
segregated there'll be more on this
later so the e-hdi is dealing there
solely with high-speed transactions it
needs something to help it with the full
and low speed it actually has companion
controllers which in our case will be
ohci controllers like you used it and
also how is this done you have all these
speeds going on at once and they need to
be segregated the answer is Magic hubs
and there's going to be Morton roads is
going to be telling you a lot more about
those later but these are really
complicated beasties they've got most of
our host controller in them because they
have to translate between high speed and
full and low speed so how are you going
to do it first of all you need some
hardware which supports USB to
high-speed you can either buy one of our
lovely new Macintosh g5 or you can get
yourself a pci card or a pc
and plug it into your existing hardware
then you need some software you need the
version the USB family we have in
Panther this will enable high speed the
version number of the software is now to
point out we reserved the number to
point out a long time ago so that no one
will ever get confused between USB spec
2.0 and USB software to point out
there's been plenty of that sort of
thing the pattern we didn't want to do
it as you notice we've almost run out of
some version numbers are up to 1.99
already so it's a good job we did it now
okay when writing your driver I suggest
that you first of all do it full speed
like you're used to and then plug it
into a high-speed port and it will just
work and you'll be happy and like I say
we make it easy for you however if it
doesn't work this may be where the harsh
introduction to USB 2 is so be careful
okay tools you might use as may have
mentioned before that i think a USB
analyzer is a really useful thing to do
USB software with and it still is a
really useful thing to us we saw slowest
now if you're doing high speed
development you should really get
yourself a high-speed analyzer the usual
suspects make high speed analyzers
Katzie has the adviser catalyst has the
SBA 20 data transit has the pod for
their machines they have pods for every
sort of bus imaginable and i'm sure
there's more out there and I didn't mean
to leave them off the list okay now I
want to tell you a little bit about high
speed i sock as i mentioned before high
speed i sock is different the driver has
to know that it's different the device
has to know it is different say the
timings are different you have 125 m
micro second micro frames instead of the
one millisecond frames and the amount of
data you can transfer in any micro frame
is increased the 3k there is one saw
wrinkle in this is that now the
frequency of a night up transaction does
not have to be one you don't have to do
one every micro frame or one
reframe as you used to you can now
specify two or four or 16 or whatever
however we haven't seen any devices
which do this so we have not implemented
that yet if you have one we'd love to
hear from you okay okay habit having
said that high speed lights off these
different height read eye sockets also
the same and that we recycle the old 80
is use exactly the same api's we just
treat the parameters you send us a
little differently so i said high speed
i sock is different from the devices
perspective the packets on the bus are
different the timings are different you
have 125 microseconds micro frames here
diagrams of what the device fees if you
have a small transaction less than 1k
and nope you can actually go up to 1024
bytes where you can only previously go
up to 10 23 it's still just in one day
20 packet I could always used to be
however if you need more data than that
in a micro frame you send multiple
packets of suitable size to add up to
the size that you want it will say if
you're sending data out you'll stay over
host will say here's a packet there's
more to come by saying data one day 20
or data do data one day 20 it'll count
down like that similarly if the device
wants to send the host multiple data
packets if your 1k or less it will just
send the single data packet like you do
always it if it's more than 1k you send
is a multi multiple data package the
device will say there's more to come
there's more to come oh that was it and
you got you know one or two extra
packets that's encoded in the the
package that identifies sent with ease
and say interrupt will also allow you to
do 3k of data per micro frame but it
uses the same old data zero data one
alternating pigs that it always did okay
the high-speed is our KPIs as i said the
api is you
are the same as they were previously the
interpretation of some of the parameters
is different here you see a typical
aisaka API read I supplied a sink and
the first thing to note the things to
note early wants the parts highlighted
in orange and first a note is the frame
stock now frame start have not changed
even if it oh sorry i missed something
out there whereas previously you had
frames it's now you should consider
these to be transfer opportunities where
a API said frame you should interpret
that as saying you know have a transfer
opportunity whether it a transfer
opportunity once a millisecond or
transfer opportunity once the micro
frame so as I saying the frame start
however has not changed a high speed I
sub transaction starts on a frame
boundary not on a micro frame boundary
next the num frame is now the number of
transfers you want to happen either a
number of frames for full speed or a
number of micro frames for high speed
and finally the frame list now specifies
the list of transfers that you want to
happen either in frames or in micro
frames for high-speed and there is also
a new API get frameless time which
actually tells you how long your
transfer opportunity laughs either 125
microseconds or a thousand microseconds
so you know what the timing should be or
in effect whether you're running full
speed or whether you're running high
speed okay so in summary USB 2 is USB
but it will run faster if it's high
speed it as a high-speed host and if
there's a high-speed device but most of
the time it looks just like the USB you
always knew and loved as I say USbut to
is just like
speed if you're not a high-speed device
and don't worry about the speed if you
do not have to just transfer the data
and don't worry about it you do need to
worry about the speed if you're doing i
sock that and say the high-speed i sock
api's are different we use the same AP
is that we reinterpret some of the
parameters and with that I should turn
it over to roads thank you very much ok
I'm going to talk a little bit about USB
2.0 hub the USB implementers forum
worked very hard to make sure that USB
devices just works no matter whether you
were on a an old USB 1.1 bus or on a USB
2.0 but and as Barry said however the
data traffic is actually segregated you
do not have full speed and low speed
data on the same wire as high-speed data
traffic and the way they do this is by
making the hub's much more complex than
they used to be and you may need to pay
attention to some of that complexity so
these USB two hubs this is where all the
magic happens this is where the
segregation between the high speed and
full speed or low speed data occurs the
root hub the hub attached to the actual
CPU on the pci card or built into the
motherboard or what not is special
because it actually every root hub port
in a high-speed USB 2 system is actually
electrically connected to two different
USB buses and ehci bus and an ohci bus
and the ohc i would be called the
companion controller and you may have
one companion controller for a number of
root hub ports or you may have a
companion controller for each root hub
port now most of this is transparent to
driver writers because
is the driver the drivers don't really
care too much about what's kind of of
hosts are on the exception would be the
hub drivers which do need to know
whether the hub is attached to a
high-speed bus running in high-speed
mode or to a full speed bus running in
full speed mode luckily Apple produces
the hub driver for Mac OS 10 and so you
wouldn't necessarily need to worry about
that now having this magic hub can cause
some problems if it's not configured
properly for example you may have a high
speed hub and if you plug it into the
root hub of your computer it runs in
high-speed mode if however you plug it
into a keyboard hub or a display hub
that is a 1.1 hub your high speed hub
has now become a full speed hub and this
can cause some confusion if you have
high speed devices attached to it you
want them to work in high-speed mode
because once you once a hub is running
in full speed mode or low speed mode
well full speed mode then all downstream
devices of that hub have now become full
or low speed mode devices now the
segregation that happens between the
high-speed bus and full speed and low
speed devices happens in something
inside the hub called a transaction
translator now these transaction
translators there is at least one of
these in every high speed hub and in
most high speed hubs that I've seen on
the market today there is exactly one
transaction translator however it's
possible to have a transaction
translator on every port of a high speed
hub and this produces a much more
complex hub but at the same time allows
some benefits you can have one full
speed controllers worth of bandwidth for
isochronous and interrupt end points on
each transaction translator which means
if you have one transaction translator
and a high speed hub you have one full
speed controllers worth of bandwidth in
that hub and if you have a 1 t-t purport
in a hub you can have one full speed
controllers worth of bandwidth
each port of that hub so multi TT hubs
can have more full speed I saw devices
for example attached than a single TT
hub would be able to have again the root
hub being special does not use
transaction translators at all what
happens is when you plug in a full speed
device to a root hub port the high speed
controller sees that it's a full speed
device and electrically disconnects
itself from the port and passes the
connection over to the companion
controller and that device is now
running on an ohci controller these
transaction translators in the hub are
therefore store and forward units for
what are called split transactions now a
split transaction essentially is a
transaction where when the host wants to
talk to a full-speed device or a
low-speed device it transfers
information to the hub to which that
device is attached in high-speed mode
the hub stores that information buffers
it up and then transfers the the
information to or from the full speed or
low speed device separate from any
activity happening on the high-speed bus
at this this transfer occurs in to spark
to two parts called start split and
complete split and in between a start
split in a complete split which is the
information going to and from the high
speed hub the there can be more
high-speed activity happening while the
hub is doing full speed or low speed
communication with the downstream device
now this can this works very nicely and
allows you to plug in devices into a hub
without really paying much attention to
it but it can have some significant
performance issues and you probably
should be aware of these here so here's
me show you graphically why that occurs
while you can have some performance
issues let's say that I have a host and
I have a low of
speed hard drive attached to a high
speed hub and the host needs to send out
a data package of this hard drive and
it's an out packet from the host to the
hard drive so what happens is first the
hosts in the start split command to the
to the hub saying I have a a packet a
data out packets destined for this hard
drive it sends the out kid to specify
that it is an out packet sends the data
64 byte data packet for example and
receives an acknowledgment from the high
speed hub that that data was
successfully received however that
acknowledgment is that it was received
by the hub not that it was received by
the device then the host and the hub or
the host and other high speed devices
can continue to talk while the hub
starts it's transferred to the device
itself so it sends the same outbid to
the device it sends the 64 byte packet
to the device which takes significantly
longer at this point and it receives an
acknowledgement from the device that
everything was received successfully now
the hub remembers that acknowledgment
and says okay at some point the host is
going to ask me whether the device got
the data or not so when the host is able
to do so it sends a complete split kid
followed by the output saying i want you
to complete the last out transaction i
did and the hub is able to then
acknowledge that transaction so that
completes what used to be an old
fashioned out data ack packet but it
takes a little bit longer and the time
between when the full speed device
acknowledges the receipt of the data and
the beginning of the complete split
transaction can depend on what other
activity is happening on the high-speed
bus and because of this it causes some
significant delay in or can cause
significant delay in these in this data
and the upshot of this is that a full
speed hard drive for example attached to
a high speed hub can end up functioning
to the point where the actual throughput
to the drive is half what it is if it's
a
attached to a full speed bus now some
hubs as I mentioned earlier high-speed
hubs have a single TT and some have
multi TTS and as I mentioned each
transaction translator essentially is
the full speed buck so this is
especially important for people doing I
sock work with these hubs because let's
take for an example if you have a camera
that transfers 980 bytes per millisecond
frame it's a full speed camera well if
you have two of these cameras and you
try to plug them into two ports of a
single transaction translator hub only
one of the cameras is going to work
because that's going to saturate the
full speed bandwidth available to that
hub if the hub has multi TTS and you
plug a camera into each of two ports
each port has its own full speed
isochronous bandwidth and both cameras
can work a more likely example might be
a camera with a microphone for input and
a pair of USB speakers for output all of
which use isochronous bandwidth and so
with a single TT hub you may have a
difficult time or have reduced quality
of your video input or output because
you're trying to share the bandwidth
amongst all the devices whereas with a
multi TT hub you'd be able to plug both
the camera and the speakers into two
separate ports and they each have their
own bandwidth so it's fine multi TT hubs
also allow for better throughput with
bulk devices as well now I have
mentioned before that the root hub is
different because we have these
companion controllers so there's no need
for the transaction translator again the
ehci driver if it exists in the system
determines that oh this is the full
speed device I need to switch it over to
the companion controller and it
disconnects itself from that particular
port so no split transactions are
necessary what ends up happening is you
you you have a completely separate ohci
controller running your full speed low
devices and you get the same performance
as you do today on a full speed ohci
controller so in summary split
transactions allow for a seamless
transition from USB 1.1 two USB 2.0 your
full speed low speed devices just work
you plug them into a hub and everything
works great however you can end up with
some performance issues which you might
want to be aware of and any performance
critical full speed devices may want to
consider somehow telling the user to put
the device on an ohci bus one way to do
this for example would be lets say you
have two ehci ports on a computer or
three or four for a pci card or whatnot
you might plug a high speed hub into one
port and a full speed hub into another
port and have all the high speed devices
living on the high speed hub and all the
full speed devices living on the full
speed hub because a full speed hub will
provide data transfer on the full speed
ohci bus and a high speed hub will
provide these transfers on the
high-speed bus so with that I'm going to
turn it over to Fernando urbina and he's
going to talk about the new API Thank
You mr. Rhodes we're going to leave us
beat the point 0 outside for a little
bit now and talk about what we've been
doing since the last time we've met with
respect to adding API to our family
we've added both colonel and I o USB
library updates and on request from
multiple developers we finally have a
way to get the version number of the
family and the USB library
programmatically instead of having to go
by hand to get the cs bundle version and
all that stuff so that is available to
you we did add like very mentioned a
couple of USB 2.2 get the frameless time
whether it's 125 microseconds or a
thousand microseconds and the other one
is to get
the buzz micro frame number and actually
this 64-bit value and quotes both the
frame number and the micro frame number
at the time that that the call is made
and just like the regular bus frame get
buzz frame number it is time stamped so
that you can know when it when we
exactly got that frame number one
request that we've had for a long time
as well was to have a more
straightforward a p.i to recover from a
from a stall presently when you get a
stall you have to clear the data toggle
both on the controller and on the device
and this involves having to issue a
device request to your device with a set
feature and point out blah blah blah
blah blah now you have this clear pipe
solve both ends that will do that for
you and so that will make your life
easier we also augmented the isochronous
api's to help you and us manage the
bandwidth better one of the big
differences however since we introduced
this API is that when you create an
interface which in turn creates the pipe
objects for your endpoints previously we
would fail that call if there was not
enough bandwidth to create the pipe with
these new api's we will now create the
pipe even if there were there is not
enough bandwidth and so your PI to
actually have zero bandwidth allocated
to them so you have to be able to
realize this and undo something
appropriate like allocating banquet for
them these are the new API is the first
to the get bandwidth available and the
get em point property are unique in the
sense that you don't have
have the USB interface open in order to
make this call bandwidth available will
it's pretty straightforward it just
tells you how many bikes are available
in in in the bus the get em point
properties will allow you to inquire of
the different alternate settings of a
particular interface to see how much
bandwidth they would use so typically
you would get the bandwidth available
iterate through all your alternate
settings pick one that that has a lower
amount of bandwidth and then called set
alternate interface and this call is not
really new just here for completeness to
create that interface and allocate the
pipe objects then very importantly you
should call get five properties on that
eye chakra notes endpoint or a token of
five objects and make sure that the max
packet size for that endpoint is not
zero if it is zero it meant that even
though we have told you that there was
bandwidth available earlier somebody
might have come in and grabbed that
bandwidth away from you and it's not
there anymore so you should really make
sure that once your bikes are created
once again there is enough bandwidth for
them finally we're back to par with our
mac OS 9 implementation in the sense
that we have a set by policy api and
this essentially allows you to return
bandwidth to the system if you know that
you're never going to use the amount of
battle bandwidth that was specified in
the alternate setting the granularity of
the alternate settings in a in an area
phase depends on the whim of the device
manufacturer and you might know that
you're not going to use all that because
there's never going to be a case where
the device is going to send that data so
be a good citizen and call set by policy
and return that
bandwidth back to us for ten point two
point three we added some new API that
I'm going to talk about now these were
trying to solve what I call the latency
problem what is the latency most of you
are probably aware that Mac os10 that
time between when the hardware
transaction completes on the bus on your
callback is called varies sometimes it
comes right away but sometimes it can be
delayed for you know 80 milliseconds or
more there's the callback happens on the
i/o USB work loop and there are other
threads that run at a higher priority
than that work loop and if they're doing
work your callback will be delayed this
presents a problem in in in some cases
but you can work around it like you have
gone in Mac OS 9 and in previous
versions by keeping the ISO can point
busy and having multiple transactions so
that even if your callback is delayed it
doesn't matter because you have already
scheduled a transaction to start prior
to your callback being called so that
that's great and that works very well in
most cases however sometimes there is a
problem the low latency scenario that
some developers came and talked to us
about was as follows and this is an
example of one of them you have for
example some USB input coming into the
device and into your computer you do
some processing some audio processing
effects whatnot and then you send it out
to the USB speakers at the same time
obviously there is a listener that is
hearing what the output from your input
devices from the guitar in this case and
also
he's obviously listening to the output
from the speakers now if this is the
delay from horned I guitar sound wave
gets to the listener and from when the
speaker some ways get to the listener is
greater than 8 milliseconds the listener
is going to realize that something is
out of whack that you know and it sounds
bad quite obviously if we have callbacks
that delay for you no more than a 10
milliseconds we wouldn't be able to do
that so we thought about it and we came
with the following solution we realized
that this being USB and isochronous USB
especially the data from the device was
in the user's buffer as soon as the USB
controller completed that frame however
we lacked one critical piece of
information that was not in the buffer
in fact it's in the USB controller and
that is how many bikes were actually
transferred isochronous data varies in
in the amount even though you ask for a
certain amount of data it can transfer
more or less and so you need to actually
know how much data was there however
realizing this we we knew that then the
client could go and peek into the buffer
that they gave us and get that data at
the at the expected time if only they
had the appropriate number of bytes that
were transferred in that frame so we
augmented the frameless structure to
actually have a time stamp and we
decided to update the actual number what
it's called the f are actual count at
primary interrupt I'm now doing
processing a primary inner of time is
sort of dicey because you are preventing
any other thread from
running at that time so we really have
to do some minimal processing at that
time and what we do is we look through
our structures get the number of bytes
from the controller update the frameless
and and get out your callback will still
happen at the same time that it's
happened in the past however since you
know when the data was going to be there
you can go and look at your data buffer
and at your frameless buffer and know
how many bytes were actually transferred
so there are four new calls for these
low latency transfers the first two are
just for userland drivers and the the
last two are the read and write api for
both user and kernel driver we thought
it was a good idea to have the i/o youth
be library manage your buffers so you
have as a client in user space you have
to call in and give us the information
for how big to make the buffer
essentially you don't have to have just
one whole buffer for your whole data you
can have multiple buffers for each
transfer if you want you can manage that
yourself however when you do finish the
transfer you need to call us back so we
can release our buffers and we can
inform the colonel entities that those
memory descriptors are no longer being
used again a typical API for for the low
latency read i sock is that followed you
can see in the highlight their that
there is there are two changes one is we
have added added this update frequency
parameter that tells us how often you
want your bike transfer your frame list
updated if you want it to be updated of
course the granularity is one
millisecond if you wanted it to be
updated every millisecond you would
pasadena one if you wanted it every
eight milliseconds you would pass in an
eight if you have a 64 frame transfer
and you're only going to be looking at
it from user space or from kernel space
every eight milliseconds you should
really pass an eighth another one
because again we're taking processing
time add filter interrupt time and that
is preventing any other threads from
running on that processor at that time
the low latency I subframe list now has
as I mentioned earlier an absolute time
parameter that is time stamp at the time
that we process the the data that we
updated your number of bytes transferred
if we are updating more than one frame
at that time all those frames are going
to have the same time stamp this is used
by the audio drivers for example to
synchronize all their stuff and do their
magic this API Tsar detailed on on
header doc if you have any questions
feel free to ask them on the USB list
and will be will answer them as soon as
we can and again don't abuse the low
latency API I can't stress that you know
we got some pushback from the colonel
guys when we were adding these api's
because they don't want anything to
happen a filter in Europe time and if
you abuse it then performance for the
whole system is going to go down just a
quick note on the USB implementers forum
one of the big things going on right now
is that a video device class
specification is nearing release in fact
I think this week it's going to the 30
day comment period
at the end of which it will become a one
point no specification and will be
released you should go on to the
implementers website it's public for for
now and and take a look at it it
provides support for a wide range of
video devices everything that you know
video related that you can think of all
sorts of different payloads the we plan
to provide a class driver for some of
those devices I am the one working on it
these specification as I mentioned is
all-encompassing it's not it does not
specify whether that you need to be a
high-speed device or not of course for
some of the payload format like DV does
not make sense it it cannot work on a
full-speed device some chipsets right
now only do bulk transfers and there is
support for jos bulk transfer short
video of course you know you have the
pros and cons about that there's still
image support it's not limited to
receiving video on the host it's also
has support for sending video out to to
a device there's plenty of manufacturers
on the working group that are gearing up
to produce these devices so there's
something exciting that we're going to
see in the near future another change
from the implementers forum is that
they've now defined an interface
association the scripture as a change
notice to the USB to point out spec and
all this does is allows classes like the
audio class and the video class for
which this descriptor is now mandatory
to relate different interfaces to each
other
so that the system will know that when
you change something on the control
interface it also needs something to
happen to a streaming interface we are
looking at the ramifications of this and
expect to support this descriptor in the
future a quick debugging tools update
this year we gave up on giving a demo on
to machine debugging it didn't work for
the last two years we decided you know
we'll save face this time we do provide
login versions of the i/o USB family on
on the website on our website in the in
the in developer.apple.com the latest
versions actually I produce so that you
can install as a package the shipping
version as well as the login version so
you don't have to save the all the one
aside and use and copy it over later a
quick caveat if you do try to build
download the sources and build your own
io USB family do not try to boot with an
on strip version of the USB family and
actually when you use project builder
and build the project using the note
that the using that development build
style it will not strip the the binary
and you will get an unhappy Mac or
whatever the equivalent is now and you
won't boot and you'll need another
partition to Buddha caveat emptor in
order to generate symbols it seems to
change with very release of project
builder this is for that december 2002
developer tool this is a line that you
use to produce an on strip version it's
simpler now i have no idea what it is or
if this will work with xcode or butter
for the december tools use this of
course if you're going to do
machine-to-machine debugging
you have to change your default boot
arguments to what's on the screen so
that you can actually connect to it if
you don't you just get the multilingual
panic message finally I actually in
solving some bugs I was able to use the
chart tools which stands for computer
hardware understanding developer tools
there is actually a session tomorrow and
it it was it was very handy and actually
you wouldn't think that get buzzed frame
number could look out your machine just
a tiny bit of a ministry administrivia
the repository as most of you who access
before now know is not live anymore
however we are still open source one
Spencer is released we were we are going
to release the e-hdi driver for the ahci
controller you've noticed that things
releases are better now and very soon
after an update is released the tar
balls with all the sources are are
released on the web so I still encourage
you to go and unbilled it if you need to
to build their family to debugging
things so it's just a summer brief
summary of the API that that we've
changed again if you have any
suggestions for new IP is that you want
to that would make your life easier for
some reason or another you know we're
always on the list you know who we are
just send us an email and the only way
we're going to consider them is if we
know about them so feel free to suggest
that we're looking forward to the video
class pack and the repository is not
live anymore but we are and we're still
working and we're enjoying ourselves
these references are pretty much
unchanged from last year even though
some of of the of the documents have
been updated let's see
suspect there are technical notes on
debugging kernel panics if you feel like
doing that for some reason we still get
for you know persons just coming to
develop on my driver doesn't load and
you know I have that bookmark and always
fire it out on the list again the Oh
some sessions that you might want to
attend just you use your time transport
and go to godfreys a session yesterday
that's on a side of course is for the
DVD blah blah blah there's as I
mentioned the short performance of the
mission optimization session tomorrow of
course we are expecting you guys to come
to the feedback forum tomorrow as well
and on give us you know let us have it
finally on Friday we have a session on
the head manager and our force feedback
support so if you want to listen to me
again yeah bookmark your friday morning
session and you know our email addresses
again the USB list at least apple com I
I also monitored one or several of the
darwin lists and the first thing i say
when somebody posts USB question there
is go ahead and join the USB list and
you know your aunt your question will be
answered faster that way