Gisteren nog even het schema bekeken. In de huidige implementatie zit de shift klok en de register klok van d 595 aan elkaar vast op dezelfde klok. Je zou bovenstaande kunnen ondervangen door voor de shiftklok de klok van het U30 bordje te gebruiken en voor de registerklok direct de kristalklok. Je hoeft dan de klok en data van het U30 bordje ook niet te resampelen. Uiteindelijk is die registerklok essentieel voor minimale jitter. En als je dan de kristalklok inverteert heb je daar extra timing/fasemarge. Hangt ook een beetje van de onderlinge delays af. Zou je op de scoop moeten bekijken.
Zou wellicht kunnen, maar ik wil niet het risico lopen op dataverlies doordat de klokken net wat verschillend zijn in frequentie. Ik ben tevreden met DSD512
-edit- Wat een alternatief zou kunnen zijn, is de dataklok op SHCP zetten en de masterklok op STCP. Dan gebruik je eigenlijk het schuifregister zelf als resampel circuit. En dan moet inderdaad de masterklok op die ingang worden geinverteerd, bij gebruik van verschillende klokken op SHCP en STCP.
Laatst gewijzigd door jeroen_d op za 10 aug 2024, 11:35, 2 keer totaal gewijzigd.
Het ging mij om wat Marcel aandroeg. Die klokken verschillen onderling in frequentie alleen in hele veelvouden. Dat is met hoe je het nu zit niet anders.
Je zou bovenstaande kunnen ondervangen door voor de shiftklok de klok van het U30 bordje te gebruiken en voor de registerklok direct de kristalklok. Je hoeft dan de klok en data van het U30 bordje ook niet te resampelen. Uiteindelijk is die registerklok essentieel voor minimale jitter. En als je dan de kristalklok inverteert heb je daar extra timing/fasemarge. Hangt ook een beetje van de onderlinge delays af. Zou je op de scoop moeten bekijken.
Ja, dat is een goeie. De registerklok is dan schoner dan een gehersynchroniseerde bitklok ooit kan zijn.
Betekent wel een extra klok leiding langs alle registers. En jitterende data die met een jitterende klok het schuifregister in gaat. Wellicht is het beste om de klok wel te splitsen dus de masterklok op het storage/outputregister te zetten maar het herklokken te handhaven zodat de dsd data en klok schoon het schuifregister ingaat
Weet niet of dat nog veel uit gaat maken dan. Zeker niet als je met alternerende klokflanken werkt. Dan heb je best wel wat timing marge. Je blijft dan i.i.g. vast zitten aan een klok met dubbele samplerate. Denk eigenlijk dat het belangrijkste is dat er geen data naar de schone registerklok kan overspreken via de print.
Of dat de jitterende klok langs de schone klok leiding loopt. Ik denk dat ik het maar zo laat als dat het nu is. Het wordt nodeloos ingewikkeld en de huidige opzet is elegant. Dat er een dubbele kloksnelheid nodig is, zie ik niet als een probleem.
Ik heb gemerkt dat bij overgang van DSD256 naar DSD512 dit alleen zin heeft als je ook de beste modulator (in mijn geval ASDM7ECv3) van HQPlayer kan blijven gebruiken. Als je naar een mindere modulator moet, omdat de PC de hogere DSD snelheid niet aankan, dan gooi je het kind met het badwater weg. En vooralsnog is er dan naar mijn smaak een te dure PC nodig om DSD1024 meerwaarde te kunnen laten hebben. En dan nog zal het verschil marginaal zijn. DSD256 naar DSD512 is al een klein verschil in kwaliteit, de stap naar DSD1024 zal echt marginaal worden.
Dat ben ik met je eens. Niet alleen vraagt een hogere DSD rate een duurdere PC met krachtiger processor, het vraagt ook veel meer wattjes voor je PC waar je niet veel of misschien wel helemaal niks voor terug krijgt. Op een I5 gaat PCM --> DSD256 nog lekker soepel. En dat kan makkelijk met de huidige opzet. Een PC die hard moet werken vraagt ook om een niet meer zo geruisloze fan.
Als ik het goed begrijp, gebruikt bijna niemand een zuivere DSD-DAC om DSD-bestanden mee af te spelen...
Wat betreft het omzetten van PCM naar iets DSD-achtigs, dat kan ook met een FPGA-module. Die in mijn buizen-DAC zet PCM om in een bitstroom van 27 Mbit/s, equivalent aan DSD612,24489..., en heeft niet eens een ventilator nodig. Het is wel een vrij grote en dus dure FPGA, ik ben aan het kijken of het ook kleiner kan.
Ik gebruik voor de TV een klein ander dacje wat op de voorversterker ingang staat, is dan voldoende.
En de Echte muziek opnames gaan via de Mac mini met Linux en daar naar de USB van Xing U30.
Er zijn duidelijk vele wegen naar Rome Had je dit bordje toevallig liggen? Begrijp van Jeroen eindje terug dat het DSD'it bordje met dubbele SRC beter presteert op dat vlak.
Ja en het DSD'it bordje gebruikt de hardware upsampling niet als er DSD signaal binnenkomt. En mocht je er via een SPDIF interface PCM ingooien dan werkt dat natuurlijk ook want wordt dan ook omgezet naar DSD.
Als ik het goed begrijp, gebruikt bijna niemand een zuivere DSD-DAC om DSD-bestanden mee af te spelen...
Ja, kan wel, maar meeste DSD bronmateriaal is DSD64. En als je dat door HQPlayer naar DSD256 laat omzetten klinkt ook dat gewoon beter.
Tenzij je van nativeDSD de hoge resolutie DSD bestanden koopt. Maar dat is echt een niche.
Ik ga nog eens kijken naar apart voeden van de Xing U30. Leverde niet veel op met de Amanero, maar bij de Xing U30 werkt het net wat anders. Die heeft een extra USB ontvanger chip die blijvend afhankelijk is van de 5V USB kabelspanning. Maar de rest van het bordje kan je eigen voeding geven. Je ziet ook dat de CPU, CPLD en klokken ieder hun eigen spanningsregelaar hebben. Wat dat betreft is de U30 qua opbouw fundamenteel mooier dan de Amanero. En dat hoor je. Zit waarschijnlijk ook in de andere chip, Xilink CPLD op de Amanero vs Altera CPLD op de U30. De CPU is ook wat krachtiger, Amanero moet het doen met een ARM Cortex M3, de Xing U30 heeft een ARM Cortex M4.
Ben je hier nog mee bezig geweest?
Ik heb vandaag ook even zitten kijken maar omzetten durf ik nu eigenlijk nog niet te doen.
Hierboven zie je in het geel het 5V spoor met nog een verbinding naar de Chip er onder.
Zou ik L1 verwijderen dan blijft deze spanningsloos en gaat het niet werken.
misschien het beste dan jet pootje van de USB connector los solderen.
Andere optie is dat ik wel de L1 los haal, de chip zal dan nog door de USB connector gevoed worden maar de rest niet meer.
Wat is wijsheid hier?
Wat is daarvan het nut nog als je het zuivere DSD dac bordje al geïsoleerd hebt voor de klok en data en de femto masterklok daarvan gebruikt voor het U30 bordje? Van extra isolatie gaat dat U30 bordje dan toch niet beter/nauwkeuriger rekenen? De verschillen tussen Amanero en Xing zijn toch ook firmware/software implementatie lijkt mij.
Dat je verder ook los bent van de PC voeding, alleen aarde is dan nog gekoppeld.
Bij de Amanero maakte dat nog al verschil en ik lees op meerdere fora dat dit ook veen de U3 verschil maakt.
Dus dan wordt je benieuwd en aangezien de U30 al een plekje heeft voor een header lijkt deze daar al op te zijn voorbereid.
Ik heb gewoon het 0-ohm weerstandje verwijderd. Daar zit al plek voor een opsteekjumper waarmee je eenvoudig de oude situatie herstelt. Ik laat de voeding van de usb ontvanger gewoon intact die blijft vanaf de pc. De andere twee chips worden van een lokale schone voeding voorzien op deze wijze met verwijderen van de 0-ohm en op dat punt een schone 5V voeding.
Andere Amanero bordjes werken allemaal met twee chips. Alleen de U30 heeft die separate extra derde USB interface chip gevoed vanuit de USB connector. Ik denk dat ze het zo bewust gedaan hebben en dat het geen toegevoegde waarde heeft deze ook nog apart te voeden https://www.microchip.com/en-us/product/usb3300
Had je dit bordje toevallig liggen? Begrijp van Jeroen eindje terug dat het DSD'it bordje met dubbele SRC beter presteert op dat vlak.
Jeroen mag het zelf zeggen