Oppskrift for god hjemmelaget musikk server

N

nb

Gjest
Så det Roysen essensielt sier er at det låter ulikt om bufferet er 67% eller 100% fullt. Og at lyden avhenger av at bufferet blir fyllt opp i en jevn og fin hastighet.
 

marsboer

Hi-Fi freak
Ble medlem
04.04.2010
Innlegg
4.356
Antall liker
1.701
Sted
Phobos
Nei, kun dersom bufferet i siste ledd før selve signalet til DACen klokkes ut tømmes, og da får vi i såfall ikke lyd i det hele tatt. Hensikten med RAM-buffere er nettopp å sørge for at variasjoner i signalet inn kan sendes ut i en jevn kontinuerlig klokket strøm så lenge bufferet har data. Om 2 sekunder eller hele låten er bufret er ikke viktig. Applikasjonen sakker ikke ned utklokkingen i variasjon med innsignalet i bufferet.
Dette gjelder kun dersom det er klokken i DAC som styrer overføring fra streamer. USB f.eks. tillater ikke det dersom overføringen ikke er asynkron.

Mvh
Roysen
Nei. det gjelder alltid. Det er PCen som klokker ut dataene på nytt uansett. Har man imidlertid async USB så vil denne klokken korrigeres regelmessig av DACens klokke. Man gjenbruker ikke i noe tilfelle klokke fra nettverkssignalet. Signalet klokkes alltid på nytt basert på spesifikasjonene i header på lyddataene og innstillinger i applikasjon og lydkort.
 
X

X186841

Gjest
Roysen prater essensielt tull i kveld , blander hifisvada og nettverk/usb fakta til en stinkende lapskaus av påståelige sannheter bedre enn noen Jehovas vitne.

Det er vel slik "hifisannheter" oppstår , gjenta det mange nok ganger og noen vil alltids tro på det.

Mener ikke att Roysen gjør dette i ond hensikt !!!
 

Class

Hi-Fi freak
Ble medlem
11.03.2009
Innlegg
2.763
Antall liker
496
Sted
Vestfold
Torget vurderinger
7
Av ren nysjerrighet: Finnes i det hele produkter som kan karakteriseres som "audiofile filservere", eller er det konseptet for idiotisk selv for HiFi-bransjen?
Det kommer nok.
Produsenten kan vise til tåkeprat lignende det som er i deler av denne tråden, gi det et aller annet snasent navn, f.eks. IP-Audio™, CAT5eJitBuzt™ eller LoLatNet™ og ta veldig godt betalt for det. Godtroende biter på og handler.

Det kan kanskje værra godt nok til å styre atomkraftverk men kom ikke her å fortell meg at det duger til Diana Krall!
 
R

Roysen

Gjest
Roysen prater essensielt tull i kveld , blander hifisvada og nettverk/usb fakta til en stinkende lapskaus av påståelige sannheter bedre enn noen Jehovas vitne.

Det er vel slik "hifisannheter" oppstår , gjenta det mange nok ganger og noen vil alltids tro på det.

Mener ikke att Roysen gjør dette i ond hensikt !!!
Kan du vennligst holde deg til sak eller la være å skrive dersom du ikke klarer å la personangrep ligge! Mener du at du får mer rett ved å gå til angrep på person i stedet fot å argumentere saklig for din syn? Det jeg har skrevet er ikke bare slik jeg ser det, og designere av hardware har laget utstyr som tar hensyn til dette og som låter bedre enn en vanlig PC. Så teorien fungerer også i prsksis. Jeg snakker da om custom OS basert på F.eks. Linux hvor alle unødvendige prosesser er skreller vekk og latency er så godt som eliminert.

Mvh
Roysen
 
Sist redigert:
R

Roysen

Gjest
Nei, kun dersom bufferet i siste ledd før selve signalet til DACen klokkes ut tømmes, og da får vi i såfall ikke lyd i det hele tatt. Hensikten med RAM-buffere er nettopp å sørge for at variasjoner i signalet inn kan sendes ut i en jevn kontinuerlig klokket strøm så lenge bufferet har data. Om 2 sekunder eller hele låten er bufret er ikke viktig. Applikasjonen sakker ikke ned utklokkingen i variasjon med innsignalet i bufferet.
Dette gjelder kun dersom det er klokken i DAC som styrer overføring fra streamer. USB f.eks. tillater ikke det dersom overføringen ikke er asynkron.

Mvh
Roysen
Nei. det gjelder alltid. Det er PCen som klokker ut dataene på nytt uansett. Har man imidlertid async USB så vil denne klokken korrigeres regelmessig av DACens klokke. Man gjenbruker ikke i noe tilfelle klokke fra nettverkssignalet. Signalet klokkes alltid på nytt basert på spesifikasjonene i header på lyddataene og innstillinger i applikasjon og lydkort.
Nå har du misforstått det jeg skrev. Tar opp tråden igjen senere. Jeg kan imidlertid si her og nå at asynkron USB overføring ble innført i audio bruk fordi reklokkingen ved synkron USB overføring førte til jitter.

Mvh
Roysen
 
Sist redigert:
R

Roysen

Gjest
Av ren nysjerrighet: Finnes i det hele produkter som kan karakteriseres som "audiofile filservere", eller er det konseptet for idiotisk selv for HiFi-bransjen?
Det kommer nok.
Produsenten kan vise til tåkeprat lignende det som er i deler av denne tråden, gi det et aller annet snasent navn, f.eks. IP-Audio™, CAT5eJitBuzt™ eller LoLatNet™ og ta veldig godt betalt for det. Godtroende biter på og handler.

Det kan kanskje værra godt nok til å styre atomkraftverk men kom ikke her å fortell meg at det duger til Diana Krall!
Å sammenligne epler og pærer gir vel ikke diskusjonen medverdi. Å sette opp stråmenn som kjernekrsftverk tilfører debatten ingenting. Mener du at utfordringene ved å drive et kjernekraftverk er tilsvarende avspilling av musikkfiler?

Mvh
Roysen
 

marsboer

Hi-Fi freak
Ble medlem
04.04.2010
Innlegg
4.356
Antall liker
1.701
Sted
Phobos
Nå har du misforstått det jeg skrev. Tar opp tråden igjen senere. Jeg kan imidlertid si her og nå at asynkron USB overføring ble innført i audio bruk fordi reklokkingen ved synkron USB overføring førte til jitter.
Det er jeg selvsagt klar over, bortsett fra at det er fullt mulig å få greie jitterverdier også med adaptive løsninger som S/PDIF og adaptiv USB. Det hele handler om implementasjonen av løsningen.

Og nei, jeg har ikke misforstått. Asynkron USB løser ikke et problem som kan være forårsaket av nettverksjitter, men snarere av at klokkegjenvinning fra en mer eller mindre nøyaktig klokke i en tilfeldig PC ikke alltid er en optimal løsning. Det kan derfor lønne seg å slave PCens klokke mot en ekstern klokke som KAN være bedre konstruert (og stort sett viser seg å være det). Uansett så er ikke nettverkstrafikken en del av denne ligningen. Dette skjer på lydkortsiden mot DAC.

Det virker også som om du mener at det er klokken i DACen som styrer utklokkingen fra PC ved asynkron USB direkte, men det gjør den faktisk ikke. Den finner bare avvik fra egen klokke (som den antar er mer nøyaktig) i mottatt signal og sender korreksjonsverdier tilbake til PCens klokke via en dedikert klokkefeedbackkanal.
 

marsboer

Hi-Fi freak
Ble medlem
04.04.2010
Innlegg
4.356
Antall liker
1.701
Sted
Phobos
Bare indirekte via korrigering av PCens klokke. Det er IKKE USB DACens klokke som klokker signalene ut fra PCen direkte, eller eventuelt reklokker dem når de ankommer DAC. Dette er er en svært vanlig misforståelse. Ved asynkron USB snur du i praksis om på adaptiv USB, ved at det er PCens klokke som tilpasses DAC-klokken. Driverne for async USB enheter kalles adaptive USB-drivere i USB 2.0 standarden.

Siden det er så mange feilopfatninger angående asynk USB, spesielt i Hi-Fi miljøet, så kan du ikke stole på de kraftig forenklede tolkningene du f.eks linker til. Les USB 2.0 standarden så vil du se at det jeg sier er rett. Denne tabellen er en fin oppsummering (5.12.4.1 i USB 2.0 standarden):

Selection_003.jpg


Source er vårt tilfelle USB-implementasjonen i PCen, mens Sink er den asynkrone USB DACen. (SOF = Start of Frame)

Fra kap 5.12.4.1.1
Asynchronous source endpoints carry their data rate information implicitly in the number of samples they produce per (micro)frame. Asynchronous sink endpoints must provide explicit feedback information to an adaptive driver (refer to Section 5.12.4.2).

Fra kap 5.12.4.2 som beskriver feedback mekanismen i asynkron USB (som jo er hovedpoenget med async USB)
5.12.4.2 Feedback
An asynchronous sink must provide explicit feedback to the host by indicating accurately what its desired
data rate (Ff) is, relative to the USB (micro)frame frequency. This allows the host to continuously adjust the
number of samples sent to the sink so that neither underflow or overflow of the data buffer occurs.
Likewise, an adaptive source must receive explicit feedback from the host so that it can accurately generate
the number of samples required by the host. Feedback endpoints can be specified as described in
Section 9.6.6 for the bmAttributes field of the endpoint descriptor.
Det er snakk om synkronisering av klokkene, omtrent som om at PCens dato/tid synkroniseres regelmessig mot en NTP-server med en mer nøyaktig klokke. Selv om klokken korrigeres mot NTP-serveren er det fremdeles klokken i PCen som benyttes av programmene dine.

Uansett asynkron eller ei, hvis vi antar adaptiv for å få frem "problemet" i størst mulig grad, er vi enige om følgende forutsetninger?

1. Inntil lyddataene er dekodet i applikasjonen så finnes det intet synkroniserings- eller klokkebehov direkte relatert til utklokkingen mot DAC. Det vil si at f.eks deler av en FLAC fil kun består av 0'er og 1'ere uten tidsmessige behov utover å settes sammen korrekt i bufferet før utklokking. Det er først ved konvertering til et digitalt lydsignal mot lydkort at den tidskritiske delen i kjeden oppstår og det er her signalet eventuelt må påvirkes av andre ledd i kjeden for å få jitter mot DAC.
2. Dette gjelder uansett hva slags medium dataene befinner seg på, enten det være seg SSD, internett eller en NAS. Alt havner i applikasjonens buffer.
3. Siden det er PCen som klokker ut lydsignalene på nytt med egen klokke så vil eventuelt klokkerelatert jitter på DAC skyldes at PCens klokke går unøyaktig.
 
Sist redigert:

Class

Hi-Fi freak
Ble medlem
11.03.2009
Innlegg
2.763
Antall liker
496
Sted
Vestfold
Torget vurderinger
7
Her ror han seg frenetisk over mot USB og svarer på det han hevdet å ikke kjenne til da jeg spurte i et annet innlegg.
 
R

Roysen

Gjest
Finnes ikke en eneste åre her. Jeg kommer som sagt tilbake til dette. Marsboer har ikke forstått hva jeg har ment. Når det gjelder problemene ved USB overføring har det vært velkjent lenge. Men så lenge du ikke klarer å sette ord på hvilken utfordering med USB du siktet til blir det svært vanskelig for meg å tipp, så der får du skylde deg selv. USB ble tatt opp av meg i denne debatten som et eksempel. Dette eksempelet var det andre tok videre for diskusjon. Ellers står jeg for alt jeg har skrevet. Det er klokken i DAC som styrer overføringen ved asynkron USB. Latency i et general purpose OS skaper forstyrrelser i D/A prosessen dersom det ikke taes forhåndsregler for å forhindre det. Det gjør ikke en vanlig PC.

Mvh
Roysen
 
Sist redigert:

Class

Hi-Fi freak
Ble medlem
11.03.2009
Innlegg
2.763
Antall liker
496
Sted
Vestfold
Torget vurderinger
7
Du snakker om et problem som ikke eksisterer, derfor forstår vi ikke hva du mener.
 

marsboer

Hi-Fi freak
Ble medlem
04.04.2010
Innlegg
4.356
Antall liker
1.701
Sted
Phobos
Det blir lite fruktbart å diskutere videre når man nekter å forholde seg til faktiske virkemåter i argumentasjonen. For min del er dette veldig lite komplisert eller sårbart og jeg anser det som en ganske så triviell greie å få et resultat minst like optimalt som enhver "audiofil" løsning til audioavspillingsformål. Den reelle utfordringen når det gjelder musikkavspillingsløsninger slik jeg erfarer det er helt andre ting enn jitter og det lydmessige, nemlig brukervennlighet, pålitelighet og fleksibilitet.
 

Piemonte

Hi-Fi entusiast
Ble medlem
14.02.2013
Innlegg
187
Antall liker
48
Har en kjenning som bruker et spesielt program der hele sangen blir lastet i RAM før den blir spilt, (tror hvertfall det virker sånn) PCen han bruker er helt standard Windows maskin mener jeg. Da unngår en hvertfall overføringsfeil fra server etc.
Dette bruker også USB til DAC.
 

marsboer

Hi-Fi freak
Ble medlem
04.04.2010
Innlegg
4.356
Antall liker
1.701
Sted
Phobos
Overføringsfeil er uansett ikke noe problem med mindre disk/nettverk er defekt. Det å ha hele låta i RAM kontra f.eks et par sekunders buffer er en meget teoretisk fordel som nok er mer for audiofiles tilfredsstillelse enn noe annet. Den eneste vagt plausible forklaringen jeg kan finne er dersom disken sitter i selve musikkavspillingsklienten og at man ved å laste hele låta i RAM ikke genererer strømbelastning eller magnetfelt i drift, forutsatt bruk av en tradisjonell harddisk. Dersom nettverket er kilden så er det ingen slike mekanismer i drift i klienten. Hva som skjer på filserversiden er da helt likegyldig for klienten så lenge dataene kommer frem. For klientens del er det da kun snakk om data som flyttes internt mellom ulike bus'er og buffere.
 
Topp Bunn