Oppskrift for god hjemmelaget musikk server

[nb]

Det er sikkert mulig å tweake litt på en datamaskin vha strømforsyninger, lage et fint kabinett og lignende, men når alt kommer til alt må den være basert på standard hyllevare siden den må være i stand til å kjøre eksisterende operativsystem og programvare, den må funke sammen med standardutstyr over standard interfacer som USB, PCI(e) og lignende.

 

[Dazed]

Tja. Blue Smoke later til selv å kalle sin "Black Box" for et "computer based audio system", og opplyser at den kjører Windows 7. Det høres ut som IT for meg. Det høres dessuten fremdeles ut som en PC for musikkavspilling mer enn noen form for server, men det har de fleste vel oppfattet at jeg mener nå.

Dette høres også "IT" ut, synes jeg, selv om det presenteres som audiofile produkter:

AudioNec Music Servers use the infrastructure of
a modern silent high-power computer to rip CDs,
store, manage and play near limitless music files.

Aurender skryter av å ha sin egen "Master Clock" (har ikke alle PC-er en "master clock" på hovedkortet?), og annen proprietær hardware, men ser likevel ut som PC-er for meg.

Light Harmonic ser det ut for meg som at bare produserer DAC-er, og de anbefaler å bruke en helt vanlig MAC til lagring av filer:

Jeg vil hevde at ingen av disse er "servere", men hvis man skal kalle dem noe fra IT-sjargongen i det hele tatt, er de rett og slett PC-er. Lumin kaller sin variant en "Audiophile Network music Player", og det høres mer riktig ut for meg enn "music server" som enkelte tydeligvis kaller slike produkter. Uansett er disse produktene kun PC-er som med unntak av propritære GUI-er og frontends de måtte ha, ikke er mer enn det man kan utrette med en selvbygd PC til 5-6000 og en god dac eller et godt lydkort.

IMNSHO, selvsagt, og YMMV.

 

[Roysen]

Dazed,

Du setter vel ikke en Blue Smoke Systems eller AudioNec inn i ditt nettverk og bruker den som PC eller server, gjør du vel? Altså ikke til IT-foremål og spesiallaget for audiobruk.

Mvh
Roysen

 

[Dazed]

Nei, det gjør jeg såvisst ikke. Til det er den garantert alt for dyr. Uansett er disse produktene slik jeg ser det datamaskiner for bruk til musikkavspilling. Noen av dem har innebygget DAC (hei, det har datamaskiner også) som er litt mer påkostet enn gjengse lydkort og litt annerledes brukergrensesnitt og tilkoblingsmuligheter enn en generisk PC, men likevel.

...Men vi trenger jo ikke for enhver pris å bli enige.

 

[DL]

This White Paper takes a stab at guiding readers towards building a [FONT=Times New Roman,Times New Roman][FONT=Times New Roman,Times New Roman]dedicated [/FONT][/FONT]audiophile Windows-based music server. This means that the server is used only for serving music, and very little else. It is by no means comprehensive, but there is much information available on the Internet to help. It is also not a "cookbook" or recipe as computer components go obsolete extremely quickly. Hence, some recommendations may no longer be available by the time you read this paper. Nevertheless, the nature of computer components is that the alternatives and replacements will be cheaper and better!!


Om det er gammelt utstyr brukt i artikkelen har altså null betydning.




DL

 

[Class]

Men latency i serveren kan medføre jitter når signalet skal konverteres til analogt i D/A converteren.

Nei. Kan ikke og gjør ikke.

Jo

Mvh
Roysen

Jasså, hvordan? Det eneste jeg kan komme på er feil i reciever-enden.
Jeg har inntrykk av at IT kanskje ikke er din sterkeste side. Det er nok FUD rundt data-basert musikkavspilling fra før.

 

[Roysen]

Kanskje vi skal holde oss til sak og hoppe over personangrepene? De styrker ikke akkurat din sak. Jeg er faktisk utdannet innen IT og har 20 års erfaring som databaseministrator for Oracle databaser.

Latency som en følge av interrupts i alle de unødvendige prodessene i et general purpose OS er årsaken.

Mvh
Roysen

 

[Class]

Personangrep? Jeg er faktisk utdannet innen IT og har 20 års erfaring som databaseministrator for Oracle databaser. I mine øyne er du kanskje den som ikke har dette som din sterkeste side.

Jeg synes ikke det var et personangrep fra min side men beklager om du oppfattet det sånn.

Latency som en følge av interrupts i alle de unødvendige prodessene i et general purpose OS er årsaken.

Her skriver du noe som igjen gjør at jeg tenker at iallfall nettverks teknologi ikke er din sterkeste side
For mottageren (klienten) er det revnende likegyldig hvilket OS og hvilke interrupts serveren har. Det er hele poenget med TCP og UDP.
En datapakke er en datapakke, uavhengig av hva inneholdet er. Det er litt besynderlig å se at med en gang det er snakk om at det er "audio-data" som transporteres så blir liksom hele nettverksprosessen er skjørt vesen.

Merk at jeg igjen prater om serveren (som i filserver/NAS). I klienten er det kanskje en helt annen kanne ormer.

 

[Roysen]

Du glemmer at ved musikkavspilling er timing viktig. Latency forårsaker timingeil og Jitter.

Jeg ber igjen om at du holder deg til sak og holder min person utenfor diskusjonen. Det styrker som sagt ikke din sak. Tvert i mot.

Mvh
Roysen

 

[Class]

Så hårsår altså? DU må gjerne gjenta at jeg ikke kan noe om disse tingene så er vi kvitt.
En eksamen i Wordperfect er vel alt jeg har å vise til av papirer etter 30 år+ med IT

Poenget er at evt. latency på server blir ikke overfør til klienten på en eller annen mystisk måte.
Datapakkene blir sjekksummet, delt opp, evt. fragmentert, sendt, evt. sendt igjen, satt sammen, satt sammen i rett rekkefølge og sjekksummet igjen, med mer.
Igjen, dette er ekstremt robust teknologi og har vært det i mange mange år.

Men for all del, det er spennende område å holde audiophilia nevrosa i live på.

 

[Roysen]

Nå tror jeg du må sjekke hva latency betyr før du skriver noe mer. Det har ikke noe med innholdet i datapakkene å gjøre.

Det du ikke har forstått er at selv om overføringen er bitperfect kan latency medføre timing error i avspillingen. Ved normal IT bruk er ikke timing kritisk.

Nå gidder jeg imidlertid ikke å diskutere dette mer før du legger personangrepene vekk.

Mvh
Roysen

 

[J.J]

@ Roysen

Gled deg til du begynner med vinyl - der er feilmarginene enda større

 

[Class]

Jeg vet hva latency er. Kanskje du kan forklare hvordan de blir overført via TCP eller UDP fra server til klient?

 

[Roysen]

Jeg vet hva latency er. Kanskje du kan forklare hvordan de blir overført via TCP eller UDP fra server til klient?

Det har jeg allerede forklart for deg. Latency spiller inn på timingen ved overføringen av pakkene. Det er altså ikke innholdet i pakkene som påvirkes. Ditt spørsmål om hvordan latency overføres viser at du ikke forstår hva det betyr. Det har ikke noe med innholdet i overføringen å gjøre. Det handler om timingen av overføringen av pakkene.

Mvh
Roysen

 

[Roysen]

@ Roysen

Gled deg til du begynner med vinyl - der er feilmarginene enda større

Det er åpenbart.

Mvh
Roysen

 

[Dazed]

Jeg synes noen har ekstremt lav terskel for å rope personangrep, men det får nå være.

Poenget er vel at på serversiden, altså før filene kommer i nærheten av noen dekoding eller d/a-konvertering, har eventuelle feil i tidsdomenet null og niks betydning, siden alt som måtte oppstå av tap og forsinkelser fanges opp og fikses av TCP/IP-protokollen. Jitter som reduserer lydkvaliteten er først et tema i det datastrømmen når avspillingsprogrammet/-hardwaren.

 

[Roysen]

TCP/IP protokollen korrigerer ikke for timing av noe slag og selv om timingavvikene ikke har betydning før signalet konverteres til analogt vil det påvirke komverteringsprosessen når signalet kommer til D/A prossen.

Mvh
Roysen

 

[Class]

Jeg vet hva latency er. Kanskje du kan forklare hvordan de blir overført via TCP eller UDP fra server til klient?

Det har jeg allerede forklart for deg. Latency spiller inn på timingen ved overføringen av pakkene. Det er altså ikke innholdet i pakkene som påvirkes. Ditt spørsmål om hvordan latency overføres viser at du ikke forstår hva det betyr. Det har ikke noe med innholdet i overføringen å gjøre. Det handler om timingen av overføringen av pakkene.

Mvh
Roysen

Artig lesing dette, Roysen. Kan du få tak i noe dokumentasjon så skal jeg sende en bug report til de aktuelle utviklerne på dine vegne
Det du skriver om ligner på problematikken rundt USB, det er ikke det du tenker på?

 

[Roysen]

Bug? Hvem har nevnt bugs? TCP/IP protokollen fungerer da som den skal selv om den ikke ble laget for å håndtere dette. Jeg vet ikke hvilken USB problematikk du tenker på.

Mvh
Roysen

 

[Class]

TCP/IP protokollen fungerer da som den skal selv om den ikke ble laget for å håndtere dette.

Hva er dette? Disse spesielt skjøre datapakkene?

 

[Dazed]

TCP/IP protokollen korrigerer ikke for timing av noe slag og selv om timingavvikene ikke har betydning før signalet konverteres til analogt vil det påvirke komverteringsprosessen når signalet kommer til D/A prossen.

Mvh
Roysen

Timing har ikke noe å si. Pakkene blir sendt i riktig rekkefølge, og mistes en pakke, sendes den på nytt. Det er hele poenget med "pakker" med data i stedet for en strøm, slik et avspillingsprogram eller en dac må slite med.

Det er meningsløst å prøve å løse et problem som ikke eksisterer. Latency i TCP/IP og annen overføring av data på/fra/til serveren påvirker ikke lydkvalliteten i det hele tatt. Det kan den rett og slett ikke. Det er ikke mulig, fordi det ikke er sånn det fungerer.

 

[Roysen]

Les det som er skrevet. TCP/IP protokollen er ikke skrevet for å ivareta tidssensitiv informasjon. Den tar ikke hensyn til timing av overføring av pakkene..

Mvh
Roysen

 

[marsboer]

TCP/IP protokollen korrigerer ikke for timing av noe slag og selv om timingavvikene ikke har betydning før signalet konverteres til analogt vil det påvirke komverteringsprosessen når signalet kommer til D/A prossen.

Det som skjer i nettverksdelen vil ikke påvirke signalet som går ut mot DACen. At TCP/IP ikke bryr seg om nøyaktig klokking, bare rekkefølgen på pakkene, er derfor helt urelevant for lydmessige formål.

Disse dataene går inn i applikasjonsbufferne etter at de er satt sammen og klokkes ut på nytt etter applikasjonens forgodtbefinnende etter enten DACs eller PCens egen klokke. Dette nullstiller de normale jittervariasjonene man alltid vil få i et best effort pakkeswitchet nettverk som også har andre klienter og/eller annen trafikk som går på den samme linken.

Det er ikke før etter at applikasjonen har konvertert dataene til lydkortsignaler at man kan påvirke signalet på en måte som gir variabel latency på digitalsignalet som går mot DAC, som igjen kanskje kan gi avvik på analogsiden (med forbehold om at man ikke har så ekstreme jitterverdier på nettverkssiden at bufferet tømmes, noe som ikke er et problem så lenge man holder seg unna ustabile trådløse nettverk).

 

[Dazed]

Les det som er skrevet. TCP/IP protokollen er ikke skrevet for å ivareta tidssensitiv informasjon. Den tar ikke hensyn til timing av overføring av pakkene..

Mvh
Roysen

Nei, for den behøver ikke det. Om hver eneste pakke bruker forskjellig tid på å komme frem betyr det ingenting. Dataene pakkene transporterer blir uansett ikke satt sammen og tolket før alle pakkene er mottatt.

TCP/IP fungerer jo forresten til og med pr. brevdue, så den protokollen er ganske robust. (Ja, det er gjort. På NTNU)

 

[Roysen]

TCP/IP protokollen korrigerer ikke for timing av noe slag og selv om timingavvikene ikke har betydning før signalet konverteres til analogt vil det påvirke komverteringsprosessen når signalet kommer til D/A prossen.

Mvh
Roysen

Timing har ikke noe å si. Pakkene blir sendt i riktig rekkefølge, og mistes en pakke, sendes den på nytt. Det er hele poenget med "pakker" med data i stedet for en strøm, slik et avspillingsprogram eller en dac må slite med.

Det er meningsløst å prøve å løse et problem som ikke eksisterer. Latency i TCP/IP og annen overføring av data på/fra/til serveren påvirker ikke lydkvalliteten i det hele tatt. Det kan den rett og slett ikke. Det er ikke mulig, fordi det ikke er sånn det fungerer.

Det stemmer ikke. Å sende en pakke på nytt påvirker timingen av den totale datastrømmen selv om pakken kommer frem uten innholdsavvik. Det spiller ingen rolle fot et Word dokument. For musikk blir det noe annet.

Mvh
Roysen

 

[Dazed]

TCP/IP protokollen korrigerer ikke for timing av noe slag og selv om timingavvikene ikke har betydning før signalet konverteres til analogt vil det påvirke komverteringsprosessen når signalet kommer til D/A prossen.

Mvh
Roysen

Timing har ikke noe å si. Pakkene blir sendt i riktig rekkefølge, og mistes en pakke, sendes den på nytt. Det er hele poenget med "pakker" med data i stedet for en strøm, slik et avspillingsprogram eller en dac må slite med.

Det er meningsløst å prøve å løse et problem som ikke eksisterer. Latency i TCP/IP og annen overføring av data på/fra/til serveren påvirker ikke lydkvalliteten i det hele tatt. Det kan den rett og slett ikke. Det er ikke mulig, fordi det ikke er sånn det fungerer.

Det stemmer ikke. Å sende en pakke på nytt påvirker timingen av den totale datastrømmen selv om pakken kommer frem uten innholdsavvik. Det spiller ingen rolle fot et Word dokument. For musikk blir det noe annet.

Mvh
Roysen

Ja, du får nesten bare tro det, da.

 

[J.J]

Hva har det å si for musikken ?? Dette som tilsynelatende er et problem ??

Stokker Kari Bremnes om på ordene eller hva ?

 

[Roysen]

TCP/IP protokollen korrigerer ikke for timing av noe slag og selv om timingavvikene ikke har betydning før signalet konverteres til analogt vil det påvirke komverteringsprosessen når signalet kommer til D/A prossen.

Det som skjer i nettverksdelen vil ikke påvirke signalet som går ut mot DACen. At TCP/IP ikke bryr seg om nøyaktig klokking, bare rekkefølgen på pakkene, er derfor helt urelevant for lydmessige formål.

Disse dataene går inn i applikasjonsbufferne etter at de er satt sammen og klokkes ut på nytt etter applikasjonens forgodtbefinnende etter enten DACs eller PCens egen klokke. Dette nullstiller de normale jittervariasjonene man alltid vil få i et best effort pakkeswitchet nettverk som også har andre klienter og/eller annen trafikk som går på den samme linken.

Det er ikke før etter at applikasjonen har konvertert dataene til lydkortsignaler at man kan påvirke signalet på en måte som gir variabel latency på digitalsignalet som går mot DAC, som igjen kanskje kan gi avvik på analogsiden (med forbehold om at man ikke har så ekstreme jitterverdier på nettverkssiden at bufferet tømmes, noe som ikke er et problem så lenge man holder seg unna ustabile trådløse nettverk).

Dette er i og for seg korrekt dersom msn mener at reklokking er en god nok løsning.. Forøvrig er det ikke alle interface til DAC som lar klokken i DAC styre overføringen f.eks. USB.

Mvh
Roysen

 

[Roysen]

TCP/IP protokollen korrigerer ikke for timing av noe slag og selv om timingavvikene ikke har betydning før signalet konverteres til analogt vil det påvirke komverteringsprosessen når signalet kommer til D/A prossen.

Mvh
Roysen

Timing har ikke noe å si. Pakkene blir sendt i riktig rekkefølge, og mistes en pakke, sendes den på nytt. Det er hele poenget med "pakker" med data i stedet for en strøm, slik et avspillingsprogram eller en dac må slite med.

Det er meningsløst å prøve å løse et problem som ikke eksisterer. Latency i TCP/IP og annen overføring av data på/fra/til serveren påvirker ikke lydkvalliteten i det hele tatt. Det kan den rett og slett ikke. Det er ikke mulig, fordi det ikke er sånn det fungerer.

Det stemmer ikke. Å sende en pakke på nytt påvirker timingen av den totale datastrømmen selv om pakken kommer frem uten innholdsavvik. Det spiller ingen rolle fot et Word dokument. For musikk blir det noe annet.

Mvh
Roysen

Ja, du får nesten bare tro det, da.

Det er nok ikke bare meg.

Mvh
Roysen

 

[marsboer]

Dette er i og for seg korrekt dersom msn mener at reklokking er en god nok løsning..

Det er vel ikke så mye å mene så mye om på akkurat dette tør jeg påstå. Jeg vet rett og slett ikke om noen mekanisme i operativsystemet eller maskinvaren som klarer å "lagre" jitter fra nettverket på veien fra nettverksgrensesnittet, via applikasjonsbufferet, gjennom logikken i applikasjonen og deretter pådytte lydkortets digitalsignaler jitter, og da delvis overstyre klokkejusteringssignalene fra f.eks asynkron USB, basert på innsignalet på RJ45-pluggen. Det er nesten så jeg får et inntrykk av at du mener dette er en sammenhengende klokkekjede som bærer et lydsignal hele veien, omtrent som en lang S/PDIF-kabel fra NAS til DAC.

 

[X186841]

Eneste problemet som oppstår er stillhet til bufferen er fylt opp igjen.

 

[nb]

Det virker som noen tror at et klient/serversystem for musikkavspilling fungerer som følger:

En byte leses fra harddisken, sendes over nettverket, behandles på klientsiden og sendes til DACen. Når denne operasjonen er fullført så leses neste byte og så går no dagan til hele musikksnutten er avspillt. Legger man en slik forståelse til grunn så kan jeg skjønne at man mener at latency er veldig viktig. Problemet er imidlertid at det ikke er slik ting fungerer i den virkelige verden.

Et lite tankeeksperiment: Låter en filserver plassert i huset bedre enn en filserver plasert et annet sted fra en ulik nettilbyder? I de to tilfellene er det et hav av forskjell på hvor mange mellomstasjoner og ulikt utstyr disse ekstremt skjøre datapakkene som inneholder noe som tilfeldigvis er musikk må passere gjennom.

 

[Roysen]

Løsningen på utfordringen er kun når hele musikkstykket buffres i D/A converteren før konvertering til analog. Så lenge d/a converteren har konvertert deler av musikkstykket til et analog signal vil en oppdeling medføre at timingen av overføringen av de ulike delene påvirker D/A prosessen. Så store cache er ikke vanlig i en standard PC. Derav min tidligere beskrivelse av at komponentene må ha spesialisert hardware og software for oppgaven.

Mvh
Roysen

 

[nb]

Det er nok ikke bare meg.

Mvh
Roysen

Nei, etter at HiFi-folket la sin hånd på datamaskinbasert musikkavspilling er det ikke måte på hvor skjøre, feilbarlige og uegnede teknologi og produkter som viser seg å fungere strålende i alle andre sammenhenger som stiller MYE større krav mhp det aller meste plutselig blir.

Jeg skrev for noen år siden på dette forum at alle audiofile nevroser fra CD-spillere og platespillere også ville bli overført til dataverdenen, og det sjokkerer meg ikke akkurat at den antagelsen viser å stemme.

 

[Dazed]

Løsningen på utfordringen er kun når hele musikkstykket buffres i D/A converteren før konvertering til analog. Så lenge d/a converteren har konvertert deler av musikkstykket til et analog signal vil en oppdeling medføre at timingen av overføringen av de ulike delene påvirker D/A prosessen.

Mvh
Roysen

Dette har jo ikke noe med serveren og agringshardwaren å gjøre.

 

[slettix]

Løsningen på utfordringen er kun når hele musikkstykket buffres i D/A converteren før konvertering til analog. Så lenge d/a converteren har konvertert deler av musikkstykket til et analog signal vil en oppdeling medføre at timingen av overføringen av de ulike delene påvirker D/A prosessen.

Mvh
Roysen

Men dette har jo ikke noe med nettverksproblematikk å gjøre? Filen har jo allerede blitt lest inn av avspillingsprogrammet på enheten som sender dette videre til DAC'en. At det kan oppstå jitter-problematikk mellom disse to enhetene (avspillingsklient og DAC via USB e.l) tror jeg vi kan være enige om, men dette har jo ikke noe med TCP/IP å gjøre...

 

[Roysen]

Løsningen på utfordringen er kun når hele musikkstykket buffres i D/A converteren før konvertering til analog. Så lenge d/a converteren har konvertert deler av musikkstykket til et analog signal vil en oppdeling medføre at timingen av overføringen av de ulike delene påvirker D/A prosessen.

Mvh
Roysen

Dette har jo ikke noe med serveren og agringshardwaren å gjøre.

Jo, så lenge bare deler av musikkstykket buffres i alle ledd og ikke hele vil timingen av deler som ikke er overført fra server til streamer påvirke D/A prosessen så lenge noe av musikkstykket er konvertert til analog.

Mvh
Roysen

 

[marsboer]

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.

 

[nb]

Jo, så lenge bare deler av musikkstykket buffres i alle ledd og ikke hele vil timingen av deler som ikke er overført fra server til streamer påvirke D/A prosessen så lenge noe av musikkstykket er konvertert til analog.

La oss si at den påstanden er riktig (hvilket den ikke er, men for diskusjonens skyld, la oss late som den er det).

Hva skal en produsent av audiofil-grade filservere gjøre med den saken? Skal de skrive om hele nettverksstacken til Windows (som de ikke har tilgang til kildekoden for), ditto til Apple OSX (som de heller ikke har tilgang til) eller til Linux (som er open source, men som de neppe har kompetanse til å modifisere). Skal de finne frem den RAID-kontrolleren som er mest hysterisk overspeccet i forhold til den latterlig enkle oppgaven det er å overføre maks noen veldig få megabyte i sekundet? Skal de skrive om mdadm om de bruker SW-Raid under Linux? Skal de dikte opp en helt egen nettverksprotokoll de skal få til å funke med eksisterende operativsystemer (de har selvsagt ikke tid, kompetanse eller er dumme nok til å prøve å lage et OS fra scratch selv).

Denne bransjen går stort sett ut på å inbille potensielle kunder at de har gjort veldig mye arbeide for å kunne ta titusenvis av kroner for en datamaskin med svært begrenset funksjonalitet og eventuelt med en innebygget DAC.

Av ren nysjerrighet: Finnes i det hele produkter som kan karakteriseres som "audiofile filservere", eller er det konseptet for idiotisk selv for HiFi-bransjen?

 

[Roysen]

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