IOKit / IOUSBLib

  • IOKit / IOUSBLib

    Bin ich der einzige, der dieses IOKit bzw. im speziellen die IOUSBLib total bescheuert findet?
    Ich kämpfe da jetzt schon eine ganze Weile mit, weil ich mir grad einen userland UVC Treiber zu schreiben versuche. Inzwischen mache ich auch gute Fortschritte.

    Was mich hier aber besonders nervt:
    Was soll dieses bescheuerte Pseudo-C++ Interface? Es nervt einfach nur. Seh ich das richtig, dass man im Kernelland ein echtes C++ Interface bekommt?

    Davon abgesehen, dass ich die Doku auch eher unangenehm finde, wunder ich mich jetzt, ob es keinen eleganteren Weg gibt z.B. alle Endpoints über alle Alternate Settings zu bekommen, damit ich mir hier jetzt konkret einen Isochronous EP mit passender wMaxPacketSize suchen kann.
    Was ich mache ist mir den gesamten configuration descriptor vom Device zu ziehen und den manuell, byte für byte, durchzugehen. Plus natürlich immer schön Endianess-Swapping.
    Irgendwie finde ich immer nur dort Abstraktion, wo ich sie grade nicht gebrauchen kann.

    Ich schaue immer gern Dinge aus dem Linux Kernel ab, und libusb sieht mir da um einiges schöner aus.

    Muss man das erst noch lieben lernen? Bin ich nur zu blöd?
    ♥C++

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Seh ich das richtig, dass man im Kernelland ein echtes C++ Interface bekommt?

    Etwas abgespeckt: Keine Exceptions, keine Templates, keine Mehrfachvererbung.
    Original von zermelo
    Muss man das erst noch lieben lernen? Bin ich nur zu blöd?

    Zu blöd bestimmt nicht. Lieben muss man es auch nicht. IOUSBLib ist in erster Linie ein direkter Zugang zu den USB-Konzepten ohne viel Tamtam. Dafür, dass USB per se ekelig ist, kann die IOUSBLib ja nichts. Ich hab' mir Wrapper für meine Belange gebastelt und ärgere mich nicht mehr darüber.
    Multigrad - 360°-Produktfotografie für den Mac

  • RE: IOKit / IOUSBLib

    Original von mattik
    Zu blöd bestimmt nicht. Lieben muss man es auch nicht. IOUSBLib ist in erster Linie ein direkter Zugang zu den USB-Konzepten ohne viel Tamtam. Dafür, dass USB per se ekelig ist, kann die IOUSBLib ja nichts. Ich hab' mir Wrapper für meine Belange gebastelt und ärgere mich nicht mehr darüber.

    Ja, das USB ...wundersam... ist, habe ich auch schon bemerkt. Eigene Wrapper schreiben hatte ich mir auch schon vorgenommen, muss man dann wohl auch machen.

    Den ersten kernel panic hab ich auch schon hinter mir. Und das aus dem userland heraus; schoen, oder?
    ♥C++

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Den ersten kernel panic hab ich auch schon hinter mir. Und das aus dem userland heraus; schoen, oder?

    Microkernel. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Bin ich der einzige, der dieses IOKit bzw. im speziellen die IOUSBLib total bescheuert findet?
    Ich kämpfe da jetzt schon eine ganze Weile mit, weil ich mir grad einen userland UVC Treiber zu schreiben versuche. Inzwischen mache ich auch gute Fortschritte.

    Was mich hier aber besonders nervt:
    Was soll dieses bescheuerte Pseudo-C++ Interface? Es nervt einfach nur. Seh ich das richtig, dass man im Kernelland ein echtes C++ Interface bekommt?[…]

    Meinst du das hier:
    de.wikipedia.org/wiki/Embedded_C%2B%2B
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • RE: IOKit / IOUSBLib

    Original von Amin Negm-Awad
    Meinst du das hier:
    de.wikipedia.org/wiki/Embedded_C%2B%2B

    Nein. Die haben einfach C genommen und versuchen das durch "Tricks" etwas Objekt-Orientiert zu machen.
    Siehe doku von bspw. IOUSBInterfaceInterface. Davon "abgeleitet" ist dann irgendwoe IOUSBInterfaceInterface245 und so weiter. Anstelle, das man jetzt schoene C++ Dinge machen koennte wie (Wunschtraum)

    Quellcode

    1. IOUSBInterfaceInterface interface;
    2. interface.open();
    3. interface.dosomething();
    4. //exception wird geworfen, dadurch wird "interface" geschlossen und wieder freigegeben

    Gibt es

    Quellcode

    1. IOUSBInterfaceInterface **interface;
    2. get_interface_from_somewhere(&interface);
    3. kern_return_t kr = (*interface)->dosomething(interface, ...)
    4. if(kr) {
    5. // immer wieder schliessen, was geschlossen werden muss,
    6. // freigeben, was freigegeben werden muss, etc.
    7. }

    Hier sind Methoden wirklich noch Funktionionen mit einem weiteren Parameter...
    ♥C++

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Anstelle, das man jetzt schoene C++ Dinge machen koennte wie (Wunschtraum)

    Quellcode

    1. IOUSBInterfaceInterface interface;
    2. interface.open();
    3. interface.dosomething();
    4. //exception wird geworfen, dadurch wird "interface" geschlossen und wieder freigegeben

    Gibt es

    Quellcode

    1. IOUSBInterfaceInterface **interface;
    2. get_interface_from_somewhere(&interface);
    3. kern_return_t kr = (*interface)->dosomething(interface, ...)
    4. if(kr) {
    5. // immer wieder schliessen, was geschlossen werden muss,
    6. // freigeben, was freigegeben werden muss, etc.
    7. }

    Hier sind Methoden wirklich noch Funktionionen mit einem weiteren Parameter...


    +pfui+
    Das ist ja wirklich hässlich.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Original von Amin Negm-Awad
    Meinst du das hier:
    de.wikipedia.org/wiki/Embedded_C%2B%2B

    Nein. Die haben einfach C genommen und versuchen das durch "Tricks" etwas Objekt-Orientiert zu machen.
    Siehe doku von bspw. IOUSBInterfaceInterface. Davon "abgeleitet" ist dann irgendwoe IOUSBInterfaceInterface245 und so weiter. Anstelle, das man jetzt schoene C++ Dinge machen koennte wie (Wunschtraum)

    Quellcode

    1. IOUSBInterfaceInterface interface;
    2. interface.open();
    3. interface.dosomething();
    4. //exception wird geworfen, dadurch wird "interface" geschlossen und wieder freigegeben

    Gibt es

    Quellcode

    1. IOUSBInterfaceInterface **interface;
    2. get_interface_from_somewhere(&interface);
    3. kern_return_t kr = (*interface)->dosomething(interface, ...)
    4. if(kr) {
    5. // immer wieder schliessen, was geschlossen werden muss,
    6. // freigeben, was freigegeben werden muss, etc.
    7. }

    Hier sind Methoden wirklich noch Funktionionen mit einem weiteren Parameter...

    Ah, okay, so habe ich das auch gemacht, bevor ich mit C++ anfing und das brauchte.

    Sind halt opaque Datentypen. Macht das RTE auch so, wobei es da keine Ableitung gibt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Original von Lucas de Vil
    Original von zermelo
    Den ersten kernel panic hab ich auch schon hinter mir. Und das aus dem userland heraus; schoen, oder?

    Microkernel. ;)

    Naja, Darwin ist ja kein reiner Microkernel.
    Uebrigends war, wenn ich mich recht erinner, sogar nur ein einziges Bit falsch, was dazu gefuehrt hat. Naja, und vielleicht die vorgeschriebene Reihenfolge der Befehle etwas vertauscht :)

    Original von hns
    Bei den MacPorts / Porticus.app gibt es libusb aus der Linux-Welt. Allerdings als "Legacy Release":

    Legacy release

    Latest version: v0.1.12
    Supported operating systems: Linux, FreeBSD, NetBSD, OpenBSD, Darwin, MacOS X

    libusb.org/

    Ich habe ein Projekt (DFU) aus der Linux-Welt damit portiert.

    Hatte ich auch schon ueberlegt, aber einfach nur portieren moechte ich den Linux code nicht (GPL stinkt, und so besonders schoen ist er auch nicht).
    Wie gut man jetzt ganze userland Treiber mit libusb schreiben kann, weiss ich auch nicht. Ich schau erstmal, ob ichs mit IOKit ohne zu grosse Schmerzen hinbekomme. Aber eine Ueberlegung ist es sicherlich wert, insb. wenn Du damit schon von Erfolgen zu berichten weisst.
    ♥C++

  • RE: IOKit / IOUSBLib

    Original von Amin Negm-Awad
    Ah, okay, so habe ich das auch gemacht, bevor ich mit C++ anfing und das brauchte.

    Sind halt opaque Datentypen. Macht das RTE auch so, wobei es da keine Ableitung gibt.

    Ja, es hat vielleicht seine Momente. Insbesondere, wenn man rein auf C beschraenkt ist. Das sehe ich hier aber nicht gegeben, und ein mehr oder weniger klassisches C interface (wie libusb z.B.) waere mir hier tatsaechlich auch lieber gewesen.

    Wenn ich das richtig sehe, ist die Ableitung auch eher "pseudo". Parameter sind ja alles void pointer.

    Ist vielleicht darin begruendet, das Objective-C frueher kein C++ konnte, man jedoch Objective-C Programmierern den Weg nicht...versperren wollte?
    ♥C++

  • RE: IOKit / IOUSBLib

    Jetzt könnte ich noch einmal Hinweise brauchen, weil ich irgendwie meinen Fehler nicht finde:

    Ich bilde mir ein, alles korrekt konfiguriert zu haben (mittels dtrace geschaut, wie QuickTime das macht), ergibt auch alles Sinn.

    Eigentlich sollte die Kamera jetzt über eine Isochronous Pipe schön die Daten ballern, macht sie aber nicht:
    Ich habe einen ordentlichen ReadIsochPipeAsync Request konfiguriert, der auch ohne zu jammern ausgeführt wird. Alle Isoch-Frames sind jetzt aber immer geflaggt als Buffer Underrun. Über alle Frames bekomm ich meisstens 0 Bytes, manchmal 24, ganz selten grosse Werte geliefert. Der buffer, den ich übergebe, bleibt aber so oder so immer unberührt.

    So richtig finde ich auch kein guten Beispielcode was Isochronous-Transfer anbelangt, die Doku ist extrem mies.
    Ich verstehe auch nicht so ganz, was für eine Größenordnung dies frReqCount haben soll. Im Internet stehn da so sachen, wie dass dort z.B. kUSBMaxHSIsocEndpointReqCount, also 3072 oder so rein kommt. Das klingt arg viel, weil das ja pro Frame ist und die Frames kommen ja doch recht schnell?

    Ideen?
    ♥C++

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Jetzt könnte ich noch einmal Hinweise brauchen, weil ich irgendwie meinen Fehler nicht finde:

    Ich bilde mir ein, alles korrekt konfiguriert zu haben (mittels dtrace geschaut, wie QuickTime das macht), ergibt auch alles Sinn.

    Eigentlich sollte die Kamera jetzt über eine Isochronous Pipe schön die Daten ballern, macht sie aber nicht:
    Ich habe einen ordentlichen ReadIsochPipeAsync Request konfiguriert, der auch ohne zu jammern ausgeführt wird. Alle Isoch-Frames sind jetzt aber immer geflaggt als Buffer Underrun. Über alle Frames bekomm ich meisstens 0 Bytes, manchmal 24, ganz selten grosse Werte geliefert. Der buffer, den ich übergebe, bleibt aber so oder so immer unberührt.

    So richtig finde ich auch kein guten Beispielcode was Isochronous-Transfer anbelangt, die Doku ist extrem mies.
    Ich verstehe auch nicht so ganz, was für eine Größenordnung dies frReqCount haben soll. Im Internet stehn da so sachen, wie dass dort z.B. kUSBMaxHSIsocEndpointReqCount, also 3072 oder so rein kommt. Das klingt arg viel, weil das ja pro Frame ist und die Frames kommen ja doch recht schnell?

    Ideen?


    Zeig mal Code.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.

  • RE: IOKit / IOUSBLib

    Original von Chris
    Zeig mal Code.

    Wegen dem ganzen experimentieren sieht der Code entsprechend furchtbar aus. Die meissten Werte habe ich entsprechend vorerst händisch eingetragen, ich will ja erstmal für eine Auflösung was korrektes bekommen. Darum nicht erschrecken, produktiv-code von mir sieht anders aus :)

    ich habe das ganze mal sinngemäß gekürzt, z.B. das error-checking rausgelöscht. mach ich aber immer und gibt keine Fehler.

    Quellcode

    1. void camera::start_iso(IOUSBInterfaceInterface245 **intf) {
    2. IOReturn ret;
    5. /** select alternate of expected transfer **/
    6. // 7 ist der alternate mit der maximalen bandbreite,
    7. // sagt auch USB Prober ;)
    8. IO_TRY( (*intf)->SetAlternateInterface(intf, 7) );
    11. /** check properties **/
    12. uint8_t direction, number, transfer_type, interval;
    13. uint16_t max_packet_size;
    15. ret = (*intf)->GetPipeProperties(intf, 1, &direction, &number,
    16. &transfer_type, &max_packet_size, &interval);
    18. // hier alles geprueft, alle werte sind korrekt
    19. // max_packet_size ist 3072,
    20. // genau der wert, den das geraet auch haben moechte
    21. // (vorher verhandelt)
    23. printf("PIPE STATUS: %x\n", (*intf)->GetPipeStatus(intf, 1));
    24. // pipe status = 0, also pipe ist in ordnung
    25. // "1" ist der isoch endpoint!
    28. CFRunLoopSourceRef source;
    29. ret = (*intf)->CreateInterfaceAsyncEventSource(intf, &source);
    30. CFRunLoopAddSource( CFRunLoopGetCurrent(), source, kCFRunLoopDefaultMode );
    32. // get first bus frame
    33. uint64_t next_frame;
    34. AbsoluteTime time;
    35. ret = (*intf)->GetBusFrameNumber(intf, &next_frame, &time);
    36. // funktioniert
    38. /* start reading */
    39. const uint32_t NUM_FRAMES = 1*8; /// das ist das minimum, was ich
    40. // lesen kann, oder? groessere werte bringen aber auch keine
    41. // verbesserung
    43. uint32_t PIPE_SIZE = max_packet_size;
    45. // funktioniert nur fuer >192 oder so, ist aber bei mir
    46. // der fall
    47. if(1){
    48. UInt32 ms_in_frame;
    49. ret = (*intf)->GetFrameListTime(intf, &ms_in_frame);
    50. if(ret) {
    51. printf("Could not GetFrameListTime\n");
    52. } else {
    53. if(ms_in_frame==kUSBHighSpeedMicrosecondsInFrame) {
    54. PIPE_SIZE = kUSBMaxHSIsocEndpointReqCount;
    55. printf("HIGHSPEED: %d\n",PIPE_SIZE);
    56. // Trifft hier. HIGHSPEED ist 3072, wie erwartet
    57. } else {
    58. PIPE_SIZE = kUSBMaxFSIsocEndpointReqCount;
    59. }
    60. }
    61. }
    63. /** give a little time...
    64. * this is quite important, as we would get an
    65. * error 0xe000400e otherwise because the frame
    66. * lies too far in the past */
    67. next_frame += 100;
    68. //next_frame += 5; // geht auch, egal?
    70. // buffer und frames anlegen
    71. IOUSBIsocFrame *frame_list = new IOUSBIsocFrame[NUM_FRAMES];
    72. uint8_t *buffer = new uint8_t[NUM_FRAMES*PIPE_SIZE];
    74. // buffer testweise auf überall 1 setzen
    75. memset(buffer, 1, NUM_FRAMES*PIPE_SIZE);
    77. // ok, testweise i einer schleife 20 mal lesen.
    78. // eigentlich geht das eleganter, aber vorerst zum testen
    79. // sollte das so ok sein?
    80. const uint32_t NUM_READS = 20;
    81. for(int i=0; i<NUM_READS; ++i) {
    83. // frames initialisieren
    84. for(int i=0; i<NUM_FRAMES; ++i) {
    85. frame_list[i].frStatus = 0;
    86. frame_list[i].frReqCount = PIPE_SIZE;
    87. frame_list[i].frActCount = 0;
    88. }
    90. // LESEN!
    91. ret = (*intf)->ReadIsochPipeAsync(intf, 1, buffer, next_frame, NUM_FRAMES,
    92. frame_list, iso_callback, NULL);
    94. if(ret) {
    95. // HIER KEIN FEHLER, aufruf klappt!
    96. }
    98. // in den run-loop
    99. CFRunLoopRun();
    101. // der "iso_callback" beendet nur den runloop, wenn der transfer
    102. // beendet wurde
    104. // weiter gehts entsprechend NUM_FRAMES spaeter
    105. next_frame += NUM_FRAMES;
    107. // schauen, was wir bekommen haben
    108. uint32_t total = 0;
    109. for(int i=0; i<NUM_FRAMES; ++i) {
    110. total += frame_list[i].frActCount;
    111. }
    112. printf("*** total read: %d\n", total);
    113. // fast immer ist total=0, selten 24,
    114. // ganz selten mehr; je nach settings.
    115. // status ist immer BufferUnderrun!
    116. // buffer ist immer, egal wieviel gelesen wurde
    117. // immernoch jedes byte==1, wie initialisiert...
    119. }
    120. // aufraeumen hier etc...
    121. }
    Alles anzeigen
    Muss ich evtl. bei Isochronous - Transfer die Packet-Größen, Framezahlen etc. *haargenau* auf die (erwartete) Transferrate des Gerätes anpassen? Also wenn ich in XX Sekunden YY Bytes erwarte, muss ich dann ausrechnen, wie lange ein Frame dauert, wie gross ein Frame ist und entsprechend so viele Frames lesen? Irgendwas in die Richtung? Ist mir auch nicht klar...

    --
    PS: Dadurch, dass ich die durch dtrace ermittelten Werte nehme, die auch QuickTime (z.B. von PhotoBooth aus) verwendet, weiss ich jetzt, warum meine Kamera so lahm ist. Der nimmt per default immer die maximale Auflösung und schafft/will daher nur 7fps. Ganz toll.
    Zieht Frames auf 1280x1024 und malt dann nur in so ein kleines Fenster...
    ♥C++

  • RE: IOKit / IOUSBLib

    Ok ist C++, kann nicht funktionieren. :D

    Der Buffer Underrun Fehler ist nur ein Hinweis dass dein Buffer nicht komplett gefüllt wurde. Kann passieren wenn das Gerät die Daten nicht schnell genug liefert.
    Bei den Geräten mit denen ich zu tun hatte war immer ein ClearPipeStallBothEnds() nötig, auch wenn
    GetPipeStatus() was anderes sagte.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.

  • RE: IOKit / IOUSBLib

    Original von Chris
    Ok ist C++, kann nicht funktionieren. :D

    Der Buffer Underrun Fehler ist nur ein Hinweis dass dein Buffer nicht komplett gefüllt wurde. Kann passieren wenn das Gerät die Daten nicht schnell genug liefert.
    Bei den Geräten mit denen ich zu tun hatte war immer ein ClearPipeStallBothEnds() nötig, auch wenn
    GetPipeStatus() was anderes sagte.

    Chris

    Mhh.. das mit den ClearPipeStallBothEnds() probiere ich heut Abend mal; aber auf meiner Isoch-Pipe ist ja vorher noch nie was gelaufen, von daher sollte die ja eigentlich in Ordnung sein.

    Weisst Du, wie ich den Isoch-Transfer zu verstehen habe? Ist der (seitens des IOKit) einfach "dumm" und versucht halt die ganze Zeit zu lesen, was auch immer geschiet? Also quasi: Wuerde der das ueberhaupt mitbekommen, wenn gar nichts entsprechendes da ist (Extrembeispiel: Geraet abgezogen)? Oder sollte ich da schon ein Fehler bekommen, wenn etwas nicht stimmt?

    Ich habe testweise auch ein Alternate Setting genommen, mit maximal 64 byte packet size, in den Frames aber 3072 angegeben. Gab kein Fehler sondern auch stehts nur die underruns. Wirkt etwas irritierend.
    ♥C++

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Original von Chris
    Ok ist C++, kann nicht funktionieren. :D

    Der Buffer Underrun Fehler ist nur ein Hinweis dass dein Buffer nicht komplett gefüllt wurde. Kann passieren wenn das Gerät die Daten nicht schnell genug liefert.
    Bei den Geräten mit denen ich zu tun hatte war immer ein ClearPipeStallBothEnds() nötig, auch wenn
    GetPipeStatus() was anderes sagte.

    Chris

    Mhh.. das mit den ClearPipeStallBothEnds() probiere ich heut Abend mal; aber auf meiner Isoch-Pipe ist ja vorher noch nie was gelaufen, von daher sollte die ja eigentlich in Ordnung sein.

    Ich kann da nur auf Erfahrung zurückgreifen.

    Weisst Du, wie ich den Isoch-Transfer zu verstehen habe? Ist der (seitens des IOKit) einfach "dumm" und versucht halt die ganze Zeit zu lesen, was auch immer geschiet? Also quasi: Wuerde der das ueberhaupt mitbekommen, wenn gar nichts entsprechendes da ist (Extrembeispiel: Geraet abgezogen)? Oder sollte ich da schon ein Fehler bekommen, wenn etwas nicht stimmt?

    Wenn du das Gerät abziehst gibt es Fehler.
    Ich habe bei meinen Tests zuerst mehr Fehler als Erfolge gehabt.

    Ich habe testweise auch ein Alternate Setting genommen, mit maximal 64 byte packet size, in den Frames aber 3072 angegeben. Gab kein Fehler sondern auch stehts nur die underruns. Wirkt etwas irritierend.

    Probier es mal mit größeren Puffern, also mehr Frames lesen.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.

  • RE: IOKit / IOUSBLib

    Hat beides erstmal nichts gebracht.
    Grosse Einsicht hat mir aber der Artikel auf der ML von Apple gebracht, mit dem schönen Titel "After 2 1/2 years Still trying to get Iso Transfers to work."
    (lists.apple.com/archives/Usb/2007/Apr/msg00008.html)

    Demnach kommen die ersten Frames wohl oft leer, weil die zu spät auf den Bus landen. Man soll wohl zuhauf ReadIsochPipeAsyncs losschicken, damit die auch rechtzeitig abgearbeitet werden können. Könnte zu meinen Problemen passen, ich strick das mal dahingehend um...

    Wirr alles. Das mit den Pipes clearen macht der Junge aber auch :)
    ♥C++

  • RE: IOKit / IOUSBLib

    Original von zermelo
    Hat beides erstmal nichts gebracht.
    Grosse Einsicht hat mir aber der Artikel auf der ML von Apple gebracht, mit dem schönen Titel "After 2 1/2 years Still trying to get Iso Transfers to work."
    (lists.apple.com/archives/Usb/2007/Apr/msg00008.html)

    Demnach kommen die ersten Frames wohl oft leer, weil die zu spät auf den Bus landen. Man soll wohl zuhauf ReadIsochPipeAsyncs losschicken, damit die auch rechtzeitig abgearbeitet werden können. Könnte zu meinen Problemen passen, ich strick das mal dahingehend um...

    Wirr alles. Das mit den Pipes clearen macht der Junge aber auch :)


    Ich hab dir ne Mail geschrieben.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.

  • RE: IOKit / IOUSBLib

    Original von Chris
    Ich hab dir ne Mail geschrieben.

    Chris

    Supi, danke.

    Ich habe in der Zwischenzeit noch herausgefunden, dass offensichtlich bei HighSpeed (wie bei mir), next_frame nur um NUM_FRAME/8 erhöht werden sollte. Noch ein bisschen umher rumgehackt und vorallem die Erleuchtung bekommen, dass natürlich frames, in denen nichts übertragen wurde, der buffer unangefasst bleibt, also ich den buffer nur untersuchen darf, wo auch frames reingeschrieben haben.

    Sieht zumindest jetzt ganz gut aus.
    ♥C++