forum.zelfbouwaudio.nl

Pjotr schreef: ↑za 10 aug 2024, 9:26

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.

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.

Zie mijn edit. Ik geloof dat we nu hetzelfde bedoelen en dat ik jou in eerste instantie verkeerd begreep.

Pjotr schreef: ↑za 10 aug 2024, 9:26

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.

Wat dan wel mogelijk is met de ROON opzet dat de PC die HQ Player voor z'n rekening neemt niet direct bij het "endpoint/bridge" hoeft te staan.

Dat is met ROON sowieso de beste opzet, met de Core en NAA ( Netwerk Audio Adapter ) separaat geeft.

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 heb in mijn voorraad muziek behoorlijk wat DSD64 oftewel .dsf files die ik afspeel met de opzet met een AK4137 opzet, en dat gaat echt lekker. Dat werkt in ieder geval met deze opzet prima, alleen dan een opname die ik dan heb met DSD256 gaat wel de mist in.

Ook waar ik dan met de koptelefoon en die met ROON opzet naar DSD gebruik gaat goed.
Of dat dan weer zo goed klinkt als met de luisprekers?

hannesie schreef: ↑zo 11 aug 2024, 0:41

Ik heb in mijn voorraad muziek behoorlijk wat DSD64 oftewel .dsf files die ik afspeel met de opzet met een AK4137 opzet, en dat gaat echt lekker.

Bedoel je dan met het DSD'it bordje? Maar als je al DSD als bron hebt wat is dan het nut ven de AK4137?

Alles wat ik via de USB ingang (Xing U30) binnen krijg, is dan via de AK4137 in die opzet naar DSD256 naar omgezet.

Dus mp3/ flac, PCM en DSD gaat naar DSD256 via het boardje.

download/file.php?id=192684&mode=view

Ah op die manier. En de S/PDIF voor het TV geluid?

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.

MarcelvdG schreef: ↑zo 11 aug 2024, 0:03

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.

jeroen_d schreef: ↑za 15 jul 2023, 14:01

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.

Schonere voeding voor de U30

De vraag was: Wat is het nut daarvan nog gezien de zuivere DSD dac al geïsoleerd is van U30 en van eigen voeding voorzien is?

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.

Kappa7 schreef: ↑vr 23 aug 2024, 16:46

Bij de Amanero maakte dat nog al verschil

jeroen_d schreef: ↑za 15 jul 2023, 14:01

Ik ga nog eens kijken naar apart voeden van de Xing U30. Leverde niet veel op met de Amanero....,

Jeroen mag het zelf zeggen

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