"a hiba valahol nem a low level oldalon lehet. Akkor meg hol?"
Feltételezel egy tiszta ISO-OSI értelemben vett protokoll-rétegszerkezetet. Ami lehet, hogy a specifikáció szintjén még teljesül, de a gyártók meg ott gányolnak ahol csak tudnak. Az USB kontrolleren futó firmware és/vagy az oprendszer szintű driver valószínűleg könyékig turkál a "magasabb rétegbeli" üzenetekben is. Így vannak kioptimalizálva, hogy a gamereknek fontos latency benchmarkban jó eredmény szülessen, közben a pendrive-ok is NVMe SSD-kkel vetekedő átviteli sebességet produkáljanak (persze csak a benchmarkban).
Tudom, kicsit off, de az első hasonló élményem a korai USB pendrive-okkal az volt, hogy egy FAT32-vel hibátlan pendrive, ext2-re (vagy ext3-ra, mindenesetre jó régen volt) formázva blokkhibás volt. Badblocks-szal tesztelve egyértelműen voltak hibás blokkok, ráadásul ide-oda mozgott a helyük (első találkozásom a flash translation layerrel...). FAT32-re visszaformázva megint hibátlan volt. A block device, ami tudja, hogy milyen filerendszer van rajta... Nyilván volt valami specifikus optimalizálás a firmware-ben, aztán nem tesztelték le, hogy mivan ha mégsem a gyári default filerendszer kerül rá.
Ide a rozsdás bökőt, hogy valami ilyesmi baj van itt is. Valami csoda optimalizálás félremegy, mert nem elég "mainstream" a hardvered, hogy össze legyen próbálva vele. Lehet, hogy pont valami proprietary latency-javító prioritizálásnak kerül a rossz végére az audio cucc forgalma.
Nyilván ezeket nagyon melós kinyomozni. Wireshark capture-rel sem biztos, hogy látni fogod a lényeget, vagy ha ki is tudod mutatni a különbséget, az okához nem jutsz közelebb.