Moin Thorsten, *g*, jup, aber, "blocked" wunderte mich. 40ms sind natürlich eine recht lange Blockade im Verhältnis zum 1ms Framing. Ich habe mich mit der MIDI-USB Klasse noch nicht so wirklich auseinandergesetzt, daher hab ich die SysEx Geschichte noch nicht probiert. Im Laufe von 1-2 Monaten wird das aber auch noch akut werden für mich, je nachdem wie ich mit meinem Projekt vorankomme. Aber Fragen weiter: 1. Wie gross sind die Datenpakete, die du sendest, in Bytes (also die Endpunktpuffer)? 2. Wieviele Pakete gehen pro Frame in welchem Modus (iso, bulk ... ) rüber? 3. Wird dein Gerät als Teil der MIDI-Geräteklasse verwendet? Es klingt aber so, als ob das Problem tatsächlich auf der Controllerseite liegt. Hast du jemals unter Windows einen "Error 30" bekommen? Meines Wissens werden die Pipes unter Windows als Streams oder Filehandles gehandhabt. Bei mir brachten Versuche, 0 Bytes von der Hostapplikation aus der Pipe zu lesen (wenn eben keine Daten anlagen) einen Abriss der Verbindung oder erzeugten wahrscheinlich auf Kernelebene (da das System ausgelastet war) diese Timeouts. Auf dem Controller selbst hatte ich keine Probleme. Abgesehen von der Control-Pipe (EP0) darf pro Endpunkt nur entweder IN oder OUT Übertragung aktiv sein. IN/OUT an einem Endpunkt geht eigentlich nicht?! Wie sieht denn dein Device Deskriptor dafür aus? (oder wo bekomme ich denn die aktuelle Firmware, an der du arbeitest?) Die UOWN Flags garantieren offenbar nicht, dass der Puffer nach Wechsel des Zugriffsrechts auch übertragen worden ist, das musste ich feststellen. Wie ich eine erfolgreiche Übertragung von der SIE überprüfe, hab ich noch nicht herausgefunden. Was sich mir auch nicht erklärt ist, wie ich abfange, dass -während- des Pufferkopierens an den EP* eben die UOWN Bits nicht gesetzt werden. Microchip lässt sich da nur sehr dürftig drüber aus... Ist während des Timeouts denn generell gar keine USB Kommunikation mit dem Controller mehr möglich (hängt die SIE?)? Vielleicht kommen wir ja weiter :) Viele Grüsse, Claudio