Az USB adatkapcsolat és a digitális hangátvitel
Hibaarányok, csomagvesztés és hibakezelés – ismeretterjesztő összefoglaló
Előszó
Érdeklődési körömet, hobbimat tekintve soft-hifistának definiálom magam. Érdekel a téma, érdekel a műszaki háttér is, de csak módjával.
Fórumokon fellelhető információ mennyiséget én kevésnek és töredezettnek éreztem. Az időnként idézett gyártói dokumentációk értelmezéséhez kellenének bizonyos műszaki alapismeretek...
Hozzáértők meg-megosztanak információ morzsákat, de ezt nehéz összegyűjteni fejben.
Hirdetés
Természetesen az írásom AI generált.
Nem az én tudásom az alábbi szöveg. Igyekeztem úgy promptolni, hogy fórumokról ne gyűjtsön infót egyik AI se, csak gyártói doksik és Engineering Notes-ok legyenek a források.
Egy olyan tudásanyagot gyűjtöttem össze, ami műszaki érdeklődésű embereknek kb könnyen emészthető.
Az esetleges szakmai pontatlanságokért elnézést kérek.
Az olvasáshoz jó szórakozást kívánok!
Bevezetés
Amikor egy USB-DAC-ot, hangkártyát vagy digitális hangszeres interfészt csatlakoztatunk a számítógéphez, hajlamosak vagyunk az USB-kapcsolatot egyetlen, egységesen megbízható digitális csatornaként elképzelni – hiszen ugyanezen a buszon keresztül fájlokat is másolunk, byte-pontos egyezéssel. A valóság ennél árnyaltabb. Az USB-szabvány két, filozófiájában alapvetően eltérő adatátviteli módot definiál, és a digitális hangátvitel tudatosan nem azt a módot használja, amelyik garantálja a hibátlan megérkezést. Ez nem tervezési hiányosság, hanem mérnöki döntés, amelynek logikáját, számszerű következményeit és a gyakorlatban alkalmazott hibakezelési technikákat ez az összefoglaló mutatja be.
1. Az USB két alapvető adatátviteli módja
Az USB négyféle ún. transfer type-ot különböztet meg: Control, Interrupt, Bulk és Isochronous. A hangátvitel szempontjából a meghatározó ellentétpár az Adatátvitel (Bulk) és az Audioátvitel (Isochronous) – ez a két mód lényegében egymás tükörképe: amit az egyik garantál, azt a másik éppen feláldozza.
1.1 Adatátvitel (Bulk)
A Bulk mód nagy mennyiségű adat (fájlok, képek, nyomtatási feladatok) hibátlan átvitelére szolgál. Alapelve, hogy a helyesség fontosabb, mint az időzítés: a busz szabad idejét használja fel, tehát ha éppen más forgalom foglalja a sávszélességet, a Bulk-átvitel várakozhat, sőt jelentősen le is lassulhat. Cserébe minden csomag ellenőrzött, és hiba esetén automatikusan újraküldésre kerül, amíg hibátlanul meg nem érkezik.
1.2 Audioátvitel (Isochronous)
Az Isochronous mód ezzel szemben folyamatos, valós idejű adatfolyamok (hang, videó) számára készült. Itt az elv megfordul: az időzítés fontosabb, mint a tökéletes helyesség. A host előre lefoglal egy fix sávszélesség-részt és egy fix időrést minden átviteli ciklusban, és ezt a csomagot – hibás vagy hibátlan tartalommal – mindig ugyanabban az ütemben küldi. Ha egy csomag megsérül vagy elvész, nincs újraküldés: a következő, ütemezett időpillanatban egyszerűen jön a következő adag, függetlenül attól, hogy az előző sikeres volt-e.
1.3 Összehasonlítás
2. Hibaérzékelés és hibakezelés a protokoll szintjén
2.1 A CRC szerepe
Minden USB-csomag tartalmaz egy CRC-t (Cyclic Redundancy Check), egy, az adatból matematikailag számított ellenőrző összeget. A vevő fél ugyanezt a számítást elvégzi a beérkezett biteken, és összeveti a kapott eredménnyel: eltérés esetén tudja, hogy a csomag sérült. Az USB 2.0-ban a token csomagok (cím + végpont mező) egy rövidebb, 5 bites CRC5-tel, az adatcsomagok (akár 1024 bájtos payloaddal) egy 16 bites CRC16-tal védettek. Fontos: a CRC önmagában csak érzékeli a hibát, javítani nem tudja – a javítás (újraküldés vagy elfedés) már a protokoll magasabb szintjén, illetve a fogadó alkalmazás felelőssége.
2.2 Bulk: ACK, NAK és a csendes visszautasítás
A Bulk-tranzakció három fázisból áll: token – adat – handshake. A handshake fázisban a vevő az alábbi válaszok egyikét adhatja:
ACK (Acknowledgement): a csomag hibátlanul megérkezett, és a fogadó puffer be is fogadta. NAK (Negative Acknowledgement): a csomag hibátlanul megérkezett, de a fogadó fél átmenetileg nem tudja feldolgozni (pl. tele a puffere) – ez tehát nem hibajelzés, hanem forgalomszabályozás, ami a hostot újrapróbálkozásra kéri. STALL: tartós hibaállapot, a host beavatkozása szükséges.
Ha viszont maga az adatcsomag (vagy az azt megelőző token) CRC-je hibásnak bizonyul, a vevő egyáltalán nem válaszol – sem ACK-ot, sem NAK-ot nem küld. A host ezt egy előre definiált időtúllépés (timeout) után ismeri fel, és megismétli a teljes tranzakciót. A gyakorlatban tehát a sérült adatra adott "válasz" a csend, nem a NAK – ez egy gyakran összekevert, de fontos technikai különbség.
2.3 Isochronous: a „No ACK" architektúra
Az Isochronous tranzakció szerkezetileg is egyszerűbb: nincs benne harmadik, handshake fázis. A CRC16 mező itt is jelen van, tehát a vevő technikailag érzékelheti a hibát, de nincs mechanizmus a visszajelzésre – ezt nevezzük No ACK architektúrának. Egy sérült vagy meg nem érkezett csomagot a rendszer egyszerűen figyelmen kívül hagy (csomageldobás), és a következő ütemezett időpillanatban – Full Speed módban 1 ezredmásodperccel (1 ms), High Speed módban 125 mikroszekundummal (125 µs) később – érkezik a következő adag, függetlenül attól, hogy az előző sikeres volt-e.
3. A hiba számszerűsítése: BER és PER
3.1 Bit Error Rate (BER)
A BER (Bit Error Rate) a hibásan átvitt bitek aránya az összes átvitt bithez képest – a fizikai réteg (jel, kábel, csatlakozók, elektronika) nyers megbízhatóságát jellemzi. Az USB fizikai rétegére vonatkozó megfelelőségi tesztek (dokumentáltan a USB 3.x specifikációban, de a USB 2.0 High Speed jelminőségi/eye-diagram követelményei is hasonló nagyságrendet céloznak) kb. BER ≈ 10⁻¹² felső korlátot írnak elő, azaz átlagosan egy billió (10¹²) átvitt bitre juthat legfeljebb egy hibás bit. Ez rendkívül szigorú érték – a vezérlőchip belső, tisztán digitális logikájában az elvárt megbízhatóság ennél is nagyobb, akár 10⁻²⁰ nagyságrendű.
3.2 Packet Error Rate (PER)
A PER (Packet Error Rate) azt fejezi ki, hogy az elküldött csomagok hányad része hibás, azaz kerül eldobásra. Mivel egy csomag sok bitből áll, egyetlen bithiba is elég ahhoz, hogy az egész csomag érvénytelenné váljon (elbukik a CRC-ellenőrzés). Ha egy csomag N bitet tartalmaz, és a bithibák egymástól függetlenek, a hibátlan megérkezés valószínűsége (1 − BER)^N, ebből:
PER = 1 − (1 − BER)^N ≈ N × BER (ha N × BER ≪ 1, ami audio esetén szinte mindig teljesül)
Ez az összefüggés kulcsfontosságú: minél nagyobb egy csomag, annál nagyobb – azonos BER mellett is – a hibás csomagok aránya. Erre a 6. fejezetben térünk vissza konkrét számokkal.
3.3 Az iparági standard
Összefoglalva: a fizikai rétegen az iparági célérték kb. BER ≈ 10⁻¹². Ez a bithiba-arány önmagában rendkívül alacsony PER-t eredményez a tipikus audio-csomagméretek mellett (lásd 6.4) – vagyis egy szabványnak megfelelő, jó minőségű USB-kapcsolaton a tisztán fizikai eredetű hangkiesésnek elméletileg rendkívül ritkának kellene lennie.
A cikk még nem ért véget, kérlek, lapozz!
