xeizo skrev:Nja, här dras det ju lite felaktiga slutsatser i det sista posterna, trots ingenjörer inblandade. Det är faktiskt irrelevant hur osynkat datan förflyttar sig genom diverse bussar, luften, kopparnätet eller vadsomhelst eftersom alla moderna ljudavspelningsprogram BUFFRAR datan innan den skickas till DAC:en.
Jo, men nu tror jag att du dragit felaktiga slutsatser om vad som egentligen sagts. Du säger ju du precis det som jag precis sa -alltså att det är lite av prinsessan på ärten att hävda att lagringsmediet spelar roll då transporten från sagda medium sker högst tidsdiskontinuerligt. Det enda som spelar roll i slutändan är utklockningen och dess jitter.
xeizo skrev:Realtime i all ära, men det är inte så man spelar upp ljud.
Det som påverkar jitter och nogrannhet hos DAC:en mest är nogrannheten hos den klocka som synkar DAC-chippet, där finns det vinster att göra. Finns det en separat systemklocka så påverkar den givetvis också i den mån hur väl den synkar med DAC-klockan. Efter DAC-stadiet är det bara vanlig analogförstärkning med dom gamla vanliga analogproblemen, som för mycket kondingar i signalvägen, brum och brus etc.
Mja, jag vill nog hävda att ljuduppspelning från diskreta data är i högsta grad ett realtidsproblem (det säger du ju själv i nästa mening

).
Det är mycket riktigt som du säger att det viktigaste för digitalkonverteringens "överföringskorrekthet" till analogdomänen (förutom korrekt data, såklart) är tidpunkten som omvandlingen och latchningen av det nya analogvärdet sker i tiden.
Ett realtidsproblem är hur denna klocka egentligen skapas. En typisk DAC med SPDIF-ingång så återskapas den mha av en PLL ifrån SPDIF-dataströmmen. Man kan göra en PLL som undertrycker jitter väldigt bra, men då tar den lång tid på sig att låsa på klockan eftersom den behöver ha en lång tidskonstsnt. För en användare är det inte acceptabelt att vänta typ 10 sekunder på att få ljud när man byter spår så därför får man använda en kompromiss och acceptera att jitter slår igenom på klockan.
De första USB-ljudkorten använde isokrona endpoints för att överföra data och var likaså tvungna att derivera klockan ur den isokrona dataströmmen, vilket skapade stora problem med jitter då de PLLer som användes i början inte alls kunde hantera den mycket mer exrrema tidsdiskontinuiteten i paketströmmen som USB isokronöverföringen gav uppjov till. Förutom tvåstegs PLLer så tog man även fram andra, bättre USB-specar där USB-ljudkortet står för masterklockan och beställer sedan data uppströms utifrån det.
När man sedan gick över till HDMI så gjorde man samma misstag igen -dvs ett antal recievers uppvisade abnorma mängder symmetriska sidband (jitter) i analogutgången när ljud och testsignaöer spelades upp via HDMI...
Kontentan är att det är väldigt, väldigt svårt att göra generella uttalanden om huruvida en viss teknologi ger några ljudmässiga för-eller nackdelar generellt, om inte realtidsproblemet vid utklockningen i D/An är helt under kontroll. Om det är helt under kontroll så spelar det som är uppströms ingen roll, men det existerar idag en väldig massa system där detta är ganska långt ifrån kontrollerat och exakt...