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.
|
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 !!!
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 !!!
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
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
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
Å 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
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.
R
Roysen
Gjest
Ved asynkron USB er det klokken i DAC som styrer overføringen fra streamer.
asynchronous USB definition
Mvh
Roysen
asynchronous USB definition
Mvh
Roysen
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):
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
Fra kap 5.12.4.2 som beskriver feedback mekanismen i asynkron USB (som jo er hovedpoenget med async USB)
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.
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):
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
Fra kap 5.12.4.2 som beskriver feedback mekanismen i asynkron USB (som jo er hovedpoenget med async USB)
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:
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
Mvh
Roysen
Sist redigert:
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.
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.
Dette bruker også USB til DAC.
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.