Hvem er jeg?, .... hvor er jeg? ..... hvor skal jeg? ...........??
Du ser noen av de ute i trafikken - ofte ...
Dagsformen avgjør...??
Sist redigert:
Mer å hente - nettverkskabler!
- Trådstarter Kristian
- Startdato
Diskusjonstråd Se tråd i gallerivisning
-
Du ser noen av de ute i trafikken - ofte ...
Dagsformen avgjør...??
Er det med en skjermet og jordet Ethernet-kabel (STP) eller uskjermet (UTP)? Hvis det er STP er Moon Audio herved notert på min lille «styr unna»-liste. Jeg ville ikke betalt €2200 for en boks med slike fundamentale problemer. Hvis det derimot er UTP tror jeg ikke på deg. Sorry.
Nocheinmal, her jeg sitter i Wien med en Ottakringer og venter på ein Schnitzel: Hos meg låter WiFi, STP og UTP klin likt. Ingen hørbar forskjell whatsoever. Og jeg har faktisk forsøkt.Sist redigert:
Jeg er helt sikker på at dette er noe som oppleves på de aller fleste produkt. Har du prøvd? Eller er det enklere å konstantere hvordan verden er basert på din oppfattelse av den? Forskjellige aksesspunkt gir diff i lyd. Det koster ingenting å sette opp aksesspunkt nærmere streamer - alternativt prøve med flere om man har. Koster ingenting. Finne kanaler med minimal forstyrrelse av andre sendere bidrar også positivt. Data kommer over uansett (ellers stopper avspilling) - men ekstremt gode signaler bidrar positivt, og eneste logiske forklaring er at støy (fra wifi receiver) påvirker resten av elektronikken.
Jeg får 1170 Mbit/s (TX Speed) med nåværende aksesspunkt (ac).
Edit:
Ny måling ga faktisk 1380 Mbit/sSist redigert:
Testene med ethernet-kabel ble gjort med UTP; tenkte å teste ut med STP etterhvert. Testet også flere forskjellige UTP-kabler, merker ingen forskjell mellom dem. WiFi var alltid bedre, alternativt prøve å bytte ut switch med en annen (kan være den som er synderen).
Hos meg er det kjempeforskjell, Wi-Fi faller ut og mister forbindelse med streamer mens kabel er 100% stabilt. Kan ha noe å gjøre med 120år gamle 80cm tykke murvegger?? Og 8meter lange jernbaneskinner i gulvet....
OK, takk. Hvis jeg likevel skal forsøke å tro på dette, ser jeg følgende spesifikasjoner:
https://simaudio.com/en/product/mind2-network-player/
Give us convenience or give us death, som Dead Kennedys vrælte for lenge siden. F...n vet hvordan alt det er implementert og hvordan de forskjellige kodesnuttene påvirker hverandre. Styr unna, ihvertfall til €2200 for en glorifisert Chomecast.
MiND2 er faktisk en veldig bra streamer (bedre enn det aller meste som er dyrere). Lyden som kommer ut av denne etter å ha vært gjennom DAC er veldig bra. Det er ikke noe galt ved å bruke ethernet kabel, men normalen er motsatt - wifi suger og ethernet er foretrukket valg. Jeg prøver å finne ut hvorfor wifi høres bedre ut enn ethernet kabel (wifi er vanligvis på nivå med å ha på en mikrobølgeovn inne i streamer'n (det er MASSE støy fra disse brikkene vanligvis)).
Har sparket over et spørsmål til produsent i håp om å fiske frem en årsak.
Forrige modell (pre MiND2) ble det anbefalt å kun bruke wifi i nødstilfeller, og holde seg til ethernet kabel der det var mulig.
Med WiFi er det ingen koblingsproblem eller dropp i lyd - så dette er mer av ren nysgjerrighet - jeg kommer naturligvis til å fortsette med wifi på denne streameren (vi snakker ikke natt/dag forskjell, men det er helt klart forskjell).
NB! jeg bruker kun streameren som Roon endpoint - har også prøvd å streame fra lokalt nettverk/Tidal/Qobuz fra streameren direkte. Samme trend her (så implementering av støtte for de forskjellige streaming-tjenestene har ingen betydning).
Edit:
Internt ser MiND2 streameren veldig ryddig og pen ut; modulbasert; med en relativt heftig linear strømforsyning.Sist redigert:XX186841
Gjest
Har prøvd det meste, drevet med nettverk og kommunikasjon siden de tidlige modemene ble mer eller mindre piratimportert. Startet med BBS blant de første i Norge (Odd De Presno og Jon Orten var vel først ute med Saltrød Horror Show og Thunderball Cave) og ble kontaktet av TBK for å teste ut modem de skulle lansere som var lovlig å koble på telenettet i Norge og har alltid holdt meg nogenlunde oppdatert med utstyr, så helt grønn er jeg ikke. Har aldri opplevd forskjell på lydkvalitet i nettverksutstyr som er vettug konstruert såsant pakkene kommer frem. Finnes sikkert noen "High end" streamere som er konstruert helt bak mål.
De hastighetene du får er laaangt over det som trengs og det påvirker ikke lyden en dritt hvilken speed du får sålenge det ikke begynner å hakke i lyden, må nok en annen type "speed" til for å få forskjeller på opplevd lyd
Jeg har da aldri påpekt at det er problem med overføring av data; men NOE påvirker lyden etter den er mottatt vs bruk av ethernet vs wifi. Data er garantert helt korrekt; så vi snakker ikke om denne type forskjeller. Hadde dette vært på nivå med "brudd" i lyd hadde vi ikke hatt denne diskusjonen engang. Jeg har også jobbet med IT og software i flere 10år. Jeg vet godt hvordan data overføres over TCP/IP. Jeg kjenner også til hvordan nettverkskort fungerer; samt wifi.
La oss bare legge den delen av diskusjonen død med en gang; data som kommer til streameren er bit-perfect og helt 100% identisk med kilden når de havner i minnet til streameren.XX186841
Gjest
Så det du prater om er bare streamere og ikke nettverk som tråden handlet om. Hvis data garantert er helt korrekt spiller det jo ikke noen rolle for de om de kom i ledning eller i luft.
Sorry, men en komponent til €2200 som ikke greier å gjøre det en Chromecast Audio eller Apple Airport Express gjør for noen hundrelapper er ikke en «veldig bra streamer».
Nei, hvorfor i all verden er det diff mellom wifi og ethernet når data som kommer over er identiske. It's a mystery. Prøvde også med et bredt utvalg UTP kabler; ikke en pøkk forskjell mellom disse. Fortsatt høres wifi bedre ut (som er ulogisk).
Jeg kan garantere deg at lyden fra MiND2 er MYE bedre enn Chromcast og Airport express; uansett oppkobling. Men naturligvis, om man i utgangspunktet mener at alle streamere er identiske; så er det ikke noe poeng å diskutere dette med deg
Nei, jeg mener ikke at alle streamere er identiske, men det skal faktisk ikke så mye til å gjøre dette riktig. Jeg har veldig lite sympati for dyre «audiofile» produkter som (ifølge dine egne observasjoner) degraderer lyden på en øvelse som en Airport Express ikke har noen problemer med å løse.
Jeg har både Chromecast Audio og Airport Express i forskjellige anlegg, og en Logitech Transporter i hovedriggen. Min erfaring er at digitalutgangene på en Chromecast er helt OK, forutsatt at den kombineres med en DAC som tåler litt jitter, og at både digitalutgangene og DAC’en i en Airport Express er helt OK. Det lar seg også lett dokumentere med måleresultater. Hvis du hevder at dyrere komponenter låter hørbart bedre er det du som har bevisbyrden. Og når du forteller at en dyrere komponent degraderer lyden i hørbar grad hvis den plugges inn via Ethernet snakker vi om noe som kanskje burde skrotes.
https://www.audiosciencereview.com/...ents-of-chromecast-audio-digital-output.4544/
http://archimago.blogspot.com/2016/02/measurements-google-chromecast-audio.html
http://archimago.blogspot.com/2016/02/measurements-google-chromecast-audio_27.html
https://kenrockwell.com/apple/airport-express-audio-quality-2014.htm#meas
https://audiophilestyle.com/ca/revi...-and-Second-Generation-Apple-AirPort-Express/Sist redigert:
- Ble medlem
- 02.03.2005
- Innlegg
- 1.312
- Antall liker
- 1.448
- Sted
- Foten av Jotunheimen
- Torget vurderinger
- 1
Moon Mind2 er mye bedre enn Chromcast og Airport express til sammen. Jeg har testet disse opp mot mind2. Chromcast og Airport express gikk i eeafall forige uke. Guttungen ville ikke ha disse engang når han hørte forskjellen. 8) Men klart vis enkelte synest det er ok lyd i disse, må dem som bruker disse glede seg over lyden og ikke bare sitte å rakke ned på produkter, fordi dem ikke hører forskjell og mase hele tiden at det er alt for dyrt.
Jeg kan garantere deg at lyden fra MiND2 er MYE bedre enn Chromcast og Airport express; uansett oppkobling. Men naturligvis, om man i utgangspunktet mener at alle streamere er identiske; så er det ikke noe poeng å diskutere dette med deg
PS Tesla,en er også alt for dyr
Jaja, min erfaring med Chromecast er bl.a. sammen med DAC’en i en Naim Uniti. Den lille pucken låt (så vidt jeg kunne høre) klin likt med den innebygde UPnP-streameren i Uniti. Min guttunge var godt fornøyd med den. Ingen hørbar degradering, men jeg ser fra måledata at Chromecast har såpass mye jitter at enkelte DAC’er vil slite med den. Et eksempel vil være Schiit Audio’s DAC. Den bærer sitt navn med rette, spør du meg. Har ikke testet Chromecast sammen med DEQX’en. Den er heller ikke immun mot jitter, men såpass tror jeg den tåler. Med f eks en Benchmark DAC burde ikke jitteret fra Chromecast være noe problem i det hele tatt.Sist redigert:
OK, da har jeg lært noe helt nytt i dag etter input fra Roon. Managed switch har ofte innstilling for "flow control"; denne bør være på siden den kunne påvirke streamere. Magisk nok høres aksesspunkt og ethernet relativt identisk ut plutselig. Flow control er normalt påslått for unmanaged switcher.
For dem som mener at ikke noe som helst kan påvirke lyden ved strømming over Ethernet, vil nok ikke dette bidraget hjelpe særlig.Ccruiser
Gjest
Hvorfor skulle det ha noe å si, det er jo ikke akkurat store mengder data som overføres her.
Beklager, lover å ikke kaste inn flere brannfakler i dag.... beklager eventuelle lidelser jeg måtte ha påført noen ved denne uttalelsen >
Fikk også tilbakemelding fra SimAudio her tidligere, de hadde ikke klart å gjenskape differansen mellom wifi og ethernet hos seg, men pekte i retning støy over ethernet (switch) som en potensiell årsak. De hadde på nåværende produktlinje (MiND2) ingen intern favoritt mellom wifi/ethernet - så begge skulle være identiske.
Ref Roon, så vil de aldri gå ut med at det finnes noen differanser uansett - jeg fikk bare spørsmål om jeg hadde managed switch; om det var tilfelle - sørg for at flow control var slått på for portene med Roon Core og streamer. Med en antydning at dette kunne ha påvirkning på enkelte streamere. Også en god plan om man opplevde små periodevis avbrudd i avspillingen (som en del sliter med; ikke merket noe til det selv).Sist redigert:https://en.wikipedia.org/wiki/Ethernet_flow_control
Congestion... Streameren har for dårlig buffer, så det kommer stop-frames når flow control er aktivert.
Har aldri fått noe avbrudd i lyd; hvorfor dette påvirker har jeg ingen idé om. Men noe avbrudd på lyd hører jeg ikke - trekker jeg ut nettverkskabelen (fra streamer) så spiller den i 5-10 sekunder uten nett.
https://kb.roonlabs.com/Networking_Best_Practices
Edit:
Buffer ser ut til å være uavhengig av innkommende PCM; 16bit 44.1kHz har like langt buffer (i tid) som 24bit 192kHz. Merket også at buffer er økt i lengde etter siste MiND2 firmware oppgradering. Så boksen har nok nok av minne, hvor mye den bufrer er nok satt opp i firmware.Sist redigert:Det er en buffer på nettverkslaget, jeg ser bort ifra PCM når det gjelder nettverk for PCM er et hakk videre etter nettverket. Congestion er at det er for mye trafikk inn på streameren så streameren ikke klarer å sluke unna alt ettersom jeg mistenker den har for lite buffer eller at denne har for dårlig hastighet. Dette bør man oppdage på en switch som er managed, men stort sett så er nok de "audiofile" switchen elendige der så det er lite info (tilsvarende rimelige switcher for en tusenlapp eller to fra komplett).
Du tenker på nettverkskortet i streamer; ikke buffer i selve streamer ?
Det stemmer, men også på dataplanet med buffer der datatrafikken fra nettverket blir behandlet videre til PCM. Et sted imellom der så er det ihvertfall en flaskehals kan det virke som, derav Congestion. Om det er buffer eller hastigheten på denne kjenner jeg ikke til. Om noen har denne streameren og en Cisco Catalyst liggende så kunne det vært interessant å sett på hva portene der sier sånn egentlig.
Om noen kjenner til DDoS angrep, så lager den massiv congestion så nettverket har nok med å sende data i retur. Forskjellen er at DDoS rammer hele nettverket. Om man sitter med et bedre nettverk enn en klient klarer å håndtere så kan man også få lignende symptomer (imellom switch og klient) der for mye trafikk kommer inn enn streamer klarer å behandle og sende i retur. Congestion har vi vært igjennom allerede i tråden her for ganske mange sider tilbake. Var mer vanlig før med hubber, med switcher så har man collision domain pr. port og ikke pr. boks. For min del så virker det som litt dårlig integrert nettverk på streameren om dette oppstår og er merkbart.
Med flow control så velger man å buffre på nettverksporten, noe som setter ned ytelsen på nettverket. På nettverksportene har man minimalt med buffer og om man har stort buffer på portene her så snakker man om switch til flere hundre tusen kroner bygd for datacenter og gjerne veldig mange 10, 40 eller 100 Gbit porter (disse switchene bråker ca. like mye som en Ferrari på tomgangen) og har gjerne en meter dybde+. Det er mye rimeligere å sette et buffer på klientenporten (dette tilfellet streamer) for å håndtere data. Cisco best practice er å ha flow control av.
https://blogs.cisco.com/perspectives/to-flow-or-not-to-flow
Et ekstremeksempel på hvor lite jitter betyr i et bufret grensesnitt: Event Horizon Telescope har nettopp tatt et nærbilde av et svart hull i galaksen M87, 53,5 millioner lysår borte. Teleskopet er basert på interferometri, dvs at det registrerer og analyserer løpetidsforskjellene mellom radiobølger som mottas i forskjellige basestasjoner rundt om på Jorden. Der stemples de mottatte signalene med klokkesignalet fra et atomur før data lagres på harddisker. Deretter sendes harddiskene med fly til MIT og Max Planck Institute hvor data fra de forskjellige basestasjonene settes sammen.
https://en.m.wikipedia.org/wiki/Event_Horizon_Telescope
Men vil ikke økningen i jitter ved en flyforsinkelse skape «smearing i tidsdomenet» og whatnot, og ødelegge hele greia når alt avhenger av disse knøttsmå løpetidsforskjellene?
Nei, den vil ikke det. Det har ingen ting å si. Grensesnittet er bufret og tidsstempelet ligger i filen, akkurat som i en musikkfil. Det har heller ikke noe å si om det er en Boeing eller Airbus, eller om det er et passasjerfly eller godsfly. Så lenge harddiskene kommer frem like hele med filene i god behold er alt OK. Om nødvendig får man bare vente til alle filene er fremme før man setter i gang kverna, og om en harddisk skulle forsvinne på veien får man ettersende en backup-kopi.
Never underestimate the bandwidth of a station wagon filled with magtapes, pleide det å hete.Sist redigert:
Jo.. så lenge det ikke er en MAX.. Men da blir det pakketap og retransmisjon som du nevner.
Tror noen prøvde seg på en Pigeon IP for noen år siden, dvs. datapakker over brevduer. Høy latency og relativt høyt pakketap... https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
Funker med snegler også:
rsm home
Men det kan bli litt lenge å vente fra man trykker "Play" til det kommer lyd hvis man bruker den teknologien.Sist redigert:
Så nå er det rimelig klart at så lenge ting kommer fra til streameren, uansette måte og kvalitet så er alt OK, så lenge streameren "kjenner igjen" data pakkene.
Men hvordan pakker streameren om fra TCP/IP eller hva det heter til strømmende bits tll DAC via SPDIF? Kvaliteten på streameren kan vel degradere det Dacen får eller betyr det ikke noe? Hvor og hvordan skjer konverteringe fra WAV/FLAC til TCPIP pakker?
Hos meg går det fra Snurrehardisk til Router- kablet nettverk Cat 5e til en boks som er Renderer/DAC/preamp alt i ett. Styring og musikkvalg er via JRiver på PC( alt Jremote på nettbrett etterhvert) som trådløst snakker med Renderer-DAC-Pre boksen. JRiver sier den er bit-perfekt, må man gjøre noen innstillinger for å virkeliggjøre det..?.
PS har også en bakvei for musikken via Tidal til Sonos bridge og mottaker som gir digitalt inn til DAC/preamp boksen.. samt en CD spiller selvsagt...og vinyl...
Hvor ligger svakhetene mht NAS/ nettverksavspilling og hva må man passe på nå som kabler ikke betyr noe?
Beklager om jeg avsporer tråden....Sist redigert:
Media server kan sende datapakker over TCP/IP enten som FLAC eller WAV. I Logitech Media Server er det en avkryssing. (Har prøvd, hørte ingen forskjell.) Hvis det er FLAC er det streameren/renderer som pakker dem ut til WAV. Den reformatterer også data som PCM og klokker dem ut videre på S/PDIF (eller AES/EBU) til DAC, som ikke er vist på bildet over.
Dette er eksakt hva en streamer/renderer gjør: Den mottar asynkrone datapakker over Ethernet eller WiFi, bufrer, konverterer til PCM, og klokker ut som en synkron datastrøm på S/PDIF til DAC. Det er det hele.
Det som først og fremst betyr noe er presisjonen i klokkekrystallen som mater S/PDIF PCM ut av renderer til DAC. Tidsvariasjoner der blir til analog forvrengning i DAC hvis det er mer enn hva DAC'en kan korrigere. Der ligger nok årsaken til eventuelle hørbare forskjeller mellom streamere, i tillegg til eventuell jordstøy som slipper gjennom fra datadingser til audiodingser. Eksempelvis har en Chromecast såpass mye jitter på de digitale utgangene at enkelte DAC'er kan få problemer, mens andre DAC'er svelger det unna uten hørbar degradering. Det kan være en bra test på DAC-kvalitet (og da er det ikke å "avsløre" jitteret som er et kvalitetstegn, tvert i mot).Sist redigert:
Ingen streamere jeg har hørt på har hatt lik lyd; og data er identisk. Så det hele må gå på klokke eller forstyrrelser (internt og/eller mellom komponenter). Data tror jeg vi alle er enige om er identiske med mindre noe er veldig galt, og da hører man det tydelig med avbrudd/stopp i avspilling.Sist redigert:
- Ble medlem
- 02.03.2005
- Innlegg
- 1.312
- Antall liker
- 1.448
- Sted
- Foten av Jotunheimen
- Torget vurderinger
- 1
Klokken er alfa omega! Denne er inne til testing av en HiFi kolega, første tilbakemelding, Enkelt og greitt, Bedre lyd
Det jeg er nysgjerrig på er hvordan de ulike streamerene håndterer klokke og distro, men diskusjonene om digitalkabler kommer liksom aldri dit. Det finnes essensielt to metoder som kan benyttes:
1) DAC klokken genererert lokalt og nettverkslaget er request/poll basert og henter mer data når vannmerket i bufferet er lavt nok. Alle internetbaserte tjenester fungerer på denne måten.
2) At klokken gjenvinnes fra innkommende datastrøm eller egen egnet signallering. En del profesjonelle audiosystemer, som Dante, bruker en egen protokoll (PTP) for å lage sample-nøyaktig synkronisering fra en sentral klokkemaster. Disse teknologiene kan ikke routes på internett eller gå over wifi (fordi latencyen er for lang og variabel).
Brukes nr 2 i det hele tatt av noen Hifi-streamere?
Kan vi da trekke kortslutningen at audio via nettverkskabler er en svært lite egnet løsning?
D/A-konverteringen er ihvertfall det eneste punktet i den digitale kjeden hvor tidsvariasjonene betyr noe som helst, og så kan vi sikkert diskutere hvor lav jitter må være før det ikke lenger er hørbart med en gitt DAC. Min DEQX HDP-4 er ikke helt immun mot jitter, så det er fullt mulig å høre forskjell f eks mellom et mekanisk CD-drivverk basert på Philips CD-PRO og en Logitech Transporter gjennom den.Klokken er alfa omega! Denne er inne til testing av en HiFi kolega, første tilbakemelding, Enkelt og greitt, Bedre lyd
Nei.
Vel, hvis det er så stor uforutsigbarhet som tilbakemeldingene fra brukere tilsier er ikke akkurat dette noen "bulletproof" løsning, det regner jeg med at vi kan slå fast.
Som å handle på butikken med papirposer og det blir regn på veien og når en kommer hjem ligger mesteparten av godsakene igjen langs veien..?... Vel..Sist redigert: -
Laster inn…
Diskusjonstråd Se tråd i gallerivisning
-
Laster inn…