Een speciale SSD voor audiofielen.

[Rob_Dingen]

Luister je dan naar 2 identieke setups waarbij je in notime kunt switchen, de 1 met de oude versie software en de anderfe met de nieuwe versie software?
Als de software enige verschillen geeft in geluid 'doet' dit iets met je packets, want dan is het niet bitperfect meer.
Of heeft de software ook invloed op het D/A conversie proces, dan kan ik me er wel iets bij voorstellen, maar niet in het transport van data naar de dac, of er moet iets heel ergs mis gaan onderweg?
Als je buffer te klein is krijg je buffer underruns, oftewel dropouts. Maar geluidstechnisch?
Als je DAC bij de PC inzit kan ik me er wel iets bij voorstellen. W.b.t. bitperfect zal een SSD of HDD geen verschil geven .. maar het kan wel zo zijn dat de HDD meer invloed heeft op de voedingslijn dan een SSD. Denk aan het induceren van ruis wat invloed kan hebben op het dac gedeelte of overige componenten.

De testen worden op dezelfde PC gedaan met als referentie Jplay daarnaast een eerdere versie en de nieuwste versie van de software.
Op die manier kun je vrij snel switchen.
We gaan usb uit naar een externe DAC.
Ik heb in mijn vorige post al wat uitgelegd meer weet ik er niet van.
Maar als je me niet geloofd kom maar langs.

Wat betreft de SSD waar het hier over gaat is denk ik het enige voordeel de mogelijkheid tot een externe voeding aan te sluiten.
Ik gebruik zelf spullen van Jcat netwerk en USB kaart met een externe lineaire voeding wat ook een verbetering brengt.
Ook heb ik een SLC SSD en geheugen of dat beter is heb ik nooit getest.

Rob

[Kingpin]

De testen worden op dezelfde PC gedaan met als referentie Jplay daarnaast een eerdere versie en de nieuwste versie van de software.
Op die manier kun je vrij snel switchen.
We gaan usb uit naar een externe DAC.
Ik heb in mijn vorige post al wat uitgelegd meer weet ik er niet van.
Maar als je me niet geloofd kom maar langs.

Wat betreft de SSD waar het hier over gaat is denk ik het enige voordeel de mogelijkheid tot een externe voeding aan te sluiten.
Ik gebruik zelf spullen van Jcat netwerk en USB kaart met een externe lineaire voeding wat ook een verbetering brengt.
Ook heb ik een SLC SSD en geheugen of dat beter is heb ik nooit getest.

Rob

Ik denk ook dat het grootste voordeel hier de externe voedingen voor elk deel wat je toepast z'n meerwaarde heeft en niet zozeer het datatransport ansich.
Ik geloof best dat er 'verschillen' zijn maar niet in het datatransport zelf.
Zoals ik al aangaf 'kunnen' de losse voedingen een voordeel bieden doordat er minder ruis 'meelift' wat ook wel te verklaren is.
Ik neem je aanbod zeker een keer aan Rob, wanneer alles weer een beetje 'normaal' is. Ik ben zelf ook wel benieuwd in hoeverre de techniek is 'verbeterd' tov van mijn Touch/Lipo combi die ik destijds tegen meerdere zeer dure streamers heb getest.

[Peerless Monster]

Mooie esoterische naam.

Zoals vzzzbx
Synoniem van loodgieter.

[mmuetst]

Lineare voeding:
https://www.audiosciencereview.com/forum/index.php?threads/do-you-need-linear-power-supply-for-dacs.7021/
Als je via luidsprekers luistert in een "stille" kamer dan is er al 20 a 30 dB geluid aanwezig. Dus welke ruis hoor je dan nog?
https://nl.wikipedia.org/wiki/Geluidsniveau

[katwax]

Dat is heel simpel. Een SSD doet puur opslag, data die je bit voor bit kunt vergelijken. Alles wat je met een SSD doet kun je meten en vergelijken met dezelfde operatie tegen een andere SSD. In de meest simpele zin: je kopieert data van een andere gegevensdrager en wanneer dit klaar is vergelijk je bron en doel bit voor bit. Tenzij je SSD defect is zal dit altijd dezelfde data opleveren.

Ik doelde meer op wat ga je meten dat audio gerelateerd is.
Uiteindelijk spreken we hier over een opslag media die niets meer of minder doet dan bits schrijven en lezen wanneer dit gevraagd wordt.

Ik zit in zelfde "beperking" als jouw, ben al jaren werkzaam in IT en stel mij, door mijn techische achtergrond, zeer grote vragen bij al die audiofiele IT gerelateerde componenten.

Ik heb geen idee. Voor alle duidelijkheid; ik vind dit klinkklare onzin, precies vanwege de redenen die aangegeven worden in diverse posts.

Maar wat mij verbaast is die enorme 'cache'. Normaliter bevat een cache vluchtige gegevens, bedoeld voor snelheid bijvoorbeeld om I/O op relatief trage schijven te versnellen door de data alvast in een geheugen te zetten, of CPUs die hun data en instructies alvast binnen halen.

Maar hier hebben we dus een cache van 2/3 van 1 TB. En dan op dezelfde schijf dus van beoogde snelheidswinst kan geen sprake zijn. Voorkomen van eventuele ruis ook niet, zelfde reden. Bovendien kan ik me sowieso niet voorstellen dat dat enig hoorbaar verschil op gaat leveren.
Die idioot grote 'cache', 2x zo groot als de gebruiker er in totaal aan data kwijt kan doet mij vermoeden dat de oorspronkelijke data geupsampled worden en er wellicht andere bewerkingen erop los gelaten worden. Geen cache als dat waar is, maar een bewerkte copy. Geluidskarakteristiek wat aanpassen en er is altijd wel die iemand die bereid is er grof voor te betalen omdat die een verbetering denkt te horen.

Maar goed, dat is alleen wat ik kan bedenken, het kan heel anders zitten.

Cache bij storage is inderdaad daar om input/output te versnellen, dat dit invloed zou hebben op geluid is zoals al aangeven dan volgens mij inderdaad door te zorgen dat het snel genoeg naar de streamer/transporter gaat, maar die hebben vaak zelf ook een buffer en tevens het gaat over muziek bestanden, die zijn qua omvang echt peanuts tov bv een HDR bestand.

Wat het andere punt betreft dan spreken we al niet meer over een SSD, want dan wordt de data reeds bewerkt, dat je door dit op de SSD te doen daaruit winst kan halen omdat dit dan native is en dit op zelfde plek gebeurt zie ik nog wel iets, maar dan noemen we het toch geen SSD meer

[Rob_Dingen]

Lineare voeding:
https://www.audiosciencereview.com/forum/index.php?threads/do-you-need-linear-power-supply-for-dacs.7021/
Als je via luidsprekers luistert in een "stille" kamer dan is er al 20 a 30 dB geluid aanwezig. Dus welke ruis hoor je dan nog?
https://nl.wikipedia.org/wiki/Geluidsniveau

Zo te lezen in de meeste opmerkingen die je hier en daar plaatst hoor jij helemaal niks

[katwax]

Ik denk ook dat het grootste voordeel hier de externe voedingen voor elk deel wat je toepast z'n meerwaarde heeft en niet zozeer het datatransport ansich.
Ik geloof best dat er 'verschillen' zijn maar niet in het datatransport zelf.
Zoals ik al aangaf 'kunnen' de losse voedingen een voordeel bieden doordat er minder ruis 'meelift' wat ook wel te verklaren is.
Ik neem je aanbod zeker een keer aan Rob, wanneer alles weer een beetje 'normaal' is. Ik ben zelf ook wel benieuwd in hoeverre de techniek is 'verbeterd' tov van mijn Touch/Lipo combi die ik destijds tegen meerdere zeer dure streamers heb getest.

Ipv dan overal een voeding te voorzien, is het dan niet beter om bij je DAC te zorgen dat al die ruis er niet doorkomt? Het digitale deel scheiden van de ruis, welke analoog is, kan toch niet al te moeilijk zijn.
Dan kom je bij bitperfect voor digitaal, dit geeft je 100% zekerheid dat wat je krijgt is wat er is opgeslagen, de ruis niet doorlaten is niet mijn domein, maar kan me voorstellen dat daar ook oplossingen zijn.

[Rob_Dingen]

Cache bij storage is inderdaad daar om input/output te versnellen, dat dit invloed zou hebben op geluid is zoals al aangeven dan volgens mij inderdaad door te zorgen dat het snel genoeg naar de streamer/transporter gaat, maar die hebben vaak zelf ook een buffer en tevens het gaat over muziek bestanden, die zijn qua omvang echt peanuts tov bv een HDR bestand.

Zoals de meeste hier op het forum is onze kennis zeer beperkt en speelt er meer als wat wij weten en als waarheid verkondigen.

Wij hebben getest in verschillende snelheden om de data naar de DAC te sturen.
Als je het langzamer doet resulteert dat in een warmere klank ga je dat met hoge snelheid doen klinkt het wat dunner.
Ook de manier hoe de software de buffers gebruikt is hoorbaar, als voorbeeld in een simpel stukje code als buffer 1 vol is ga naar buffer 2 als buffer 4 vol is ga naar 1.
Dan heb je bij elke keer een ander bewerking als de 4 buffer vol is, hij heeft dat verandert (weet niet hoe) waardoor alle bewerkingen hetzelfde bijven en dat hoor je duidelijk.

Zoals ik al eerder zij zijn alle software spelers bitperfect en toch zit er verschil is dat heeft te maken met instellingen van buffers en de data snelheid waarmee het naar de dac gaat en je moet een speler hebben die vanuit ram afspeelt.

Rob

[Rob_Dingen]

Ipv dan overal een voeding te voorzien, is het dan niet beter om bij je DAC te zorgen dat al die ruis er niet doorkomt? Het digitale deel scheiden van de ruis, welke analoog is, kan toch niet al te moeilijk zijn.
Dan kom je bij bitperfect voor digitaal, dit geeft je 100% zekerheid dat wat je krijgt is wat er is opgeslagen, de ruis niet doorlaten is niet mijn domein, maar kan me voorstellen dat daar ook oplossingen zijn.

Dat is niet echt een logische manier van denken omdat we het hier over een bron hebben waar je dingen in verandert die hoorbaar zijn.
Dus als daar hoorbare verbeteringen te halen zijn is dat voor ons als DIY erg interessant en soms de moeite om het toe te passen.
En ook bitperfect met jitter is een probleem.

Rob

[mmuetst]

Zo te lezen in de meeste opmerkingen die je hier en daar plaatst hoor jij helemaal niks

Het is gewoon wat stof om te lezen en over na te denken en dan na te gaan wat je zegt. De aarde is niet plat, maar zo rond als een pannenkoek 

Ik luister trouwens niet met oren tegen de luidsprekers aan (behalve als ik een koptelefoon gebruik, maar dat doe ik alleen in de trein).

Trouwens zijn veel oude opnames, die heel goed zijn nog met tape opgenomen. De ruis in die opname is vele malen hoger (dus hoorbaar) in de zachte passages van de muziek. Het hoort er gewoon bij en doet niet af van de kwaliteit.

[katwax]

Zoals de meeste hier op het forum is onze kennis zeer beperkt en speelt er meer als wat wij weten en als waarheid verkondigen.

Wij hebben getest in verschillende snelheden om de data naar de DAC te sturen.
Als je het langzamer doet resulteert dat in een warmere klank ga je dat met hoge snelheid doen klinkt het wat dunner.
Ook de manier hoe de software de buffers gebruikt is hoorbaar, als voorbeeld in een simpel stukje code als buffer 1 vol is ga naar buffer 2 als buffer 4 vol is ga naar 1.
Dan heb je bij elke keer een ander bewerking als de 4 buffer vol is, hij heeft dat verandert (weet niet hoe) waardoor alle bewerkingen hetzelfde bijven en dat hoor je duidelijk.

Zoals ik al eerder zij zijn alle software spelers bitperfect en toch zit er verschil is dat heeft te maken met instellingen van buffers en de data snelheid waarmee het naar de dac gaat en je moet een speler hebben die vanuit ram afspeelt.

Rob

Als je een buffer gebruikt heeft de snelheid toch geen invloed zolang er data in de buffer zit, want het lezen gebeurt uit de buffer.
Je buffer verhaal volg ik niet helemaal, waarom 4 buffers gebruiken ipv 1 buffer grotere te maken? Maar als je 4 buffers gebruikt dan wijzig je toch niets in je code alleen je buffer is een varialble die je meegeeft.

[katwax]

Dat is niet echt een logische manier van denken omdat we het hier over een bron hebben waar je dingen in verandert die hoorbaar zijn.
Dus als daar hoorbare verbeteringen te halen zijn is dat voor ons als DIY erg interessant en soms de moeite om het toe te passen.
En ook bitperfect met jitter is een probleem.

Rob

Je wijzigt toch niets in de bron, zeker niet als het bitperfect is.

[Kingpin]

Als je een buffer gebruikt heeft de snelheid toch geen invloed zolang er data in de buffer zit, want het lezen gebeurt uit de buffer.
Je buffer verhaal volg ik niet helemaal, waarom 4 buffers gebruiken ipv 1 buffer grotere te maken? Maar als je 4 buffers gebruikt dan wijzig je toch niets in je code alleen je buffer is een varialble die je meegeeft.

Same here, ik volg het buffer verhaal ook niet.
Kan het ook niet rijmen hoe dit verschillen zouden moeten geven.
Heb laatst zelf nog een ADC gemaakt waarbij hoekbepalingen in milligraden digitaal moeten worden omgezet (andere tak, maar komt op hetzelfde neer).
Zodra het digitaal omgezet is kan ik er alles mee doen, zelfs tot op 16 bits niveau blijft alles gelijk.
Wel is het zo, in mijn geval ook meetbaar, dat de reference spanning die de hoeken bepalen qua nauwkeurigheid afhankelijk zijn van de aangesloten spanning, zeker als je in millivolts de hoeken gaat aansturen.
Dat alles heeft meer betrekking op de ADC en DAC.
Maar op datatransport zelf kon ik geen verschillen ontdekken.
Buffers worden alleen bepaalt door de maximale snelheid die 'het systeem' aankunnen.
Oftwel in mijn geval de minimale snelheid die de mechanische hoek nodig heeft.
Zodra je hier niet overheen komt kan je in en uitgang met elkaar vergelijken op onnauwkeurigheden.
Dit alles kan je met een simpele logic analyzer wel volgen.
De meeste dacs gebruiken 1 buffer, zodra deze is geladen met het aantal bits kan je vlaggetje omzetten om het register te laden, dat is een sequentieel process.

[jazzy]

Dat is niet echt een logische manier van denken omdat we het hier over een bron hebben waar je dingen in verandert die hoorbaar zijn.
Dus als daar hoorbare verbeteringen te halen zijn is dat voor ons als DIY erg interessant en soms de moeite om het toe te passen.
En ook bitperfect met jitter is een probleem.

We hebben het nog steeds over deze nieuwe SSD toch? Want dan is dat is een denkfout. Je verandert hier niets in de bron, er zit geen verschil in de data die naar de DAC gevoerd wordt. Het is bit voor bit dezelfde informatie, identiek en er kan ook geen sprake van jitter zijn voordat het bij de DAC komt. In data-transport is geen sprake van jitter, de volgorde van de de bytes verandert niet tijdens transport.

[mmuetst]

We hebben het nog steeds over deze nieuwe SSD toch? Want dan is dat is een denkfout. Je verandert hier niets in de bron, er zit geen verschil in de data die naar de DAC gevoerd wordt. Het is bit voor bit dezelfde informatie, identiek en er kan ook geen sprake van jitter zijn voordat het bij de DAC komt. In data-transport is geen sprake van jitter, de volgorde van de de bytes verandert niet tijdens transport.

Klopt @Jazzy, maar het maakt niet uit hoeveel we proberen mensen dit aan hun verstand te brengen, men hoort verschil. Ik ben benieuwd wat het volgende probleem is wat fabrikanten moeten oplossen voor de onrust van Audiofielen.

Zelf heb ik wel een mooi idee, maar weet niet of het uitvoerbaar is: dynamische akoestische panelen. Misschien bestaat het al?

[chansig]

We hebben het nog steeds over deze nieuwe SSD toch? Want dan is dat is een denkfout. Je verandert hier niets in de bron, er zit geen verschil in de data die naar de DAC gevoerd wordt. Het is bit voor bit dezelfde informatie, identiek en er kan ook geen sprake van jitter zijn voordat het bij de DAC komt. In data-transport is geen sprake van jitter, de volgorde van de de bytes verandert niet tijdens transport.

Ik begrepen dat nog niet alles is te meten en men moet zeker niet denken dat men alles al weet.

Gr. Hans

[RalphH]

Zelf heb ik wel een mooi idee, maar weet niet of het uitvoerbaar is: dynamische akoestische panelen. Misschien bestaat het al?

Op gebied van laag wel, antigeluid/subs om roommodes te cancelen. Prijzig en weet ff niet meer hoe die dingen ook alweer heten.

[jahtari]

Op gebied van laag wel, antigeluid/subs om roommodes te cancelen. Prijzig en weet ff niet meer hoe die dingen ook alweer heten.

https://www.soundonsound.com/reviews/psi-audio-avaa-c20

[minplus]

Ik begrepen dat nog niet alles is te meten en men moet zeker niet denken dat men alles al weet.

Gr. Hans

Kijk kijk, zijn we het zomaar opeens weer helemaal 100% eens, ook al vond je dat elders totaal niet...

[chansig]

Jij leest iets wat ik 2 keer niet geschreven heb. Da's best knap.

Gr. Hans

[RalphH]

De wens is de vader van de gedachte, toch?

[Kjelt]

Als je real time streamt via usb van pc naar dac ja dan spelen veel zaken, vraag me serieus af waarom je dat wikt.
Als je dac ethernet heeft met fatsoenlijke galvanische scheiding een eigen buffer en zeer goede klok a la Tentlabs dan ben je van een hele hoop van die zaken af.

[mmuetst]

Als je real time streamt via usb van pc naar dac ja dan spelen veel zaken, vraag me serieus af waarom je dat wikt.
Als je dac ethernet heeft met fatsoenlijke galvanische scheiding een eigen buffer en zeer goede klok a la Tentlabs dan ben je van een hele hoop van die zaken af.

Wat moet een DAC met een ethernet aansluiting? Of bedoel je streamer met ingebouwde DAC?

[Kjelt]

Maakt me niet uit hoe je het noemt.
Het gaat om de dac, de interface die mag nooit de oorzaak zijn van jitter, of ruis of andere verstoring door een aangesloten kabel of wat dan ook.
Anders is het per definitie een slecht ontwerp en dat ga je nooit meer goed krijgen, ook niet met software.

De reden is bedieningsvriendelijkheid vs geluidskwaliteit. Als je de eerste overboord gooit met alle fancy wireless en grafische GUI bagger kun je heel ver komen, maar het is niet gebruiksvriendelijk. Maar dat is een platenspeler ook niet en daar hoor je de high end liefhebbers ook niet klagen dat ze niet even snel een willekeurig nummer op kunnen zetten.

Mijn theoretisch perfect klinkende DAC zou een batterijgevoed apparaat zijn met twee volledig gescheiden circuits.
Een met de microcontroller waar je eerst de gewenste nummers in het (dual port ?) ram geheugen laadt via een interface zoals ethernet, net zoals dat je een plaat op de speler legt of een cd in de lade.
Daarna schakelt dit hele microcontroller circuit zich zelf uit en gaat een tweede circuit waarbij alleen een zuivere klok het ram geheugen uitklokt naar een seperaat gevoede DAC en analoog deel voor de weergave.

Het grootste ontwerp probleem hier is de dac aangezien deze de twee domeinen in 1 chip verbindt.

[Rob_Dingen]

Als je een buffer gebruikt heeft de snelheid toch geen invloed zolang er data in de buffer zit, want het lezen gebeurt uit de buffer.
Je buffer verhaal volg ik niet helemaal, waarom 4 buffers gebruiken ipv 1 buffer grotere te maken? Maar als je 4 buffers gebruikt dan wijzig je toch niets in je code alleen je buffer is een varialble die je meegeeft.

Ik heb het nog steeds over de software en waarom er 4 of meer buffers inzitten weet ik niet.
Wat ik wel weet is dat er 3 keer hetzelfde gebeurd en de 4e keer anders.
Dat heeft hij opgelost en kun je met een vinkje in de software uit of aan zetten en duidelijk hoorbaar

Je wijzigt toch niets in de bron, zeker niet als het bitperfect is.

Dat is dus niet zo probeer ik al een tijdje hier uit te leggen, de klank is beïnvloedbaar door timing en buffers te veranderen.
Ook belangrijk is een zo laag mogelijke cpu load en vanuit RAM af te spelen.

Same here, ik volg het buffer verhaal ook niet.
Kan het ook niet rijmen hoe dit verschillen zouden moeten geven.
Heb laatst zelf nog een ADC gemaakt waarbij hoekbepalingen in milligraden digitaal moeten worden omgezet (andere tak, maar komt op hetzelfde neer).
Zodra het digitaal omgezet is kan ik er alles mee doen, zelfs tot op 16 bits niveau blijft alles gelijk.
Wel is het zo, in mijn geval ook meetbaar, dat de reference spanning die de hoeken bepalen qua nauwkeurigheid afhankelijk zijn van de aangesloten spanning, zeker als je in millivolts de hoeken gaat aansturen.
Dat alles heeft meer betrekking op de ADC en DAC.
Maar op datatransport zelf kon ik geen verschillen ontdekken.
Buffers worden alleen bepaalt door de maximale snelheid die 'het systeem' aankunnen.
Oftwel in mijn geval de minimale snelheid die de mechanische hoek nodig heeft.
Zodra je hier niet overheen komt kan je in en uitgang met elkaar vergelijken op onnauwkeurigheden.
Dit alles kan je met een simpele logic analyzer wel volgen.
De meeste dacs gebruiken 1 buffer, zodra deze is geladen met het aantal bits kan je vlaggetje omzetten om het register te laden, dat is een sequentieel process.

Het gaat niet om de DAC maar om de software.
Hoe het verder met de buffers zit met wat ik tot nu toe verteld heb weet ik niet en heb er verder geen verstand van, vertel alleen mijn bevindingen.

Rob