En skal ikke mer en 20 år tilbake hvor multitaskingen var en katastrofe, så hvorfor kan ikke en streamer slite med å holde bitstrømmen perfekt om den må håndtere unødig databehandling fra nettverket?
Buffer/cache og threads.. Det foregår på akkurat samme måten idag som for over 40 år siden, men idag har man flere CPUer og threads. FIFO er også en greie fortsatt idag. DAC og streamer er også to forskjellige ting selv om man får det i samme boks.. DAC må også sees på som flere "enheter" alene.
Prosessorer har ikke endret seg veldig siden x86 kom på markedet i arkitektur når det kommer til hvordan software behandles selv om "multitasking" først ble mer vanlig de senere årene. For 20 år siden så var 1Gbit nettverk blitt veldig vanlig også blant forbrukere, 1Gbit standarden kom i 1998 og bare noen få år i etterkant var det tilgjengelig for bare noen hundrelapper for et nettverkskort og switcher med bare noen porter var også overkommelig i pris.
Men å spille av musikk tar vel knapt nok en promille av CPU kraften idag, det tok ikke mye mer enn 10% for 20 år siden heller om man hadde en crappy PC så det var nok av hastighet og bufre på den tiden til den oppgaven også. Men software og støtte av drivere er et litt annet kapittel.
Du skjønner fortsatt ikke forskjell på realtime protokoller og vanlige strømmer, eller hva enn en protokoll skulle være.
Protokoller er et slags "språk" der sender og mottaker må snakke samme språk, av og til så må mottaker tolke hva som kommer inn for å sette rett protokoll men gjerne er det sender som sier hva som kommer i enhver pakke. I en datastrøm så har man fast satt max størrelse på bit i et nettverk, header forteller hva som er innholdet og hvordan det skal tolkes og gjerne med avsender rekkefølge og checksum (det kan være flere lag med headere, normalt ved kryptering som alle streaming tjenester er). Om rekkefølgen ikke stemmer så fylles bufferet opp frem til korrekte pakker kommer og settes i rett rekkefølge før det sendes videre. Fordelen her er at om en pakke har feil checksum så kan den spørre om å få den pakken på nytt (bidirectional). Realtime så er det mye likt, men her snakker man om unidirectional trafikk (enveis) og om rekkefølgen ikke stemmer så kan man ikke spørre om ny pakke, det som skjer da eller om en pakke har feil checksum er at pakken forkastes (derfor får man grønt og uskarpt bilde på TVn av og til, pga. enkelte pakker har feil rekkefølge eller er korrupte).
Alle streaming tjenester har bidirectional trafikk (toveis kommunikasjon) og godt egnet med store bufre, DAB har også bufre men her er det unidirectional i form av mottaker antenne. Realtime er ikke nødvendigvis "realtime" men kjappere, og det kan også settes prioritet på nettverket for dette så forbrukeren får denne dataen kjappere.
SPDIF er unidirectional og har andre realtime protokoller, I2S, USB audio class 1.0 og 2.0 bygger på akkurat det samme prinsippet. Problemet her er at det er design fra 80-tallet og uten å bruke noe spesielt av buffer da det er realtime protokoller i bruk. USB audio class er datatrafikk med "embedded" lyd i overføringen (mersom SPDIF i filen som sendes over), kan sammenlignes litt med en pakke over nettverket med header og data pakket inn. Men husk, det er protokollene som bestemmer hvordan data skal bli tolket. Om man har en streamer eller PC til noen hundrelapper eller en million så er det faktisk akkurat de samme protokollene som brukes.