---
title: WWDC2003 Session 503
framework: wwdc
role: article
path: wwdc/wwdc2003-503
---

# 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