Granskning av Rob Watts teorier

[Svante]

Får jag påpeka då att det osnygga ligger i valet att inte lägga transitionsbandet under fs/2 utan att lägga det halvvägs kring fs/2. Det blir så om man stirrar sig blind på att impulssvaret ska vara en sinc med rippel som motsvarar fs/2. Man behöver lägga ripplet lite långsammare så bryter filtret lite lägre. Det är ren slentrian att inte göra det.

Därför är det osnyggt, även om hörbarheten i de flesta (alla?) fall är noll.

Riktigt bra omsamplare gör det snyggt. Chords två omvandlare som jag har testat gör det också. De flesta DACar gör det inte. Det är ingen stor grej, men nu när allt annat är så nära perfekt så kan man väl fixa till även detta?

Vad är halvvägs kring fs/2? Menar du 11 kHz för CD-systemet?

Just nu ligger cut off i vår DAC på 21 kHz då fs=44,1 kHz. Vid 21 kHz är nivån ungefär -50 dB.

Jag syftar på den mätstandard som de flesta tillverkare verkar använda där transitionsbandet ligger mellan 0,454*fs och 0,546*fs, vilket översatt till 44,1 kHz samplingsfrekvens blir 20-24,1 kHz. Har man förstått sampling, och köper tanken att man har lagt fs/2 vid 22,05 kHz, dvs en gnutta över 20 kHz (det som brukar anses vara den högsta hörbara frekvensen) så borde transitionsbandet ligga mellan 20 och 22,05 kHz. Eller mellan 0,454*fs och 0,5*fs.

[petersteindl]

Så här har Burr Brown gjort det i sin filterkrets 1704DF



Med vänlig hälsning
Peter

[Svante]

Så här har Burr Brown gjort det i sin filterkrets 1704DF

[ Bild ]

Med vänlig hälsning
Peter

Ja, osnyggt. Varför inte låta stoppbandet börja vid 0,5 fs? Jag kan förstå att man gjorde så för 20 år sedan, men idag, 20 år senare borde beräkningskapaciteten ha ökat den faktor 2 som behövs för att fixa det.

[IngOehman]

För att allt skall bli rätt så krävs inte bara hög kapacitet - det krävs att man kan stå ut med fördröjningen också.

Det är inte alltid så att det är okej att vänta väldigt länge innan signalen kommer ut. T ex inte när ljudet hör ihop med bild.

Jag hade snarare önskat att man när CD-systemet bestämdes, hade valt 20 bitar och 50 kHz. Så mycket hade blivit så mycket enklare då. Visst, man hade fått 29,44% kortare speltid, men det hade ändå gått att pressa speltiden uppåt 55 minuter. Inte så dåligt ändå. Och det hade faktiskt till och med gått att nå långt över en timme med 20/50, om man hade trimmat systemets effektivitet på lite andra sätt.


Vh, iö

[petersteindl]

För att allt skall bli rätt så krävs inte bara hög kapacitet - det krävs att man kan stå ut med fördröjningen också.

Det är inte alltid så att det är okej att vänta väldigt länge innan signalen kommer ut. T ex inte när ljudet hör ihop med bild.

Jag hade snarare önskat att man när CD-systemet bestämdes, hade valt 20 bitar och 50 kHz. Så mycket hade blivit så mycket enklare då. Visst, man hade fått 29,44% kortare speltid, men det hade ändå gått att pressa speltiden uppåt 55 minuter. Inte så dåligt ändå. Och det hade faktiskt till och med gått att nå långt över en timme med 20/50, om man hade trimmat systemets effektivitet på lite andra sätt.


Vh, iö

Precis, men 20 ms fördröjning bör kunna gå att kompensera för i A/V-sammanhang. Oppon klarar det i alla fall och jag tror att jag kan få ihop en sjuhelvetisk kapacitet inom 20 ms.

Nu är CD vad det är och jag har tänkt fullborda mitt DAC-projekt intill absurdum. så får vi se hur bra det blir. Naturligtvis bör en motsvarande Bremen A/D kunna se sitt ljus så småningom. Vi bör kunna sampla med 6,144 MHz och 32 bitar. Helst vill jag ha 98,304 MHz samplingsfrekvens med 32 bitar d v s 98304/32 format. Det kommer gå åt lite hårddisk, men det blir ett smutt filter på ingången Fast, jag får väl stå ut med det vi kan åstadkomma för stunden.

Med vänlig hälsning
Peter

P.S. För övrigt är det jobbigt med dubbla negationer. Jag har avsiktligt inte tagit med det ovan kursiverade ordet inte i min blåmarkering.

[Nattlorden]

Att kompensera ljudfördröjning med fördröjning av bild är i alla fall inget som fungerar om man spelar.... då blir all fördröjning där en fördröjning på din reaktionstid...

[Svante]

Fördröjning är inget problem när man talar om en lagrad signal. Man kan ju mycket enkelt tjyvtitta på kommande sampel och på så sätt få en (virtuell) nollfördröjning. Det är först om man spelar in och upp samtidigt som det är ett problem.

[Piotr]

Det är först om man spelar in och upp samtidigt som det är ett problem.

Men endast om man behöver medhörning utav det inspelade, right?

Dvs. direkt återkoppling utav det som spelas in "nu", inte det tidigare som man "spelar till".

[Svante]

Det är först om man spelar in och upp samtidigt som det är ett problem.

Men endast om man behöver medhörning utav det inspelade, right?

Dvs. direkt återkoppling utav det som spelas in "nu", inte det tidigare som man "spelar till".

Ja, precis. Typ. En AD-DA-kedja i ett PA-system skulle inte må bra av 1 s fördröjning.

[Nattlorden]

Fördröjning är inget problem när man talar om en lagrad signal. Man kan ju mycket enkelt tjyvtitta på kommande sampel och på så sätt få en (virtuell) nollfördröjning. Det är först om man spelar in och upp samtidigt som det är ett problem.

Finns väl mycket väl ett use case för en DAC att spela upp en digital signal som originerar i ett dator- eller tv-spel?

[Svante]

Fördröjning är inget problem när man talar om en lagrad signal. Man kan ju mycket enkelt tjyvtitta på kommande sampel och på så sätt få en (virtuell) nollfördröjning. Det är först om man spelar in och upp samtidigt som det är ett problem.

Finns väl mycket väl ett use case för en DAC att spela upp en digital signal som originerar i ett dator- eller tv-spel?

Ja, det är ju ett exempel på när en insignal (tangenttryckning) behöver ge omedelbar respons i form av ett ljud. Tangenttryckningen ligger ju inte lagrad.

[IngOehman]

Njae, tidsförhållandet mellan ett ljud och en bild kan DEFINITIVT bli ett problem om tiden i en disparat DAC fördröjs mycket. Att fördröja bild mycket (eller alls) i en hemmabioförstärkare är alls inte säkert att det går att göra.

I normalfallet går ju läppsynkronisering till på så vis att bildvisaren berättar (baklänges via HDMI) hur lång tid den tar på sig för att visa bilden. Den informationen använder hemmabioförstärkaren till att fördröja ljudet lika mycket. Inte tvärtom.


Vh, iö

[Svante]

Det må vara så i praktiken, men jag menar att det på systemnivå är ett icke-problem att en DAC har en fördröjning. Givetvis ska ett system ta hand om fördröjning både i DAC och videorendering så att det blir noll tidsskillnad mellan dem. Och det går att göra om video och audio ligger digitalt lagrade så att man kan tjyvtitta på kommande data.

Faktum är att detta är ett typfall när det skulle vara bra om olika DACar hade väldigt olika fördröjningar, det skulle tvinga fram ett system som tar hand om den. Det härke som finns idag där användaren ska/kan ställa in läppsynk är ju bara knas. Det är, om man ska hårdra det, en konsekvens av att olika DACar har för lika fördröjning så att det bara är ett litet problem.

[IngOehman]

Nej, så är det inte.

Dels är det INTE meningen att användaren skall ta hand om synkningen själv. Det är automatiskt och en del av vad HDMI-protokollet medger. Bildvisaren berättar för hemmabioförstärkaren om sin delay (som även kan ändra sig när man ändrar bildvisarens insrällningar, och då berättas även det, det är alltså ingen konstant utan ett värde som kan ändra sig beroende på hur bildvisaren är inställd).

Dessutom är fördröjningen mellan olika DACar alls inte samma. Olika DACar har väldigt olika fördröjningar. Vet inte varför du tror att de skulle vara väldigt lika varandra? De som har längst fördröjning har hundratals gånger mera fördröjning än de med kortast.

Däremot är det i normalfallet så, att fördröjningen för bilden är mångfaldigt större än den som gäller ljudet, och det är det som är skälet till att man hanterar synkningen genom att anpassa ljudets fördröjning. Och en bra sak med det är att det gör behovet av att lagra data mindre.

Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare..

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

Att låtsas som att det inte är något problem duger inte. I praktiken så behöver man tillgripa andra (intelligentare) lösningar än att förlänga sincen så den blir så lång att man kan trunkera den bryskt utan att det ger störande artefakter. En sak som man kan göra är att "fulstarta" vågformsrekonstruktionen. Det går, och får till följd att ljudkvaliteten stiger medan man spelar. 16 bitars upplösning för trunkeringsdisorsionen når man då efter runt en halv sekund.


Vh, iö

- - - - -

PS. Resonemanget härovan utgår ifrån en samplingsfrekvens på lite mera än 2 x 20 000 Hz.


Vh, iö

[Svante]

Ok, upplys mig då, om HDMI-protokollet har hand om synkningen, hur hanteras då DACar med olika fördröjning? Talar DACen om för sändaren hur mycket fördröjning den har? Isf, vad är problemet med att ha en DAC med lång fördröjning?

[Johan_Lindroos]

Bildvisare och ljudavkodare har inbyggda värden om deras respektive fördröjningar och kommunicerar detta över HDMI-protokollet. "Basic stuff". Dock funkar det ofta inte så bra i praktiken är min egen uppfattning. Särkilt inte om man har många olika apparater och skärmar anslutna. Jag behöver ofta fingra på läppsynkjusteringen.

[Svante]

Bildvisare och ljudavkodare har inbyggda värden om deras respektive fördröjningar och kommunicerar detta över HDMI-protokollet. "Basic stuff". Dock funkar det ofta inte så bra i praktiken är min egen uppfattning. Särkilt inte om man har många olika apparater och skärmar anslutna. Jag behöver ofta fingra på läppsynkjusteringen.

Ok, så alltså är det bra om olika DACar har väsentligt olika fördröjning; det kommer ju att leda till att funktionen till slut kommer att funka. Om skillnaderna är på gränsen till det uppfattbara så kommer det inte att lösa sig och då sitter vi med ett halvdåligt system.

[petersteindl]

...
Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare.

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

PS. Resonemanget härovan utgår ifrån en samplingsfrekvens på lite mera än 2 x 20 000 Hz.

Vh, iö

Ingvar, det finns helt andra sätt att göra detta på som gör att man exempelvis får 256 000 tappar d v s samples delay med totalt sett inte mer än 45 ms fördröjning. Det sker då upsampling i de olika stegen. Då har man dessutom alla beräkningar i 36 bitar vilket blir ett krav om man skall beräkna korrekta resultat med lågt digitalt brus. Dessutom kan man använda ett betydligt snyggare tidsfönster än rektangulärt d v s trunkering.

I den DAC som jag nu utvecklar med lilltroll så kan vi få 5 000 000 samples delay d v s taps i de digitala filtren där tidsfördröjningen totalt blir 55,36 ms d v s lite drygt 55 ms. Det är då förenat med upsampling vilket är en självklarhet om man skall införa digitala filter. Då kan man räkna baklänges och få fram vilken upsampling vi har.

Då man väljer antalet taps i varje upsamplingssteg så bör man veta att efter ett visst antal taps så är nivån på sincen lägre än exempelvis LSB på 16 bitar och antingen har man ett tidsfönster som anpassas eller så får man räkna med exempelvis 24 bitar eller mer. Annars blir ett stort antal taps helt meningslöst. Jag kan redan nu säga att det faktiskt finns de omvandlare där efter ett visst antal taps multiplikationen d v s resultatet alltid blir noll eftersom upplösningen i processen är för låg, men det kan ju vara kul att skryta med en massa taps. Jag och lilltroll väljer en annan väg.

Vi har just nu simulerat hur de olika stegen ser ut med 36 bitar i varje steg och det verkar räcka och bli över. Dagens kretsar är så pass snabba att man kan få otrolig beräkningskapacitet om man utnyttjar kretsarna intill max.

Efter diskussionerna i den här tråden har jag beslutat att se vad vi kan uppnå om vi utnyttjar befintlig FPGA till 99 %. Hittills har vi utnyttjat 17 % vilket innebär att befintlig FPGA sover i 83 % Jag har bestämt att den skall f-n upp och jobba i sitt anletes svett, FPGAn alltså.

Det är bara lite annorlunda mjukvara som skall till. Det arbetet blir kanske klart i nästa vecka.

Med vänlig hälsning
Peter

[Svante]

Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare..

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

Att låtsas som att det inte är något problem duger inte. I praktiken så behöver man tillgripa andra (intelligentare) lösningar än att förlänga sincen så den blir så lång att man kan trunkera den bryskt utan att det ger störande artefakter. En sak som man kan göra är att "fulstarta" vågformsrekonstruktionen. Det går, och får till följd att ljudkvaliteten stiger medan man spelar. 16 bitars upplösning för trunkeringsdisorsionen når man då efter runt en halv sekund.

Ja, den argumentationen är inget vidare. Det ideala impulssvaret för rekonstruktionsfiltret må vara en sinc, men det betyder inte att den bästa realiseringen av ett FIR-filter innehåller en fultrunkerad sinc. Förstås ska man vid dimensioneringen av rekonstruktionsfiltret släppa tidsdomänen och i stället optimera mot det filtret ska göra, nämligen ta bort allt över fs/2 och låta allt under fs/2 vara kvar. Den dimensioneringen görs bäst i frekvensdomänen, tumregelmässiga resonemang i tidsdomänen med fultrunkering med rektangulärt fönster leder lätt fel precis som du visar. Vågformen som lagras i FIR-filtrets koefficienter ska förstås starta mjukt och snyggt, allt annat är dumt. Jag använder i bästa förinställningen på min omsamplare 640 sinc-perioder* med den får jag filtersvar enligt bilderna. Filtrets dämpning i spärrbandet över 22300 Hz är aningen bättre, det som syns är brusgolvet från de 32-bits floatar som används. Filterkoefficienterna är faktiskt skapade utgående från en algoritm i tidsdomänen, men valet av parametrar har jag utvärderat i frekvensdomänen. Lilltrolls dimensionering är (gissar jag) helt optimerad i frekvensdomänen (med Matlab?) och därmed antagligen ytterligare optimerad.

Att stirra sig blind på tidsdomänen, sincen och förenklade metoder att förutse hur många tappar som behövs när man dimensionerar rekonstruktionsfilter blir ungefär lika fel som om man beräknar tidsupplösningen som 1/fs.

*Det är bättre att tala om antal sinc-perioder än antal tappar, eftersom antalet tappar skalar med grad av översampling. 640 sinc-perioder motsvarar 29 ms vid 44100 Hz samplingsfrekvens. Jag har alltså pratat om fördröjningar i den storleksordningen hela tiden.

[Lazyworm]

Efter diskussionerna i den här tråden har jag beslutat att se vad vi kan uppnå om vi utnyttjar befintlig FPGA till 99 %. Hittills har vi utnyttjat 17 % vilket innebär att befintlig FPGA sover i 83 % Jag har bestämt att den skall f-n upp och jobba i sitt anletes svett, FPGAn alltså.

Det är bara lite annorlunda mjukvara som skall till. Det arbetet blir kanske klart i nästa vecka.

Med vänlig hälsning
Peter

FPGAn har verkligen tagit sig in i finrummet sista åren
Jag är på Väg mot MS i Redmond nu och ska bl.a diskutera neurala nätverk och machine learning där MS har tagit upp FPGAerna i skyn och löser mer och mer extremt krävande problem med FPGAer.

FPGA i molnet

[petersteindl]

Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare..

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

Att låtsas som att det inte är något problem duger inte. I praktiken så behöver man tillgripa andra (intelligentare) lösningar än att förlänga sincen så den blir så lång att man kan trunkera den bryskt utan att det ger störande artefakter. En sak som man kan göra är att "fulstarta" vågformsrekonstruktionen. Det går, och får till följd att ljudkvaliteten stiger medan man spelar. 16 bitars upplösning för trunkeringsdisorsionen når man då efter runt en halv sekund.

Ja, den argumentationen är inget vidare. Det ideala impulssvaret för rekonstruktionsfiltret må vara en sinc, men det betyder inte att den bästa realiseringen av ett FIR-filter innehåller en fultrunkerad sinc. Förstås ska man vid dimensioneringen av rekonstruktionsfiltret släppa tidsdomänen och i stället optimera mot det filtret ska göra, nämligen ta bort allt över fs/2 och låta allt under fs/2 vara kvar. Den dimensioneringen görs bäst i frekvensdomänen, tumregelmässiga resonemang i tidsdomänen med fultrunkering med rektangulärt fönster leder lätt fel precis som du visar. Vågformen som lagras i FIR-filtrets koefficienter ska förstås starta mjukt och snyggt, allt annat är dumt. Jag använder i bästa förinställningen på min omsamplare 640 sinc-perioder* med den får jag filtersvar enligt bilderna. Filtrets dämpning i spärrbandet över 22300 Hz är aningen bättre, det som syns är brusgolvet från de 32-bits floatar som används. Filterkoefficienterna är faktiskt skapade utgående från en algoritm i tidsdomänen, men valet av parametrar har jag utvärderat i frekvensdomänen. Lilltrolls dimensionering är (gissar jag) helt optimerad i frekvensdomänen (med Matlab?) och därmed antagligen ytterligare optimerad.

Att stirra sig blind på tidsdomänen, sincen och förenklade metoder att förutse hur många tappar som behövs när man dimensionerar rekonstruktionsfilter blir ungefär lika fel som om man beräknar tidsupplösningen som 1/fs.

*Det är bättre att tala om antal sinc-perioder än antal tappar, eftersom antalet tappar skalar med grad av översampling. 640 sinc-perioder motsvarar 29 ms vid 44100 Hz samplingsfrekvens. Jag har alltså pratat om fördröjningar i den storleksordningen hela tiden.

Jag ser av dina kurver att de inte är i närheten av att satisfiera följande du skriver.

Får jag påpeka då att det osnygga ligger i valet att inte lägga transitionsbandet under fs/2 utan att lägga det halvvägs kring fs/2. Det blir så om man stirrar sig blind på att impulssvaret ska vara en sinc med rippel som motsvarar fs/2. Man behöver lägga ripplet lite långsammare så bryter filtret lite lägre. Det är ren slentrian att inte göra det.

Därför är det osnyggt, även om hörbarheten i de flesta (alla?) fall är noll.

Riktigt bra omsamplare gör det snyggt. Chords två omvandlare som jag har testat gör det också. De flesta DACar gör det inte. Det är ingen stor grej, men nu när allt annat är så nära perfekt så kan man väl fixa till även detta?

Vad är halvvägs kring fs/2? Menar du 11 kHz för CD-systemet?

Just nu ligger cut off i vår DAC på 21 kHz då fs=44,1 kHz. Vid 21 kHz är nivån ungefär -50 dB.

Jag syftar på den mätstandard som de flesta tillverkare verkar använda där transitionsbandet ligger mellan 0,454*fs och 0,546*fs, vilket översatt till 44,1 kHz samplingsfrekvens blir 20-24,1 kHz. Har man förstått sampling, och köper tanken att man har lagt fs/2 vid 22,05 kHz, dvs en gnutta över 20 kHz (det som brukar anses vara den högsta hörbara frekvensen) så borde transitionsbandet ligga mellan 20 och 22,05 kHz. Eller mellan 0,454*fs och 0,5*fs.

Din kurva kör kringlor kring de standarder du nämner. Vad ligger du på? Mellan 0,492*fs och 0,5*fs?

Det är i alla fall ungefär så som vi nu optimerar där fs/2 skall ligga på ungefär -180 dB.

Med vänlig hälsning
Peter

[Svante]

Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare..

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

Att låtsas som att det inte är något problem duger inte. I praktiken så behöver man tillgripa andra (intelligentare) lösningar än att förlänga sincen så den blir så lång att man kan trunkera den bryskt utan att det ger störande artefakter. En sak som man kan göra är att "fulstarta" vågformsrekonstruktionen. Det går, och får till följd att ljudkvaliteten stiger medan man spelar. 16 bitars upplösning för trunkeringsdisorsionen når man då efter runt en halv sekund.

Ja, den argumentationen är inget vidare. Det ideala impulssvaret för rekonstruktionsfiltret må vara en sinc, men det betyder inte att den bästa realiseringen av ett FIR-filter innehåller en fultrunkerad sinc. Förstås ska man vid dimensioneringen av rekonstruktionsfiltret släppa tidsdomänen och i stället optimera mot det filtret ska göra, nämligen ta bort allt över fs/2 och låta allt under fs/2 vara kvar. Den dimensioneringen görs bäst i frekvensdomänen, tumregelmässiga resonemang i tidsdomänen med fultrunkering med rektangulärt fönster leder lätt fel precis som du visar. Vågformen som lagras i FIR-filtrets koefficienter ska förstås starta mjukt och snyggt, allt annat är dumt. Jag använder i bästa förinställningen på min omsamplare 640 sinc-perioder* med den får jag filtersvar enligt bilderna. Filtrets dämpning i spärrbandet över 22300 Hz är aningen bättre, det som syns är brusgolvet från de 32-bits floatar som används. Filterkoefficienterna är faktiskt skapade utgående från en algoritm i tidsdomänen, men valet av parametrar har jag utvärderat i frekvensdomänen. Lilltrolls dimensionering är (gissar jag) helt optimerad i frekvensdomänen (med Matlab?) och därmed antagligen ytterligare optimerad.

Att stirra sig blind på tidsdomänen, sincen och förenklade metoder att förutse hur många tappar som behövs när man dimensionerar rekonstruktionsfilter blir ungefär lika fel som om man beräknar tidsupplösningen som 1/fs.

*Det är bättre att tala om antal sinc-perioder än antal tappar, eftersom antalet tappar skalar med grad av översampling. 640 sinc-perioder motsvarar 29 ms vid 44100 Hz samplingsfrekvens. Jag har alltså pratat om fördröjningar i den storleksordningen hela tiden.

Jag ser av dina kurver att de inte är i närheten av att satisfiera följande du skriver.

Vad är halvvägs kring fs/2? Menar du 11 kHz för CD-systemet?

Just nu ligger cut off i vår DAC på 21 kHz då fs=44,1 kHz. Vid 21 kHz är nivån ungefär -50 dB.

Jag syftar på den mätstandard som de flesta tillverkare verkar använda där transitionsbandet ligger mellan 0,454*fs och 0,546*fs, vilket översatt till 44,1 kHz samplingsfrekvens blir 20-24,1 kHz. Har man förstått sampling, och köper tanken att man har lagt fs/2 vid 22,05 kHz, dvs en gnutta över 20 kHz (det som brukar anses vara den högsta hörbara frekvensen) så borde transitionsbandet ligga mellan 20 och 22,05 kHz. Eller mellan 0,454*fs och 0,5*fs.

Din kurva kör kringlor kring de standarder du nämner. Vad ligger du på? Mellan 0,492*fs och 0,5*fs?

Det är i alla fall ungefär så som vi nu optimerar där fs/2 skall ligga på ungefär -180 dB.

Med vänlig hälsning
Peter

Nej, just det, inställningen ger "bara"-113 dB vid fs/2. Vid 0,506 fs drunknar den dock i 24-bitsbruset, dvs ligger under -150 dB. Jag skulle kanske flytta ner knäet mot lite lägre frekvenser så att den börjar falla redan vid 21500 Hz. Eller inte. Man kan också nämna att det är digitalt MÄTTA kurvor du ser, det är alltså spektrum för en riktig (digital) signal som har passerat genom filtret. Jag är rätt övertygad om att filterkurvan du visade är en teoretisk beräkning av filterkurvan (?). Hur ser spektrum för en 24-bitssignal ut som har passerat din filterimplementation?

Nu är båda våra filterkonstruktioner långt bättre än de i de flesta DACar på marknaden. Jag skulle kunna posta valfri mätning på någon DAC här, men låter bli. Det blir ju lite orättvist när signalen faktiskt har blivit analog på vägen också. Våra kurvor är ju tagna helt i den digitala domänen. Hursomhelst så brukar dämpningen vid fs/2 vara c:a 3-15 dB, typiskt och det är dåligt. Eller "osnyggt" om man inte vill vara så hård.

[petersteindl]

Nej, just det, inställningen ger "bara"-113 dB vid fs/2. Vid 0,506 fs drunknar den dock i 24-bitsbruset, dvs ligger under -150 dB. Jag skulle kanske flytta ner knäet mot lite lägre frekvenser så att den börjar falla redan vid 21500 Hz. Eller inte. Man kan också nämna att det är digitalt MÄTTA kurvor du ser, det är alltså spektrum för en riktig (digital) signal som har passerat genom filtret. Jag är rätt övertygad om att filterkurvan du visade är en teoretisk beräkning av filterkurvan (?). Hur ser spektrum för en 24-bitssignal ut som har passerat din filterimplementation?

Nu är båda våra filterkonstruktioner långt bättre än de i de flesta DACar på marknaden. Jag skulle kunna posta valfri mätning på någon DAC här, men låter bli. Det blir ju lite orättvist när signalen faktiskt har blivit analog på vägen också. Våra kurvor är ju tagna helt i den digitala domänen. Hursomhelst så brukar dämpningen vid fs/2 vara c:a 3-15 dB, typiskt och det är dåligt. Eller "osnyggt" om man inte vill vara så hård.

Vi har dessa kurvor också, eller snarast vi tittar på simuleringar med testtoner in. Så småningom med ytterligare optimering lägger jag upp lite kurvor. De ser ganska fantastiskt bra ut. Lilltroll kör hårt. Vi använder två toner, 19 kHz + 20 kHz på -6dB med 24 bitar Input och då tittar vi på output. Jag tror inte att mätning ger stor avvikelse. Det har det inte gjort tidigare.

Alla upsamplingssteg skall optimeras och köras tillsammans för att totalen skall optimeras.

Med vänlig hälsning
Peter

[IngOehman]

Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare..

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

Att låtsas som att det inte är något problem duger inte. I praktiken så behöver man tillgripa andra (intelligentare) lösningar än att förlänga sincen så den blir så lång att man kan trunkera den bryskt utan att det ger störande artefakter. En sak som man kan göra är att "fulstarta" vågformsrekonstruktionen. Det går, och får till följd att ljudkvaliteten stiger medan man spelar. 16 bitars upplösning för trunkeringsdisorsionen når man då efter runt en halv sekund.

Ja, den argumentationen är inget vidare. Det ideala impulssvaret för rekonstruktionsfiltret må vara en sinc, men det betyder inte att den bästa realiseringen av ett FIR-filter innehåller en fultrunkerad sinc. Förstås ska man vid dimensioneringen av rekonstruktionsfiltret släppa tidsdomänen och i stället optimera mot det filtret ska göra, nämligen ta bort allt över fs/2 och låta allt under fs/2 vara kvar. Den dimensioneringen görs bäst i frekvensdomänen, tumregelmässiga resonemang i tidsdomänen med fultrunkering med rektangulärt fönster leder lätt fel precis som du visar. Vågformen som lagras i FIR-filtrets koefficienter ska förstås starta mjukt och snyggt, allt annat är dumt. Jag använder i bästa förinställningen på min omsamplare 640 sinc-perioder* med den får jag filtersvar enligt bilderna. Filtrets dämpning i spärrbandet över 22300 Hz är aningen bättre, det som syns är brusgolvet från de 32-bits floatar som används. Filterkoefficienterna är faktiskt skapade utgående från en algoritm i tidsdomänen, men valet av parametrar har jag utvärderat i frekvensdomänen. Lilltrolls dimensionering är (gissar jag) helt optimerad i frekvensdomänen (med Matlab?) och därmed antagligen ytterligare optimerad.

Att stirra sig blind på tidsdomänen, sincen och förenklade metoder att förutse hur många tappar som behövs när man dimensionerar rekonstruktionsfilter blir ungefär lika fel som om man beräknar tidsupplösningen som 1/fs.

*Det är bättre att tala om antal sinc-perioder än antal tappar, eftersom antalet tappar skalar med grad av översampling. 640 sinc-perioder motsvarar 29 ms vid 44100 Hz samplingsfrekvens. Jag har alltså pratat om fördröjningar i den storleksordningen hela tiden.

När du nu håller med om allt det jag skriver, varför gör du så stora ansträngningar för att få det att verka som motsatsen? Trist retorik.

Är det en sorts hämnd för de fel jag påpekade i ditt tidigare inlägg?


Vh, iö

[IngOehman]

Nej, så är det inte.

Dels är det INTE meningen att användaren skall ta hand om synkningen själv. Det är automatiskt och en del av vad HDMI-protokollet medger. Bildvisaren berättar för hemmabioförstärkaren om sin delay (som även kan ändra sig när man ändrar bildvisarens insrällningar, och då berättas även det, det är alltså ingen konstant utan ett värde som kan ändra sig beroende på hur bildvisaren är inställd).

Dessutom är fördröjningen mellan olika DACar alls inte samma. Olika DACar har väldigt olika fördröjningar. Vet inte varför du tror att de skulle vara väldigt lika varandra? De som har längst fördröjning har hundratals gånger mera fördröjning än de med kortast.

Däremot är det i normalfallet så, att fördröjningen för bilden är mångfaldigt större än den som gäller ljudet, och det är det som är skälet till att man hanterar synkningen genom att anpassa ljudets fördröjning. Och en bra sak med det är att det gör behovet av att lagra data mindre.

Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare..

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

Att låtsas som att det inte är något problem duger inte. I praktiken så behöver man tillgripa andra (intelligentare) lösningar än att förlänga sincen så den blir så lång att man kan trunkera den bryskt utan att det ger störande artefakter. En sak som man kan göra är att "fulstarta" vågformsrekonstruktionen. Det går, och får till följd att ljudkvaliteten stiger medan man spelar. 16 bitars upplösning för trunkeringsdisorsionen når man då efter runt en halv sekund.


Vh, iö

- - - - -

PS. Resonemanget härovan utgår ifrån en samplingsfrekvens på lite mera än 2 x 20 000 Hz.


Vh, iö

Ok, upplys mig då, om HDMI-protokollet har hand om synkningen, hur hanteras då DACar med olika fördröjning? Talar DACen om för sändaren hur mycket fördröjning den har? Isf, vad är problemet med att ha en DAC med lång fördröjning?

Det fungerar i hemmabioapparater. Den känner till fördröjningen från sina egna DA-omvandlare. Hur lång fördröjningen är spelar alltså ingen roll så länge den är rimlig - rimlig i betydelsen att den inte är större än att rätt läppsynk uppnås genom att ÖKA fördröjningen av ljudsignalerna.


Vh, iö


Vh, iö


Vh, iö

[Svante]

När du nu håller med om allt det jag skriver, varför gör du så stora ansträngningar för att få det att verka som motsatsen? Trist retorik.

Är det en sorts hämnd för de fel jag påpekade i ditt tidigare inlägg?


Vh, iö

Eh, va?

Jag bara förklarar att det inte behövs ett impulssvar på två minuter för att ge tillräckligt bra rekonstruktion av en 24/44-signal. Och invänder emot ditt retoriska grepp att felberäkna hur långa FIR-filter man behöver. Jag vet inte om du inser det, men du får det att framstå som att jag argumenterade för filter med 2 minuters väntetid. Varför skulle du annars skriva så? Fönstring av sincen görs på ett eller annat sätt i alla vettiga konstruktioner och jag visade dig ett exempel på att ett 29 ms fönster kan ge en mycket bättre rekonstruktion än vad som görs i dagens DACar. Utöver fönstring behöver man flytta ner brytfrekvensen en gnutta för att få det vettigt.

Alltså: Min poäng här är att delayen i en högpresterande DAC är inte ett problem om man inte måste svara omedelbart på input, som i spel eller vid live-inspelning där man lyssnar på en AD-DA-kedja. Med film finns både bild och ljud lagrat och det är inga problem att tjuvtitta på de sampel som finns om man vill. Och det var ju bra att få veta att HDMI-standarden föreskriver att DACen talar om vad den har för delay, det visste jag inte. Men påståendet att man ska behöva vänta i två minuter, skrivet med samma nivå av okunnighet som att tidsupplösningen i ett samplat system är 1/fs. Varför skriver du så, du vet ju bättre?

Det finns DACar med rekonstruktionsfilter kortare delay tack vare nära kausala impulssvar. Det får till följd att fasgången inte blir linjär, vilket inte behöver vara allvarligt. De kan behövas i tex studiosammanhang för att få en medhörning som inte är fördröjd. Men om man inte har de kraven så gör det inget ens om DACen har en förhållandevis stor delay eftersom man kan tjuvtitta på sampel om man har dem lagrade. Och vid omsampling tänker åtminstone jag just så; filtret har inte en delay, men det har möjlightet att titta på den signal som ska komma. På så sätt får man ingen fördröjning mellan infil och utfil, trots att sincen börjar 15 ms före huvudbullen i sincen.

[Svante]

Alla upsamplingssteg skall optimeras och köras tillsammans för att totalen skall optimeras.

Varför samplar ni upp i flera steg?

[IngOehman]

Det är ganska vanligt att man gör så.


Dels betyder det stt man kan förenkla processen till linjär interpolering för den senare processen. Det vill säga - linjär interpolering och en brusformning som inte går av för hackor...

...
Nu finns ju väldigt stora och snabba minnen till bra priser, men om man skulle göra en idealisk sinc med upplösning som tangerar blygsamma 16 bitars upplösning trots grov trunkering av sincen, så talar vi om delayer om 20 000 samples, alltså runt en halv sekund. Vill vi närma oss 20 bitar så blir det 300 000 samples... Det är en klart märkbar delay, även när man bara spelar CD, även om man självklart kan hävda att det går att trycka på play 8 sekunder tidigare.

Men om man vill ha 24 bitars upplösning då, även i det korta perspektivet? Det blir typ 5 000 000 samples delay, alltså runt två minuter i fördröjning...

PS. Resonemanget härovan utgår ifrån en samplingsfrekvens på lite mera än 2 x 20 000 Hz.
Vh, iö

Ingvar, det finns helt andra sätt att göra detta på som gör att man exempelvis får 256 000 tappar d v s samples delay med totalt sett inte mer än 45 ms fördröjning. Det sker då upsampling i de olika stegen. Då har man dessutom alla beräkningar i 36 bitar vilket blir ett krav om man skall beräkna korrekta resultat med lågt digitalt brus. Dessutom kan man använda ett betydligt snyggare tidsfönster än rektangulärt d v s trunkering.

Självklart! Det skriver jag ju om (den del av mitt inlägg som du valde att inte citera).

I den DAC som jag nu utvecklar med lilltroll så kan vi få 5 000 000 samples delay d v s taps i de digitala filtren där tidsfördröjningen totalt blir 55,36 ms d v s lite drygt 55 ms. Det är då förenat med upsampling vilket är en självklarhet om man skall införa digitala filter.

Javisst. Det folk kallar för "digitalt filter" i sådana här sammanhang är ju frekvensinnehållet för den form som man ger rekonstruktionspulsen, närmare bestämt hur man beskriver vågformen mellan de ögonblick som signalen samplats i. Och alla dessa nya ögonblick inklämda emellan samplingsögonblicken, är de som "är" översamplingens alla nya ögonblick!

Det går även alldeles utmärkt att göra "filter" med avsevärt mycket kortare delay än så. Faktorer som branthet och fassymmetri har stor betydelse för hur kort delay man kan nå.

Vill man ha perfekt fassymmetri och extrem branthet (kort avstånd från full signal till -144 dB, eller vad man nu vill klara för spärrbandsdämpning) så blir rekonstruktionspulsen låååååååång....


Vh, iö

[petersteindl]

Alla upsamplingssteg skall optimeras och köras tillsammans för att totalen skall optimeras.

Varför samplar ni upp i flera steg?

DACen kan ta emot signaler med olika format, typ Fs 44,1/48/88,2/96/176,4/192/352,8/384/705,6/768 kHz. Upsampling sker därefter 8 ggr och sedan 8 eller 16 ggr. Beroende på format in behövs det olika steg. Den sista upsamplingen har skett med linjär interpolation. Vi skall se om vi istället kan använda sincen även där.

Med befintlig FPGA vet jag inte. Med senaste generation är det inga problem.

Mvh
Peter

[Svante]

Alla upsamplingssteg skall optimeras och köras tillsammans för att totalen skall optimeras.

Varför samplar ni upp i flera steg?

DACen kan ta emot signaler med olika format, typ Fs 44,1/48/88,2/96/176,4/192/352,8/384/705,6/768 kHz. Upsampling sker därefter 8 ggr och sedan 8 eller 16 ggr. Beroende på format in behövs det olika steg. Den sista upsamplingen har skett med linjär interpolation. Vi skall se om vi istället kan använda sincen även där.

Med befintlig FPGA vet jag inte. Med senaste generation är det inga problem.

Mvh
Peter

Aha, har ni alltså en fix (hög) samplingsfrekvens i det som egentligen är DACen och samplar om alla olika till denna enda samplingsfrekvens? Ja, då får man tänka både en och två gånger, att interpolera en 44100Hz-signal till 192000Hz (ni har kanske en annan "hög" samplingsfrekvens) innebär ju att de nya samplen hamnar på olika ställen mellan de ursprungliga. Men så länge det är ett rationellt tal som faktor mellan de två samplingsfrekvenserna går det. Större heltal i förhållandet gör dock att man behöver mer minne att lagra koefficienter i även om det inte behövs mer beräkningskapacitet. Det heter nåt speciellt det där... Hmm. Ah, "polyphase filtering" heter det. Då räknar man ut tappar för den gemensamma jättehöga* samplingsfrekvensen, men använder inte alla för varje nytt sampel. Har man vissa fixa frekvenser, vilket man har i DAC så vet man precis vilka beräkningar som behöver göras. Jag fick lite bök i min omsamplare, för jag ville kunna sampla om hur som helst. Så jag använder polyphase om frekvensförhållandet går att beskriva som ett rationellt tal med heltal <2000. Annars räknar jag ut koefficienterna "on-the-fly", vilket blir en faktor 10 långsammare, ungefär.

*Vid tex 44100->48000 kan man se det som att man samplar upp till 160*44100=7056000Hz och sedan samplar ner till 7056000/147=48000 Hz. Koefficienter behövs då till motsvarande 7,056 MHz samplingsfrekvens, men samplen behöver bara räknas ut motsvarande 48 kHz samplingsfrekvens; man använder bara en del av koefficienterna per sampel, men vilka man använder roterar.