Hørbar forskjell på 24-bit og 32-bits audio i en DSP?

[Midas]

Er det noen her på forumet som driver med digital prosessering av lyd og som har eksperimentert med ordbredder og om forskjellene er hørbare? F.eks. heltall vs flyttall, 24-bit vs 32-bit vs 64-bit?

Jeg skal til å implementere digital prosessering (volumkontroll) og muligens noe IIR og kan velge ordbredde. Dataene som kommer inn og ut er 24-bit heltall, men hvilken presisjon vil være nok for internprosessering? Er 32-bit nok, med f.eks. 4 ekstra bit til headroom og 4 ekstra bit til støygulv/kvantiseringsfeil?

 

[Bjørn ("Orso")]

Jeg har ingen ting teknisk å bidra mer her. Kanskje I_L kommer på banen.

Men min subjektive erfaring generelt med digital volumkontroll er at 32 bit er nødvendig (24 blir for lite), men også tilstrekkelig og at det ikke er behov for noe mer.

 

[Midas]

Husk at AES/EBU og lignende formater kun har 24-bits overføring. Hvis man appliserer digital volumjustering på et signal som overføres via AES/EBU/SPDIF eller lignende, så er man begrenset av bredden i grensesnittet.

I generell digital signalprosessering er det alltid hensiktsmessig å ha en del ekstra bit å gå på. For det første kan et midlertidig internt summeringsledd gi en verdi som er større enn signalet og da trenger man ekstra bit i toppen. For det andre kan avrundingsfeil og kvantisering i bunn skape litt støy, og da er det greit å ha ekstra bit i bunn slik at denne støyen blir fjernet når signalet sendes.

Det er spesielt i filter hvor man jobber nære 0 Hz at ordbredden er kritisk. Slik trenden er i utstyr i dag så økes samplingraten, gjerne til 192kHz, og da blir det ekstra vanskelig å kjøre filter i sub-området uten å øke til høyere ordbredder i prosesseringen.

For eksempel har jeg en liten heving på 20Hz som en del av huskurvejustering i kinoen. Hvis DSPen kjører på 192kHz, og har implementert denne hevingen som et simpelt biquad IIR-filter, må DSP eksempelvis jobbe med koeffesienter som er i området 1.0000065019239854. Her er det hele 5 nullere før man kommer til de "nyttige" tallene. Dette tilsvarer ca 16-bit med 0, og da må man ha nok bits igjen til prosesseringen. Hvis ikke er det lett for at det oppstår kvantiseringsfeil og upresisjon i filteret dersom man har for få bit.

 

[Asbjørn]

Jeg har heller ikke gjort dette selv, men jeg hvis jeg skulle kodet opp noe sånt ville jeg vel brukt double precision (64 bits) floating point som intern datarepresentasjon uten å tenke noe særlig mer over det. Det gir vel ikke noen hørbar forskjell fra 24 bits fixed point under normale forhold, men gjør systemet mer robust mot nivået på input og spesialtilfeller hvor det ganges og deles med store tall. Dessuten er det enklest å bruke. Det er flust av velprøvde standardbiblioteker i double, mens fixpointaritmetikk er særere greier.

Edit: Ovenstående gjelder hvis dette skal kjøre på en PC eller tilsvarende. Hvis programmet skal kjøre på annen hardware kan det være noen andre vurderinger. Eksempelvis kan en CPU uten floating point-støtte i hardware kjøre programmet raskere hvis det er fixed point. Hvilken hardware er det du tenker å bruke?

 

[Midas]

Jeg har heller ikke gjort dette selv, men jeg hvis jeg skulle kodet opp noe sånt ville jeg vel brukt double precision (64 bits) floating point som intern datarepresentasjon uten å tenke noe særlig mer over det. Det gir vel ikke noen hørbar forskjell fra 24 bits fixed point under normale forhold, men gjør systemet mer robust mot nivået på input og spesialtilfeller hvor det ganges og deles med store tall. Dessuten er det enklest å bruke. Det er flust av velprøvde standardbiblioteker i double, mens fixpointaritmetikk er særere greier.

Jeg har ikke skrevet det i tråden, men jeg skal bruke dette i en FPGA til dette prosjekt: http://www.hifisentralen.no/forumet...-digital-tapping-fra-hjemmekinoprosessor.html. Da vil fixed point være langt enklere og mindre ressurskrevende. Eller sagt på en annen måte: Enklere å heller øke ordbredden på fixed-point enn å innføre flyttall.

 

[Asbjørn]

Aha. Da er jeg nokså clueless om hva som blir best og hva som blir bra nok.

 

[Utgattmedlem 762]

For volumjustering har det liten hensikt å ha høyere ordbredde enn i kildematerialet, siden kvantiseringsstøyen med høy ordbredde er å anse som en konstant hvitstøykilde. Når man demper flytter man bare signalstyrken nedover mot et konstant støygulv og det vil i all hovedsak være gitt at analog/termisk støy. For filtre, tja, man får jo bedre koeffisientpresisjon. Ikke godt å si på stående fot hva det vil ha å bety, men feks Matlab sin Filter Design Toolbox tillater simulering av filtre med en gitt koeffientoppløsning så man kan sammenligne det praktiske resultatet med teoretisk resultat gitt uendelig presisjon (64-bit flyttall som er standard oppløsning i Matlab IIRC). Ville ikke overraske meg om Octave etterhvert har fått samme funksjonalitet (ikke sjekket siden jeg har tilgang til Matlab og sjelden bruker Octave).

 

[Midas]

For volumjustering har det liten hensikt å ha høyere ordbredde enn i kildematerialet, siden kvantiseringsstøyen med høy ordbredde er å anse som en konstant hvitstøykilde. Når man demper flytter man bare signalstyrken nedover mot et konstant støygulv og det vil i all hovedsak være gitt at analog/termisk støy. For filtre, tja, man får jo bedre koeffisientpresisjon. Ikke godt å si på stående fot hva det vil ha å bety, men feks Matlab sin Filter Design Toolbox tillater simulering av filtre med en gitt koeffientoppløsning så man kan sammenligne det praktiske resultatet med teoretisk resultat gitt uendelig presisjon (64-bit flyttall som er standard oppløsning i Matlab IIRC). Ville ikke overraske meg om Octave etterhvert har fått samme funksjonalitet (ikke sjekket siden jeg har tilgang til Matlab og sjelden bruker Octave).

Takk for innspill!

Som kjent har koeffesientene kvantiserte pol/null-plasseringer i z-planet. Hvis man har dårlig presisjon på koeffeisentene i et filter betyr dette i hovedak at man ikke treffer på ønsket senterfrekvens, ønsket gain eller Q-verdi. Normalt er disse kvantiseringsstegene tilstrekkelig neglisjerbare, men når man nærmer seg enhettsirkelen, så begynner kvantiseringen å få større betydning. Som filter som opererer nære 0 Hz.

 

[Midas]

Jeg har ingen ting teknisk å bidra mer her. Kanskje I_L kommer på banen.

Men min subjektive erfaring generelt med digital volumkontroll er at 32 bit er nødvendig (24 blir for lite), men også tilstrekkelig og at det ikke er behov for noe mer.

Men hva er systemoppsettet med dette? Altså hvordan overføres digital strøm til enhet med DAC? Fordi jeg har ikke vært borti noen eksterne digitale overføringsmåter som har mer enn 24-bit. AES3 (altså AES/EBU, SPDIF og TOSLINK) har maks 24-bit, ADAT har maks 24-bit. Jeg skal ikke blodsverge på at digital overføring i PC til DAC i innebygget lydkort ikke støtter mer enn 24-bit, det er iallefall ikke vanlig med mer.

I_L kan korrigere meg hvis jeg er på bærtur, men jeg tenker at for overføring og DAC-konvertering er det ikke poeng med mer enn 24 bit. Det har hensikt i operasjoner der man skal prosessere signalet med mange mellomledd, der regnefeil og avrunding kan påvirke tellende bits. På et tidspunkt vi fysikken ta deg igjen, og i 32-bits overføring vil de nederste bitene vil være så hinsides svake at termisk støy i vanlige ledninger og motstander blir som støyende fossefall i forhold. En 1k motstand på 20 grader har en termisk støy på rundt 400nV ved en båndbredde på 10kHz, som tilsvarer omtrentlig bit 22-23 i en DAC med 3,3V single-ended supply.

I_L, kanskje du vet noe om hvordan de kan klare å ha DAC som angivelig gir så svake nyanser ut?

 

[thohaug]

Jeg har ingen ting teknisk å bidra mer her. Kanskje I_L kommer på banen.

Men min subjektive erfaring generelt med digital volumkontroll er at 32 bit er nødvendig (24 blir for lite), men også tilstrekkelig og at det ikke er behov for noe mer.

Men hva er systemoppsettet med dette? Altså hvordan overføres digital strøm til enhet med DAC? Fordi jeg har ikke vært borti noen eksterne digitale overføringsmåter som har mer enn 24-bit. AES3 (altså AES/EBU, SPDIF og TOSLINK) har maks 24-bit, ADAT har maks 24-bit. Jeg skal ikke blodsverge på at digital overføring i PC til DAC i innebygget lydkort ikke støtter mer enn 24-bit, det er iallefall ikke vanlig med mer.

I_L kan korrigere meg hvis jeg er på bærtur, men jeg tenker at for overføring og DAC-konvertering er det ikke poeng med mer enn 24 bit. Det har hensikt i operasjoner der man skal prosessere signalet med mange mellomledd, der regnefeil og avrunding kan påvirke tellende bits. På et tidspunkt vi fysikken ta deg igjen, og i 32-bits overføring vil de nederste bitene vil være så hinsides svake at termisk støy i vanlige ledninger og motstander blir som støyende fossefall i forhold. En 1k motstand på 20 grader har en termisk støy på rundt 400nV ved en båndbredde på 10kHz, som tilsvarer omtrentlig bit 22-23 i en DAC med 3,3V single-ended supply.

I_L, kanskje du vet noe om hvordan de kan klare å ha DAC som angivelig gir så svake nyanser ut?

Vil det fortsatt ikke ha betydning dersom volumkontrollen kommer før man overfører via AES/EBU etc? Si f.eks at man har en 64bit volumkontroll i samme software som man bruker som avspiller. Dette vil jo være i mitt tilfelle i så fall hvor jeg bruker JRiver som både avspiller og volumkontroll. Da vil jo volumet blir regulert før det blir sendt over AES/EBU. Hører gjerne en forklaring på hvordan dette vil fungere, ettersom jeg ikke kan nok om dette. Vil jeg ikke da kunne beholde 24bit oppløsning nesten uavhengig av hvor lavt volumet står?

 

[Midas]

Vil det fortsatt ikke ha betydning dersom volumkontrollen kommer før man overfører via AES/EBU etc? Si f.eks at man har en 64bit volumkontroll i samme software som man bruker som avspiller. Dette vil jo være i mitt tilfelle i så fall hvor jeg bruker JRiver som både avspiller og volumkontroll. Da vil jo volumet blir regulert før det blir sendt over AES/EBU. Hører gjerne en forklaring på hvordan dette vil fungere, ettersom jeg ikke kan nok om dette. Vil jeg ikke da kunne beholde 24bit oppløsning nesten uavhengig av hvor lavt volumet står?

Vanlige DACer som brukes til audio er som oftest implementert med analog volumjustering etter digital til analog konverteringen. Altså behøver man en audiostrøm og en voluminformasjon. Fordelen med denne metoden, er at man demper støygulvet like mye som signalet og dermed kan man ha tilnærmet lik mengde signal/støy-forhold mer eller mindre uavhengig av MV.

AES/EBU (AES3) er begrenset til å overføre 24-bit og uheldigvis mangler standardisert mulighet til å overføre voluminformasjon. Altså, det er ikke mulig å sende informasjon fra PC til forsterker som spesifiserer hvor mye analog demping volumkontrollen skal ha. Volumkontroll basert på AES3 må altså være utelukkende digital.

Digital volumkontroll har den ulempen at støygulvet er konstant, mens signalet synker når volumet skrues ned. Dermed så vil signal/støyforholdet bli dårligere og dermed virker det som støyen øker. Som i praksis betyr at man mister oppløsning på lavere volum.

64-bits volumkontroll har lite å bety for volumet når dette sendes ut på et 24-bits grensesnitt, fordi alle bits under 24 blir fjernet uansett.

 

[Bjørn ("Orso")]

Jeg har ingen ting teknisk å bidra mer her. Kanskje I_L kommer på banen.

Men min subjektive erfaring generelt med digital volumkontroll er at 32 bit er nødvendig (24 blir for lite), men også tilstrekkelig og at det ikke er behov for noe mer.

Men hva er systemoppsettet med dette? Altså hvordan overføres digital strøm til enhet med DAC? Fordi jeg har ikke vært borti noen eksterne digitale overføringsmåter som har mer enn 24-bit. AES3 (altså AES/EBU, SPDIF og TOSLINK) har maks 24-bit, ADAT har maks 24-bit. Jeg skal ikke blodsverge på at digital overføring i PC til DAC i innebygget lydkort ikke støtter mer enn 24-bit, det er iallefall ikke vanlig med mer.

I_L kan korrigere meg hvis jeg er på bærtur, men jeg tenker at for overføring og DAC-konvertering er det ikke poeng med mer enn 24 bit. Det har hensikt i operasjoner der man skal prosessere signalet med mange mellomledd, der regnefeil og avrunding kan påvirke tellende bits. På et tidspunkt vi fysikken ta deg igjen, og i 32-bits overføring vil de nederste bitene vil være så hinsides svake at termisk støy i vanlige ledninger og motstander blir som støyende fossefall i forhold. En 1k motstand på 20 grader har en termisk støy på rundt 400nV ved en båndbredde på 10kHz, som tilsvarer omtrentlig bit 22-23 i en DAC med 3,3V single-ended supply.

I_L, kanskje du vet noe om hvordan de kan klare å ha DAC som angivelig gir så svake nyanser ut?

Lynx Two-B analogt ut til effektrinn. Dvs. jeg bruker nå også den digitale utgangen, som går til et eksternt delefilter og videre til subwoofere.
LynxTWO
Har aldri opplevd volumkontrollen til Lynx som degraderende. Det er fortsatt den mest transparente kilden jeg har prøvd hjemme.

 

[JENO]

Vil det fortsatt ikke ha betydning dersom volumkontrollen kommer før man overfører via AES/EBU etc? Si f.eks at man har en 64bit volumkontroll i samme software som man bruker som avspiller. Dette vil jo være i mitt tilfelle i så fall hvor jeg bruker JRiver som både avspiller og volumkontroll. Da vil jo volumet blir regulert før det blir sendt over AES/EBU. Hører gjerne en forklaring på hvordan dette vil fungere, ettersom jeg ikke kan nok om dette. Vil jeg ikke da kunne beholde 24bit oppløsning nesten uavhengig av hvor lavt volumet står?

Vanlige DACer som brukes til audio er som oftest implementert med analog volumjustering etter digital til analog konverteringen. Altså behøver man en audiostrøm og en voluminformasjon. Fordelen med denne metoden, er at man demper støygulvet like mye som signalet og dermed kan man ha tilnærmet lik mengde signal/støy-forhold mer eller mindre uavhengig av MV.

AES/EBU (AES3) er begrenset til å overføre 24-bit og uheldigvis mangler standardisert mulighet til å overføre voluminformasjon. Altså, det er ikke mulig å sende informasjon fra PC til forsterker som spesifiserer hvor mye analog demping volumkontrollen skal ha. Volumkontroll basert på AES3 må altså være utelukkende digital.

Digital volumkontroll har den ulempen at støygulvet er konstant, mens signalet synker når volumet skrues ned. Dermed så vil signal/støyforholdet bli dårligere og dermed virker det som støyen øker. Som i praksis betyr at man mister oppløsning på lavere volum.

64-bits volumkontroll har lite å bety for volumet når dette sendes ut på et 24-bits grensesnitt, fordi alle bits under 24 blir fjernet uansett.

Digital vs. analog volumkontroll har vært diskutert tidligere. I_L kan sikkert utdype, men det jeg mener å erindre fra diskusjonen er at i en kjede med analog volumkontroll er støybudsjettet dominert av støy som er introdusert etter volumkontrollen, gitt at god gainstruktur er ivaretatt. Dermed er det ett fett om volumkontrollen er analog eller digital, bortsett fra at en digital volumkontroll har høyere presisjon og mindre forvrenging. Dermed vil begge løsninger ha konstant støygulv, og dermed tape oppløsning når volumet dempes. Korriger meg om jeg tar feil!

 

[Utgattmedlem 762]

Jeg har ingen ting teknisk å bidra mer her. Kanskje I_L kommer på banen.

Men min subjektive erfaring generelt med digital volumkontroll er at 32 bit er nødvendig (24 blir for lite), men også tilstrekkelig og at det ikke er behov for noe mer.

Men hva er systemoppsettet med dette? Altså hvordan overføres digital strøm til enhet med DAC? Fordi jeg har ikke vært borti noen eksterne digitale overføringsmåter som har mer enn 24-bit. AES3 (altså AES/EBU, SPDIF og TOSLINK) har maks 24-bit, ADAT har maks 24-bit. Jeg skal ikke blodsverge på at digital overføring i PC til DAC i innebygget lydkort ikke støtter mer enn 24-bit, det er iallefall ikke vanlig med mer.

I_L kan korrigere meg hvis jeg er på bærtur, men jeg tenker at for overføring og DAC-konvertering er det ikke poeng med mer enn 24 bit. Det har hensikt i operasjoner der man skal prosessere signalet med mange mellomledd, der regnefeil og avrunding kan påvirke tellende bits. På et tidspunkt vi fysikken ta deg igjen, og i 32-bits overføring vil de nederste bitene vil være så hinsides svake at termisk støy i vanlige ledninger og motstander blir som støyende fossefall i forhold. En 1k motstand på 20 grader har en termisk støy på rundt 400nV ved en båndbredde på 10kHz, som tilsvarer omtrentlig bit 22-23 i en DAC med 3,3V single-ended supply.

I_L, kanskje du vet noe om hvordan de kan klare å ha DAC som angivelig gir så svake nyanser ut?

Er litt usikker på om jeg forstår spørsmålet, men hvordan man kan lage kretser med lav termisk støy eller høy SNR? Som du sier er termisk støy fundamentalt begrenset av Vn^2=4kTR som gir en 1k-motstand et støybidrag på ca 400nV over en 10kHz båndbredde. Generelt er all termisk støy skapt av statistisk fluktuasjon av ladning som skaper statistisk støy i ladningsflyten, dvs strømmen som flyter gjennom en node, og den resulterende støyspenningen er proporsjonal med motstanden i noden. Så for å oppnå høyere S/N for en gitt signalspenning må man derfor ha høyere strøm eller ekvivalent lavere motstand i de ulike nodene i kretsen. Så det enkle svaret; mer strøm.

I transistorkretser vil du gjerne optimalisere forholdet mellom støy og strømtrekk. For transistorer generelt er utgangsreferert støy In^2∝gm. Hvis transistorene er i metning er gainet proporsjonalt med gm^2, så du vil gjerne designe for høy gm (eller mer spesifikt høy gm/Id) for å få en best mulig støyfaktor. For transistorer i triodeområdet er gainet også proporsjonalt med gm, samt gds, så gm faller ut og det er gds som "teller". Så man må analysere kretsen og transistorene avhengig av hva de gjør og hvilken region de opererer i.

http://betasoft.org/wordpress/wp-content/uploads/2012/02/noise02s-raf.pdf
https://www.eecs.berkeley.edu/~boser/presentations/2011-12 OTA gm Id.pdf

Det er ikke veldig vanskelig å lage en DAC med >120dB SNR i 3.3V, i hvert fall ikke hvis man kan koste på seg endel strømtrekk. Det som er vanskelig er linearitet på det nivået. Linearitet er begrenset av matching og ikke-lineære dynamiske effekter som slewing, ISI og jitter. Å lage en krets med 20 bit+ linearitet i CMOS er vanskelig og involverer gjerne ganske avansert digital korreksjon for nevnte ikke-lineariteter. Digital mismatchkorreksjon har eksistert siden tidlig 90-tall og begynner å bli ganske moden teknologi, mens digital korreksjon for dynamisk ikke-linearitet fortsatt er mer på forskningsstadiet. Én av de kulere DACene jeg har sett er en somLars Risbo fra Texas Instruments presenterte i 2011 som har en svært finurlig korreksjonsmotor som tar både mismatch og dynamiske feil. Resultatet er også imponerende, -120dB THD med 0.5Vrms utgangsspenning i 45nm CMOS.

http://www.eit.lth.se/fileadmin/eit/courses/etin05/2011/lec10.pdf

 

[Midas]

Digital vs. analog volumkontroll har vært diskutert tidligere. I_L kan sikkert utdype, men det jeg mener å erindre fra diskusjonen er at i en kjede med analog volumkontroll er støybudsjettet dominert av støy som er introdusert etter volumkontrollen, gitt at god gainstruktur er ivaretatt. Dermed er det ett fett om volumkontrollen er analog eller digital, bortsett fra at en digital volumkontroll har høyere presisjon og mindre forvrenging. Dermed vil begge løsninger ha konstant støygulv, og dermed tape oppløsning når volumet dempes. Korriger meg om jeg tar feil!

Makes sense to me.

Det jeg egentlig prøver å røyke ut her er hvorfor man tilstreber 32bits og nå i senere tid 64bits*) operasjoner på audio, hvis overføring og/eller DAC (og ultimat sett støygulvet) har mye lavere oppløsning. Kvantiseringseffekter i mellomprodukter av filtrering er ett argument jeg ser, men er det andre?

*) 64bits float har en effektiv mantissapresisjon på 48bit.

 

[Asbjørn]

Fordi det ikke koster noe ekstra? Prosessorer som håndterer 64-bits double precision i hardware finnes overalt, så det vil fort bli dyrere å be en programmerer om å tenke for å sette opp en 24-bits fixed precision datastruktur enn bare å deklarere alle variable som 64-bits double precision arrays og bruke tiden på noe annet. Det er som sagt hva jeg ville gjort om jeg ikke hadde noen tungtveiende grunn til å gjøre noe annet. At markedsføringsavd sikkert ville brukt det som et salgsargument ville vært en bivirkning. Om det mot formodning skulle føre til utfordringer med minne er neste opplagte alternativ å deklarere variablene som 32-bits float og kutte minnebehovet til halvparten. If in doubt use brute force, som det heter.

 

[Arnold Duck]

"Det jeg egentlig prøver å røyke ut her er hvorfor man tilstreber 32bits og nå i senere tid 64bits*) operasjoner på audio, hvis overføring og/eller DAC (og ultimat sett støygulvet) har mye lavere oppløsning. Kvantiseringseffekter i mellomprodukter av filtrering er ett argument jeg ser, men er det andre?"

Svar:

Nei.
Det er hele poenget.

 

[AAaF]

Om det ikkje har skjedd veldig mykje med analoge referanser dei seinare åra, så ligg vel støygulvet på ca 22 Bit? Korriger meg gjerne om det er feil, dette er vel 10 år sidan, men tenkte det kanskje ikkje var hendt så mykje på den fronten.

I såfall tenker eg i mitt stille sinn, at det vil teoretisk være fordelaktig om ein har ein del ekstra bit for å kunne gjere signalprossesering under dette støygulvet, for å ikkje miste noko som helst.

Er dykk einige i det?