Voyage MPD

[marsboer]

Hos meg går update kun når det er en oppdatering som kjører. Og denne tråden starter ikke før oppdateringen settes igang. Det er derfor helt avhengig av tidligere bruk av mpd om denne dukker opp før eller etter decoder/output trådene. Det er bare å følge med på trådene når man setter i gang en operasjon, så ser man det med en gang på min installasjon.

har ikke gjort noen sammenligning mellom nrpacks 8 og 1 enda. Jeg ser for meg en kveldsøkt hvor jeg tester dette.

 

[coolbiz]

Mye gull i denne tråden. 5 stjerner avgitt.

Spørsmål til marsboer: Er det Bryston BDA-1 du forer med Voyage-boksen? Har du sammenlignet med Logitech Transporter som digitalkilde?

 

[marsboer]

Først: Jeg benytter ikke Voyage. Det er imidlertid lett å bli forvirret siden den generelle Linux MPD-diskusjonen også foregår her, og Voyage er vel også basert på Debian.
"Boksen" min er en selvbygd PC. Det har aldri vært noe tema å installere Voyage på denne.

Jeg benytter en minimal 64-bit installasjon av Debians kommende versjon med kodenavn Wheezy. Jeg liker best å benytte egenskrudde versjoner av Debian hver gang jeg drar inn Linux i et prosjekt, siden jeg da vet hva som er gjort og hva jeg kan forvente videre. Dette betyr ikke at "native" Debian er mer eller mindre egnet enn Voyage. Det er kun en personlig preferanse.

Min audio-kjede er slik:
Debian Wheezy 64-bit / MPD -> M2Tech HiFace Two USB to RCA S/PDIF -> RCA-BNC -> Bryston BDA-1 -> XLR -> Marantz SC-11S1 -> XLR -> Bryston 4B SST2 -> Klipsch RF-7 II

Transporter står fremdeles nedpakket etter flytting og jeg har ingen referanser med denne i mitt nåværende oppsett, som jo låter totalt annerledes enn før på grunn av helt annet rom. Planen er å legge den ut på bruktmarkedet i nær fremtid.
Jeg vet heller ikke om jeg tar meg bryet med å pakke den ut og koble den opp i anlegget bare for å sammenligne siden byttet av digital transport er motivert av helt andre ting enn at Transporter fungerte for dårlig. Men om en sammenligning skulle være et sterkt ønske fra noen, så er det jo fullt mulig å få til. Det er til og med mulig å få høre med egne ører om du befinner deg i nærheten av Oslo et sted.

 

[coolbiz]

Ehhh, ja, jeg mente selvfølgelig "MPD-boksen". Ikke stress med sammenligning, marsboer, men skriv gjerne en setning eller to dersom du finner noe å rapportere ved en senere anledning.

 

[nb]

Bra nerdet gutar.

 

[gut_man]

Skjønner lite av diskusjonen, men er svært glad for de nerdete diskusjonene som Man lar meg nyte godt av i form av stadig forbedrede MPD versjoner. Så får jeg heller forsøke å bruke ører og lytteerfaring for å validere det som "nerdes" frem. Venter som tidligere nevnt enda på mitt hiface-two interface og regner med å komme sterkere på baneni denne tråden for å dele noe som forhåpentligvis er rimelig nøytrale innteykk av både software og hardware etter som MPD prosjektet mitt skrider frem. Og bare for å ha sagt deti klartekst; Jeg er en forholdsvis uvitende hvermannsen når det kommer til pc-kunnskaper. Klarer meg til husbruk på hjemmets windowsbaserte pc'er, men er totally f..cked når jeg må skrive i stedet for å klikke på ikoner

Likevel har Man og Oblivion helt rett når de hevder at MPD er brukervennlig og genialt enkelt. Når ting er oppe og går, funker det som bare det både ifht stabillitet og lyd. Så til alle som måtte synes at dette er den mest "nerdete" tråden her inne, ha tålmod. Det dere leser, er jo faktisk pc-audio evolusjon i real time. Nesten som om dyktige forsterker eller høyttaler konstruktører skulle diskutere videreutviklinger av produkter som ble gjort omtrent gratis tilgjengelig for alle diy'ere (Oblivion er jo faktisk også en slik kapasitet) Sit back and enjoy folks, for dette blir garantert en hakeslipp-opplevelse for de som velger å implementere det disse gutta leker med!

 

[nma]

@marsboer Du har rett i at update tråden opprettes først ved scanning =) Ble litt lurt i første omgang..
ps -eLo pid,lwp,rtprio,priority,cmd | grep mpd <-- Første PID er samlet for hele MPD prosessene, andre PID er main, player på tredje etc..

 

[Oblivion]

Den største forskjellen på @man / @marsboer installasjonene og min er at de ikke kjører høyere enn 192k og ikke native DSD.
Jeg kjører stort sett 352.8k/32bit og native DSD128.
Jeg går heller ikke veien om SPDIF...
Jeg kunne funnet frem en Hifase med SPDIF for å teste, men vet av erfaring at det er å gå ca. 100 skritt tilbake..

Det jeg er helt sikker på er at de tweak og settinger i kernel og mpd som spiller best med opp til 192k og med SPDIF innblandet ikke vil være optimalt med isolert USB og direkte re-klokket I2S inn i DAC som har ekstremt lavt støy nivå og ekstremt høy oppløsning.

Jeg har også SPDIF inngang på DACen og med standard oversamplings filter er lydkvaliteten såpass elendig pga SPDIF hardwaren at tweaking på kernel og mpd stort sett blir å "voice" til SPDIF hardwaren.

Jeg har fått prøve noen versjoner av @man Voyage MPD, men uten passord slik at jeg ikke har hatt mulighet til å forsøke noen alternative settinger i mitt system.

 

[nma]

Forstår ikke helt hvorfor du ikke installerer din egen minimale Debian Wheezy? Det tar 15min, og da kan du prøve deg fram så mye du vil selv.
Jeg kan lage ISOer hvor alt unødvendig inkl login og ssh er strippet vekk, men jeg vil anbefale å installere selv. Og det skjønner jeg jo ikke helt, det virker ikke som om det er noe tvil om at du er i stand til det ihvertfall. Dette er ikke akkurat rakettforskning, selv om det definitivt kvalifiserer til nerding på høyt nivå...

Nå kjører ikke jeg S/Pdif heller, mens native DSD er ikke noe jeg foreløpig higer mot. Men det er selfølgelig ikke slik at bare fordi en DAC er kapabel til 352/384, eller at den klarer å oversette et DSD-kodet PCM signal om til DSD, så skal den respondere annerledes på innstillinger. Min erfaring er at innstillinger/tweaks påvirker selve operativsystemet, med derav bedre lyd som er ganske universalt. En forbedring er en forbedring uansett lydkort liksom. Ikke så mye direkte voicing, selv om det sikkert kan virke slik iblant (og det kan sikkert argumenteres med et og to tvilstilfeller)

 

[Oblivion]

Forstår ikke helt hvorfor du ikke installerer din egen minimale Debian Wheezy? Det tar 15min, og da kan du prøve deg fram så mye du vil selv.
Jeg kan lage ISOer hvor alt unødvendig inkl login og ssh er strippet vekk, men jeg vil anbefale å installere selv. Og det skjønner jeg jo ikke helt, det virker ikke som om det er noe tvil om at du er i stand til det ihvertfall. Dette er ikke akkurat rakettforskning, selv om det definitivt kvalifiserer til nerding på høyt nivå...

CuBox blir levert i dag og da må jeg begynne "linux nerdingen"..
Hadde håpet at linux "nerdene" hadde vært litt mindre egosentriske slik at jeg kunne fokusert på hardware og firmware
Men jeg får sette i gang og "bygge" en Intel versjon og en ARM versjon tilpasset den hardwaren jeg bruker.
Regner med at dette tar endel tid fordi jeg må sette meg inn i endel "nerde materiale" før jeg har et oppsett som fungerer tilfredstillende.

Nå kjører ikke jeg S/Pdif heller, mens native DSD er ikke noe jeg foreløpig higer mot. Men det er selfølgelig ikke slik at bare fordi en DAC er kapabel til 352/384, eller at den klarer å oversette et DSD-kodet PCM signal om til DSD, så skal den respondere annerledes på innstillinger. Min erfaring er at innstillinger/tweaks påvirker selve operativsystemet, med derav bedre lyd som er ganske universalt. En forbedring er en forbedring uansett lydkort liksom. Ikke så mye direkte voicing, selv om det sikkert kan virke slik iblant (og det kan sikkert argumenteres med et og to tvilstilfeller)

To identiske hovedkort med identiske komponenter, men hvor en har en standard strømforsyning og den andre har en kraftig oppgradert strømforsyning vil få helt forskjellig "voicing" når en tweaker OS / apps.

Hvis en veksler mellom uisolert og isolert USB så er lyd kvalitet / signatur så forskjellig at det en tweaker til med uisolert mest sannsynlig ikke spiller best med isolert USB.

På et og samme system som er kapabel til 352.8k/384k/32bit og en har en ES9018 (eksempel) basert DAC så vil Quantizer i DAC jobbe med en hastighet som er lik uansett format som kommer inn...
Men en har noen valgmuligheter (utgangspunkt en 44.1k/16bit fil):
1. Sende data som 44.1k/16bit og la DAC foreta hele over/up samplings jobben.
2. La MPD over/up sample til 352.8k/32bit og disable første over/up samplings filter i DAC.
3. Over/up sample til 352.8k/32bit offline og MPD sender kun data til DAC og disable første over/up samplings filter i DAC.

Det som jeg har erfart spiller best er alternativ 3 etterfulgt av 1 og 2.
Med andre ord - DAC gjør jobben bedre enn MPD, men en ferdig over/up samplet fil spiller best fordi både MPD og DAC blir avlastet den jobben...

 

[Goophy]

CuBox blir levert i dag og da må jeg begynne "linux nerdingen"..
Hadde håpet at linux "nerdene" hadde vært litt mindre egosentriske slik at jeg kunne fokusert på hardware og firmware
Men jeg får sette i gang og "bygge" en Intel versjon og en ARM versjon tilpasset den hardwaren jeg bruker.
Regner med at dette tar endel tid fordi jeg må sette meg inn i endel "nerde materiale" før jeg har et oppsett som fungerer tilfredstillende.

Får du den idag!? Jeg fikk bare e-post om at min blir levert senest 15. August.

De er vel egentlig ikke egosentriske iogmed at de fleste kjerner som blir levert kommer med støtte for så godt som alt mulig.
Vil du bygge dine egne ting med egne parametere blir det såklart litt å sette seg inn i, men det trenger ikke nødvendigvis være så altfor vrient.
Archlinux (Arch Linux ARM | Arch Linux ARM) har et veldig enkelt og greit byggesystem for pakker (inkludert kjerner) der du kan modifisere parametere osv. i en tekstfil.

Det eneste man må være litt påpasselig med når det gjelder ARM er å oppdatere uboot-scriptene hver gang man gjør endringer.

 

[Oblivion]

CuBox blir levert i dag og da må jeg begynne "linux nerdingen"..
Hadde håpet at linux "nerdene" hadde vært litt mindre egosentriske slik at jeg kunne fokusert på hardware og firmware
Men jeg får sette i gang og "bygge" en Intel versjon og en ARM versjon tilpasset den hardwaren jeg bruker.
Regner med at dette tar endel tid fordi jeg må sette meg inn i endel "nerde materiale" før jeg har et oppsett som fungerer tilfredstillende.

Får du den idag!? Jeg fikk bare e-post om at min blir levert senest 15. August.

De er vel egentlig ikke egosentriske iogmed at de fleste kjerner som blir levert kommer med støtte for så godt som alt mulig.
Vil du bygge dine egne ting med egne parametere blir det såklart litt å sette seg inn i, men det trenger ikke nødvendigvis være så altfor vrient.
Archlinux (Arch Linux ARM | Arch Linux ARM) har et veldig enkelt og greit byggesystem for pakker (inkludert kjerner) der du kan modifisere parametere osv. i en tekstfil.

Det eneste man må være litt påpasselig med når det gjelder ARM er å oppdatere uboot-scriptene hver gang man gjør endringer.

Sjekket leveringstid for en tid tilbake og de var da "tomme" og ventet ny batch i slutten av juli...
Og de hadde en lang venteliste (flere hundre) som de skulle sende ut.
Jeg fikk sporingsnummeret en uke før pakken ble fysisk sendt så de jobber nok med liten bemanning.
Min CuBox ble sendt 29. og blir utlevert i dag (Posten skulle normalt levere den ut i morgen, men denne gangen var de ekstra velvillige).

 

[marsboer]

Oblivion:
Dette er det beste jeg har å tilby for øyeblikket. Jeg har også laget et mer avansert script for enkel testing og aktivering av optimaliseringer enn det jeg har lagt ut i denne tråden.

Hi-Fi Debian MPD USB transport - marsboer.net wiki

Jeg har nok et litt annet fokus for oppsettet enn Man og Oblivion.
Neste for meg er å se på mulighetene for å laste OS inn i RAM, enten fra lokal disk, minnepinne eller nettverk. Dette har imidlertid ikke høy prioritet for meg, all den tid hensikten med min mpd-installasjon er å ha noe jeg kan oppdatere regelmessig via apt-get, og ikke en mer eller mindre read-only appliance.

 

[Oblivion]

Oblivion:
Dette er det beste jeg har å tilby for øyeblikket. Jeg har også laget et mer avansert script for enkel testing og aktivering av optimaliseringer enn det jeg har lagt ut i denne tråden.

Hi-Fi Debian MPD USB transport - marsboer.net wiki

Jeg har nok et litt annet fokus for oppsettet enn Man og Oblivion.
Neste for meg er å se på mulighetene for å laste OS inn i RAM, enten fra lokal disk, minnepinne eller nettverk. Dette har imidlertid ikke høy prioritet for meg, all den tid hensikten med min mpd-installasjon er å ha noe jeg kan oppdatere regelmessig via apt-get, og ikke en mer eller mindre read-only appliance.

Dette blir utrolig bra!

marsboer:
Ditt fokus er nok det riktige for de fleste som vil prøve MPD og ha en installasjon som fungerer over tid.

 

[Oblivion]

Får du den idag!? Jeg fikk bare e-post om at min blir levert senest 15. August.

CuBox mottat og kabinettet åpnet...
Første avvik som er funnet er at micro SD kortet er 4GB og ikke 2GB
Det blir ikke lett å modifisere denne lille enheten i stor grad hvis kabinettet fortsatt skal benyttes.
Det indre aluminiums kabinettet brukes også som kjøling av ARM CPU så min første modifikasjon
blir å montere nye "RAM" kjølere i kobber slik at en kommer til kretskortet og samtidig får bedre kjøling.

Skal prøve å få tak i skjema slik at det blir enklere å fortsette modifiseringene.

 

[gut_man]

Lytterapport fra test av siste MPD iso fra Man. Nå begynner dette å lukte gull Har en meget habil vinyl referanse som jeg bruker for å sammenligne digitalkilden med. Med siste versjon MPD er de største forbedringene slik jeg hører dem fra mellomtone og oppover. Nå er det mye mindre "digitalis", mellomtonen virker mer organisk med mer smekk. Som jeg har påpekt tidligere var det litt vel stramt i dette området med tidligere versjoner. Diskantområdet er mer oppløst og virker mer finkornet. Bassen er som tidligere deilig dyp og velartikulert med smekk og moro akkurat som jeg liker det . Gleder meg til m2Tech two er på plass. Nå er jeg veldig usikker på hvor mye begrensninger HagUSB legger på opplevelsen.

 

[marsboer]

Jeg tok en liten kortvarig sammenligning mellom nrpacks 1 og 8 i går, og her hos meg synes jeg subjektivt sett at det låt kornete og "digitalt" med nrpacks 1. Med standardverdien på 8 låt det finkornet flytende og organisk igjen. Jeg kommer derfor ikke til å bruke noe særlig mer tid på denne parameteren i mitt anlegg når default viser seg å være kurant hos meg.

 

[marsboer]

Lytterapport fra test av siste MPD iso fra Man. Nå begynner dette å lukte gull Har en meget habil vinyl referanse som jeg bruker for å sammenligne digitalkilden med. Med siste versjon MPD er de største forbedringene slik jeg hører dem fra mellomtone og oppover. Nå er det mye mindre "digitalis", mellomtonen virker mer organisk med mer smekk. Som jeg har påpekt tidligere var det litt vel stramt i dette området med tidligere versjoner. Diskantområdet er mer oppløst og virker mer finkornet. Bassen er som tidligere deilig dyp og velartikulert med smekk og moro akkurat som jeg liker det . Gleder meg til m2Tech two er på plass. Nå er jeg veldig usikker på hvor mye begrensninger HagUSB legger på opplevelsen.

Hmm etter å skrevet mitt eget innlegg angående nrpacks leste jeg dette, og beskrivelsene er jo merkelig sammenfallende..
Det er vel ikke tilfeldigvis nrpacks som er økt fra 1 til noe annet i den nye Man-ISOen?

 

[gut_man]

Regner med Man svarer for hva som er gjort av endringer i denne siste versjonen. Morro når uavhengige lytteinntrykk sammenfaller! Har brukt noen timer på lytting siden jeg skrev lytterapporten og dette er blitt j..lig bra kort og godt! Nå mangler jeg bare ny software fra dCS som støtter native dsd fra pc og en iso som da upsampler til dsd.. Mens jeg venter blir nok neste skritt en sånn liten Intel sak som ble nevt tidligere.

 

[nma]

Morsomt at du også hører dette, til tross for et helt annet oppsett. nrpacks er fortsatt 1. (Du ser dette i oppstarten)
Målet var å beholde de gode egenskapene og luke ut de negative. Iogmed noe utvilsomt ble bedre (massivt lydbilde/bass) mens noe ble dårligere, gikk logikken min ut på at det tydeligvis er noe blir trigget ved lavere nrpacks som fører til en negativ endring i lyden, og å prøve å omgå dette istedet for å ta til takke med nrpacks=8. Jeg skal dog ta en siste sammenligning mellom 1 og 8 før jeg konkluderer, men jeg hører ikke noe til kornetheten ved å bruke 1 lengre.

 

[marsboer]

Har du lyst til å si noe om hva du eventuelt gjorde?

 

[gut_man]

Update; Har nå fått testet en del mot vinylriggen min. Konklusjon er at det fremeles er litt igjen til den ekstreme oppløsningen jeg har i mellomtone og diskantområdet med VdH Grashopper og Kuzma armen min. Smekket er der, og oppløsningen er ikke påfallende dårlig på noe vis, men når jeg sammenligner direkte mangler noe av stjernedrysset helt i toppen samt noe av den vanvittig varmt oppløste mellomtonen som arm/pu komboen nevnt klarer å gjengi.. Kan godt være at dette skyldes den noe utdaterte HagUSB. Skal gi videre tilbakemeldinger når M2tech er på plass! Når du får tid Man, hadde det vært morsomt å teste den innstillingen som marsboer foretrekker på 8 for å høre hva den gjorde her.

 

[nma]

Har du lyst til å si noe om hva du eventuelt gjorde?

Mpd og endel prosesser den bruker på egen core. Bufferverdier, disabling av hyper threading og turboboost (tror ikke de siste gjør så mye fra eller til). @Gutman : jeg tror m2tech vil gi deg bedre lyd. Dens asynkrone virkemåte med dedikerte klokkekrystaller er på papiret helt overlegen. Du vil også med letthet høre forskjell på hirez kontra cdkvalitet (pass på det er samme mastering) du må nok opp på dette for at det skal kunne matche eller overgå en topp vinylrigg. Jeg skal teste litt videre når jeg får tid til det uti neste uke.

En ulempe hos deg er jo at du bruker USB-disker. Iogmed USB-diskene bruker samme Interrupt som USB-DAC'en. Jeg vet ikke hva det har å si på lydkvaliteten (og det er ikke sikkert det har noe å si) Men jeg vil gjette på at en NAS vil være en fordel på sikt.

 

[Oblivion]

Har installert et Atom hovedkort med debian Wheezy 64bit RT kjerne etter marsboers wiki.
CuBox blir nå installert med debian Wheezy med modifisert 3.5 kernel...
En av modifiseringene av kernel er at SPDIF kan kjøre 192kHz med eksternt generert "audio fil" klokking.
Derfor er det kanskje mulig å få til galvanisk isolert og "audio fil" re-klokking av SPDIF og kanskje også I2S.

For de som ikke trenger høyere samplerate enn 192kHz så vil denne løsningen kunne spille bedre enn å bruke USB....

Driver nå og undersøker om det også lar seg gjøre å bruke begge I2S / SPDIF utgangene i CuBox og dermed kunne sende data som dual mono slik som dCs har gjort og kanskje gjør fortsatt.
Hvis dette skulle vise seg å være mulig så vil også 352.8k/384k/DSD128 fungere direkte med en modifisert CuBox uten å bruke USB.

På CuBox blir det nå to forskjellige kernel som en kan velge mellom.
En kernel hvor grafikk ikke blir aktivert (headless) og hvor all RAM blir tilgjengelig for MPD - kun SSH eller konsol via USB.
Den andre kernel har grafikk aktivert og kan kjøre X - 1080p og video avspilling er da mulig, men da med mindre RAM til MPD og også litt redusert audio ytelse..

Meningen er å sammenligne Atom med RT kernel etc. med CuBox med modifisert kernel og hardware..
Hvis I2S / SPDIF "oppgraderingene" lar seg realisere tror jeg CuBox har potensiale

 

[marsboer]

Apropos RAM-bruk på mpd. Jeg har prøvd å utnytte RAMen jeg har tilgjengelig litt bedre ved å gi mpd langt mer audio_buffer. Et slags klønete forsåk på å få til noe tilnærmet 100% buffering av låter.

Jeg får ikke mpd til å starte med større "audio_buffer_size" enn 128 MB, eller helt nøyaktig 128 * 1024 - 1 KiB = 131071. Jeg får dermed ikke mpd til å bruke særlig av de 8 GB jeg faktisk har til rådighet.
Med så store størrelser på bufferet bør man også senke buffer_before_play fra default "10%" til f.eks "1%". Dette virket å fungere ypperlig med umiddelbar oppstart av låtene og full funksjonalitet forøvrig. Men det viser seg at det å søke i sanger nå blir tregt og uforutsigbart, så jeg valgte å gå tilbake til default. Det er vel ikke uten grunn at det står at du bør vite hva du driver med før du justerer audio_buffer_size...

Jeg misforsto forresten betydningen av buffer_before_play først. Jeg trodde verdien anga hvor mange % av låten som skulle buffres før start, men det er ikke det verdien betyr. Den angir hvor mange prosent av audio_buffer som skal fylles opp før låten startes. Med standardverdiene vil det si at 10% av 2048 KiB skal fylles opp. Hvis man derfor benytter 10% ved 128 MiB buffer, vil man måtte vente lengre tid enn nødvendig på oppstart av låter. Uansett så er buffringen gjerne over på det første sekundet av låten bare bufferet er stort nok og kilden er normalt rask via f.eks gigabit nett og en oppegående NAS, i hvertfall slik mpd opererer. Det gir derfor liten mening å vente på å buffre store mengder data før start av avspilling.

Jeg ser imidlertid at det ligger som en relativt nyopprettet request på bug-trackeren til mpd for å få ekte 100% buffring av låter ved avspilling. Det er ikke et stort behov for min del, men jeg har nå uansett så mye RAM i systemet. En ordentlig implementasjon blir bedre enn å tukle med audio_bufferet, da jeg antar at det er langt bedre å først kopiere låten i minnet for deretter å ha et relativt lite audio buffer for rask reaksjon på operasjoner ved avspilling av filen (søking, oppstart, pause osv)

 

[Oblivion]

Buffer er en ting..
MPD kan cache spillelisten så langt du har RAM i maskinen.
Det vil si at etterhvert som du spiller så blir data liggende i RAM.
Spiller du på nytt en tidligere avspillt melodi så skjer det fra RAM.

Så at Wheezy som standard bare installerer "gammel" MPD versjon og at når jeg prøvde å avinstallere ALSA / OSS for å få fjernet alt rusk så chrashet Wheezy....
Mulig at Unetbootin laster ned feil image...
Installerer uansett på nytt fordi Grub ble installert feil (debian har alltid for meg vært full av idiotiske bug)..

Grub sier at siden det bare er installert et OS så er det trygt å installere -ha-ha
Problemet var bare at Grub ble installert på USB minnepinnen som jeg startet netinstall med -ha-ha

 

[marsboer]

Mener du at man kan cache en playlist i forkant av avspilling, eller kun at tidligere avspilt data ligger i RAM?
Hvordan aktiverer man dette? Fant ingenting på nett.

 

[jangri]

Har noen av dere prøvd å kjøre Voyage MPD i en virtuell maskin via Hyper-V i windows 2008?
Det første problemet som oppsto når jeg skulle prøve var at det ikke er noen mulighet for å "route" USB-device (denne adaptersaken) fra den fysiske maskinens usb-inngang og videre til den virtuelle maskinen. Så det er jo ganske meningsløst å sette igang med dette før jeg klarer å mounte USB inn på hyper-v

 

[marsboer]

I følge dokumentasjonen støtter Hyper-V kun mounting av USB lagringsenheter, og ingen andre typer USB enheter. Det ser ikke ut som om Hyper-V kan dele lydkortet med Windows-maskinen i bunn heller, som jo kunne vært et alternativ.

Uansett en suboptimal løsning, og ting som real time kernel gir ingen mening når maskinen kjører virtuelt. Men som en ren funksjonalitetstest så er det jo greit.

VMware har imidlertid denne funksjonaliteten. Muligens VirtualBox også.

 

[Oblivion]

Mener du at man kan cache en playlist i forkant av avspilling, eller kun at tidligere avspilt data ligger i RAM?
Hvordan aktiverer man dette? Fant ingenting på nett.

Kun tidligere avspillt.
Det virker både i mpdPUP og i en spesial kompliert / oppsatt MPD versjon som jeg har brukt (0.17.xx).
Men både mpdPUP og de andre MPD installasjonene ble fjernet når jeg installerte Wheezy...

 

[marsboer]

Ok. Det er i grunnen ikke så interessant om mpd cacher allerede avspilte låter med min typiske bruk.

 

[Oblivion]

Ok. Det er i grunnen ikke så interessant om mpd cacher allerede avspilte låter med min typiske bruk.

Si ikke det..
Jeg har spillelister og lar MPD stå og spille kontinuerlig slik at når har tid til å sitte en time eller to og lytte så har hele spillelisten kommet i cache og da spilles det jeg vil høre på fra RAM.

Når jeg nå begynner å bruke ARM med kun 1GB RAM så mister jeg det meste av cache funksjonen.
Men buffer vil fortsatt virke og jeg skal få testet om om spilling fra SATA (SSD) eller NAS gir best resultat.

 

[marsboer]

Hehe, du er tydeligvis mer hardcore enn meg

Info for de som eventuelt benytter seg av Wiki-oppsettet mitt:
Jeg har lagt til fasiliteter for å enkelt teste CPU affinity i scriptet mitt: http://www.marsboer.net/shared/hifi-linux/hifi.sh
CPU-affinity vil sjekkes ved den regelmessige kjøringen med -u siden CPU-affinity resettes hver gang mpd starter.
Jeg har ikke testet om jeg hører noen forskjell enda. Personlig tror jeg egentlig at Linux-kernelen har bedre forutsetninger for å vurdere hvor en tråd best kjøres enn jeg har, men jeg observerer jo at trådene bytter CPU hele tiden, så det kan jo hende dette påvirker.

Man kan forøvrig ikke benytte seg av de kommandoene som finnes på nett for CPU affinity konfigurasjon siden disse baserer seg på "$(pidof mpd)"-kommandoer som ikke får med seg undertrådene til mpd. Det er derfor litt morsomt at de samtidig skriver at de får lydforbedringer, når trådene mpd benytter seg av for å gjøre faktisk arbeid ikke er påvirket. Dette ser man enkelt om man kjører:

ps -eLo pid,lwp,cls,rtprio,pri,nice,psr,cmd | grep mpd

hvor psr-kolonnen da viser CPU affinity for trådene

Dvs at den typiske kommandoen man ser rundt omkring, taskset -c -p <CPU ID> $(pidof mpd), ikke gjør noe av reell betydning
Typisk lurt av at standardvisningen i top ikke viser undertråder tenker jeg..

Si fra hvis det er noen optimaliseringsparametre som ønskes, så kan jeg vurdere å legge dem inn, om ikke annet enn for egen testings skyld.

 

[nma]

Dvs at den typiske kommandoen man ser rundt omkring, taskset -c -p <CPU ID> $(pidof mpd), ikke gjør noe av reell betydning
Typisk lurt av at standardvisningen i top ikke viser undertråder tenker jeg..

Er klar over dette

 

[Oblivion]

@marsboer:
Har nå installert etter din wiki på i5 systemet (Med Atom ble det bug i alle rettninger)..
NFS4 fungerte ikke mot Netgear Pro Business med siste oppgraderinger så jeg måtte koble opp med cifs..
MPoD / MPaD ser ikke MPD og en må inn med IP addressen og manuell konfigurering.
Oppdaterer du wiki slik at automatisk tilkobling virker (for de som ikke har brukt MPD så blir det mye enklere, eventuellt også med statisk IP).
På mitt system var det IRQ 18 som USB kortet brukte på USB 2.0 port og IRQ 41 på USB 3.0 port.
En må reboote for at NRPACKS skal bli endret.
En får feilmelding på scriptet: SCALING - no such file or directory..

Den MPD versjonen som blir installert hvis en følger wiki er 0.16.7 ifølge MPD,
men når jeg installerer MPC (for å kunne kontrollere MPD fra konsoll) så rapporteres det at MPD er versjon 0.16.0.
Uansett må en opp på MPD versjon 0.17.1 for å få med seg full native DSD støtte - minimum 0.17.0...
Så det neste nå blir å oppgradere til 0.17.1 for min del,
og da fjerner jeg også alle lydformatene med data tap..
Slik mpd.conf er satt opp for ALSA (format "44100:16:2") så blir vel alt resamplet til 44.1k/16bit... Jeg kommenterer ut format, mixer_device, mixer_control og mixer_index slik du viser i din wiki - dette er lett å glemme...
I tillegg vil det på MPD 0.17.1 være flere parametre som må settes riktig for at native DSD skal fungere (alternativt DSD til PCM konvertering for de som ikke har DSD kompatibelt USB kort / DAC).

EDIT: Har sjekket prosessene og USB er definitivt værstingen..
2.7% til 8.3% CPU forbruk avhengig av prioritet, NRPACKS, USB port og USB kort...

Med WaveIO USB -> I2S:

	USB2RT	USB2STD	USB3RT	USB3STD
NRPACKS 1	2.7-3.3%	3-5.3%	8-8.3%	7.6-8.3%
NRPACKS 8	3-3.3%	3-5.3%	8-8.3%	7.6-8.3%
NRPACKS 20	4.6-5.6%	3-3.3%	7.3-7.6%	7.3-8.3%

Med QNKTC 1.1 USB -> Analog:

	USB2RT	USB2STD	USB3RT	USB3STD
NRPACKS 1	2.7-3.3%	4.3-5.6%	5-5.3%	5-5.6%
NRPACKS 8	3-3.3%	4.3-6.3%	5-5.3%	5-5.3%
NRPACKS 20	4.6-5.3%	4.3-5.3%	5%	4.6-5%

Det er USB CPU tid i %
USB2RT = USB 2.0 port med RT kernel
USB2STD = USB 2.0 port med standard kernel
USB3RT = USB 3.0 port med RT kernel
USB3STD = USB 3.0 port med standard kernel

Slik jeg ser det "MÅ" USB kjøres via USB 2.0 port i RT modus (prioritet 99),
og NRPACKS = 1 (eller under 8) gir det jevneste CPU forbruket på ca. 3% konstant.

MPD prosessene bør også kjøres med prioritet 99 (RT modus) selv om MPD bruker minimalt med CPU (når en IKKE resampler - noe en IKKE bør finne på å gjøre pga lyd kvaliteten).

Disse betraktningene er gjort med et WaveIO XMOS USB kort, QNKTC 1.1 USB 2.0 og samplerate på 44.1k/16bit.
Skal etterhvert prøve med flere USB kort og sjekke forskjellene i ressurs forbruk..
Det er rimelig sikkert at det er USB driver / USB port / USB kort som er det som er det svakeste leddet.
Skal også sjekke om USB isolering har noen innvirkning.
Og få kompilert en kernel som støtter NRPACKS verdier som er høyere - dette fordi flere har rapportert at NRPACKS rundt 100 er det som spiller best... Da må dette sjekkes ut både lydmessig og datamessige på MPD systemet.

Det er jo nettopp USB koden i kernel som jeg har sett på som veldig lite optimal...
Og USB kernel koden er nettopp lite optimal fordi det er lagt inn korreksjoner for veldig mange dårlige USB kort implementasjoner.
Så skal det jobbes for virkelig god lyd med et USB grensesnitt i bruk så blir det her fokuset må være.
Det blir spennende å koble opp flere USB kort og se de tekniske forskjellene i linux..

Har IKKE hørt på resultatet ennå fordi at før det tekniske er evaluert og optimalt er det ingen vits å kaste bort tiden på å "lytte" etter forskjeller.
Med CPU forbruk som varierer fra underkanten av 3% til nesten 9% avhengig av fysisk port på PC og på USB kort og på valg av NRPACKS og prioritet så er det langt igjen før det er optimalt...

Av de to USB "kortene" jeg nå har sjekket er det QNKTC 1.1 som er mest stabil i forhold til både RT eller standard kjerne og USB 2.0 eller USB 3.0 port og NRPACKS settingen.
Da er det rimelig å anta at det er enklest å få QNKTC 1.1 til å fungere optimalt av disse to.

Legger også merke til at RT kernel og USB 2.0 port gir best resultat ved lave NRPACKS,
men at standard kernel med USB 2.0 port og både RT kernel og standard kernel med USB 3.0 gir best resultat med NRPACKS på 20...
Derfor må det testes hva som skjer med NRPACKS høyere enn 20.
Voyage MPD, mpdPUP og de fleste andre "pakkeløsningene" for MPD kjører stort sett 32bit og standard kernel og det er for disse at det er rapportert at NRPACKS på 100 spiller best...

 

[marsboer]

NFS4 fungerte ikke mot Netgear Pro Business med siste oppgraderinger så jeg måtte koble opp med cifs..

Jeg benytter NFSv4 i mitt nett, som er siste versjon og denne støttes sannsynligvis ikke av NASen din. Sannsynligvis fungerer NFSv3 og tidligere (bare bruk "nfs" i fstab) fint på de fleste NAS-løsninger, gitt at NFS-exports er satt opp på NAS.
Om du har en løsning som fungerer med CIFS så kan du jo også fortsette å bruke denne.

MPoD / MPaD ser ikke MPD og en må inn med IP addressen og manuell konfigurering.

Dette er nevnt som en forutsetning. Det vil si at jeg tildeler fast adresse via DHCP-serveren i nettverket mitt. For ordens skyld har jeg imidlertid nå oppdatert wikien med hvordan man setter en fast IP-adresse på serveren manuelt.

Oppdaterer du wiki slik at automatisk tilkobling virker (for de som ikke har brukt MPD så blir det mye enklere, eventuellt også med statisk IP).

Jeg regner med at dette er enkelt å få til så jeg kan se hva jeg kan gjøre. I mitt nett er ikke dette en aktuell problemstilling siden WLAN-klienter (m.a.o iPad 2 med MPaD) uansett ikke er på samme LAN som mpd-serveren og autodeteksjon fungerer dermed ikke uansett. Det er derfor dette ikke er tatt med.

En må reboote for at NRPACKS skal bli endret.

Ikke om du bruker mitt script. Scriptet sjekker om nrpacks er endret i forhold til faktisk satt verdi. Er den det vil scriptet unloade usb-snd-audio modulen og laste den inn på nytt med nrpacks satt. Du vil imidlertid få feilmelding om f.eks mpd benytter lydkortet, og dermed også usb-snd-audio modulen, så sørg for å stoppe avspilling før du endrer nrpacks. Hvis prosessen tryner fordi modulen er låst vil den gamle verdien fremdeles bli stående, så scriptet vil da forsøke på nytt neste gang det eksekveres.
Etter at modulen er lastet på nytt med ny nrpacks-verdi legger det også til config for sysctl slik at parameteren lastes automatisk ved neste oppstart så man slipper at modulen lastes ut og inn igjen ved første gangs script eksekvering etter hver boot.

En får feilmelding på scriptet: SCALING - no such file or directory..

Dette er mystisk. SCALING er det aller første i scriptet som ikke er kommentert ut (#) og er bare første del av en variabel. Her lukter det egentlig at det har skjedd noe rart tegnmessig med scriptet eller at f.eks #!/bin/bash ikke er korrekt på toppen.

Jeg anbefaler at du benytter wget-metoden beskrevet på wikien for å hente ned scriptet, for deretter å kjøre det i sin originale form bare for å teste.
Jeg har forøvrig oppdatert scriptet slik at det nå er "dash safe". Dvs at det trygt kan kjøres med "sh /scripts/hifi.sh", i tillegg til "bash /scripts/hifi.sh" og bare "/scripts/hifi.sh"

 

[Oblivion]

Brukte wget fordi jeg da slapp å skrive alt inn på nytt.
Så det var ditt umodifiserte script jeg testet med.
Stoppet ikke avspilling så da var det årsaken til NRPACKS ikke endret seg.
Skal teste det oppdaterte scriptet.
Uansett er både wiki og script allerede veldig flotte hjelpemiddel for de som vil prøve MPD

 

[marsboer]

Da har jeg slengt opp litt mer på Wikien. Dette går ikke på mpd spesielt, men er egentlig et slags tillegg for de som måtte ønske det. Det dreier seg hovedsaklig om litt enkel feilsøking, samt installasjon av GUI og Spotify for de som ønsker at boksen gjør noe mer enn kun å fungere som mpd-server.

 

[marsboer]

Da har jeg gjort litt finlytting på anlegget, med verifisering med Sennheiser HD 800 for å prøve å minimere eventuelle romintegrasjonsmessige fordeler/ulemper som drar i favør den ene eller andre retningen, samtidig som HD 800 jo også er et ekstremt bra detaljanalyseverktøy uansett.
Jeg vil bare understreke at dette er mine ekstremt ikke-beviste 100% subjektive konklusjoner på nåværende tidspunkt, som i tillegg med stor sannsynlighet er systemavhengig. Jeg har prøvd etter beste evne å legge ingeniøren "marsboer" bort under lyttingen, og ikke tenke ut liksom-plausible forklaringsmodeller for at jeg opplever det ene eller andre, men dette er selvsagt en tilnærmet umulig oppgave siden jeg trossalt er den jeg er.

- Den største forskjellen opplever jeg alltid ved å gå fra generic til rt-kernel, uavhengig av om threadirqs er påslått for generic eller ei. _Men_ jeg begynte som smått å endre ståsted angående bruk av rt-kernelen her om dagen, og dette bekreftet seg bare ytterligere etter mye frem og tilbake med HD 800 nå i kveld. Jeg opplever definitivt at det låter mere "friskt" med rt-kernelen. Generic fremstår rett og slett som marginalt matt i forhold. Men etter nærmere sammenligning og lytting på musikk av ulike sjangere får jeg en definitiv følelse av at det hele rett og slett låter "tynnere" med rt-kernelen. Dessverre uten at jeg får følelse av mer presisjon. Jeg får en definitiv følelse av at det hele låter slankere og mere skjørt. Det vil si mindre flytende og organisk, og mer nesten på tippen til "digitalt". Nøye lytting med HD 800 gjorde at jeg fikk en enda sterkere følelse av dette. Mere "luft" oppover ble byttet mot mindre romlig størrelse i mellomtoneområdet og den lille varmen som gir det viktige touchet av organisk liv. Jeg føler derfor at rt-kernelen har en helt klar signatur, som jeg ikke er helt sikker på at er mer riktig, siden jeg vanligvis forbinder høyere oppløsning og en bedre signalkjede med forbedringer over hele fjøla, ikke med klare kompromisser i forhold til alternativet.
Er det mitt anlegg som ikke "kler" rt-kernelen, eller er det rett og slett en eller annen stressfaktor jeg opplever? Rent opplevd lydmessig får jeg mest følelsen av det siste.

- CPU affinity på mpd føler jeg er den parameteren som gir nest mest effekt. Og da alltid til det bedre med CPU affinity på. Det låter like organisk som før, men med mer presisjon. Det vil si hakket mer presis i bassområdet, og stemmer låter enda litt mer ekte. Dette er en forbedring som oppleves slik jeg vanligvis opplever reelle forbedringer.

- NRPACKS mener jeg også å høre forskjell på. NRPACKS=1 gir et ørlitegrann strammere lydbilde, men jeg opplever at det låter litt mer grovkornet. Jeg synes imidlertid at NRPACKS=1 låter bedre på generic (med threadirqs) vs nrpacks 8, enn den gjør på rt, hvor jeg føler det låter i overkant stresset.

Prioritetene har jeg ikke gått gjennom nøye enda. Men når jeg slår av all prioritet så låter det såpass marginalt dårligere at jeg mistenker at systemet mitt har så mye headroom at effekten av disse parametrene ikke slår til i fullt monn.
Threadirqs, og dermed egen prioritet på IRQ-tråden til USB-huben lydkortet er tilkoblet, føler jeg likevel får det hele til å låte marginalt mer finkornet enn å ha threadirqs deaktivert på kernelen.

En gledelig nyhet er at jeg ikke greier å høre et fnugg forskjell med scaling governor ondemand vs performance på min CPU. Om dette skyldes at CPUen er såpass kraftig i forhold til oppgaven den er gitt, slik at den ikke trenger å bytte klokkefrekvens underveis, eller om det er asynkron USB som slår til vites ikke. Uansett gir dette en bonus i form av strømsparing, og dermed mindre varmeutvikling, på systemet.

For å oppsummere så finner jeg foreløpig at parametrene under låter mest finkornet ekte, organisk og presist med min MPD-server. Dog mindre "forskjellig" fra et out-of-the-box oppsett (i hvertfall min box ) enn en variant med rt-kernelen og full pupp på en del andre parametre:

# The scaling governor used to control CPU throttling
SCALING_GOVERNOR="ondemand"

# The name of the USB audio interface IRQ thread
USB_IRQ_THREAD="irq/23-ehci_hcd"

# The priority of USB_IRQ_THREAD
PRI_IRQ=99

# The priority of mpd and its threads
PRI_MPD=80

# The CPU to put the mpd process and its threads on. Leave unset to disable.
# Note that you should restart mpd if you decide to turn this off after having
# set the affinity. Alternatively you can run the command "taskset -a -p f $(pidof mpd)"
MPD_CPU_AFFINITY=2

# Control how aggressively Linux will swap memory to disk.
# Lower values means less swapping.
SWAPPINESS=10

# Select snd-usb-audio nrpacks interval in ms
NRPACKS=8

Kernel: Debians generic 3.2-3 kernel med "threadirqs" aktivert.

 

[Oblivion]

Er det mitt anlegg som ikke "kler" rt-kernelen, eller er det rett og slett en eller annen stressfaktor jeg opplever? Rent opplevd lydmessig får jeg mest følelsen av det siste.

Jeg tror det er "støy" effekten av rt-kernel du hører.
Da mener jeg strømforsyning / jord støy som introduseres når CPU jobber.

Hvis du oppgraderer alle spennings punktene i PCen vil du høre en klar forbedring.
Med den strømforsyningen du nå bruker er dette en enkel prosedyre fordi du har alle spenningene og jord tilgjengelig i kablene...
Du får "sortere" bakgrunn og mer "organisk" lyd og langt bedre "klang" og vesentlig redusert "stress".
Alle settingene MÅ vurderes på nytt etter at strømforsyning er oppgradert.
Dette er noe du har mulighet til å prøve ut umiddelbart

Det siste som har like stor eller faktisk større positive effekt er galvanisk isolering av USB tilkoblingen mellom PC og "lydkort".
Her finnes det kun noen optiske løsninger for USB 2.0 Audio som jeg ikke vet hvordan de påvirker lyd kvaliteten fordi disse introduserer mye elektronikk i begge ender som ikke er laget med lyd som formål.
Utenom disse optiske løsningene vet jeg kun om min egen måte for å isolere USB audio 2.0.

Jeg kommer til å lage noen USB 2.0 Audio -> I2S kort med galvanisk isolering som det blir mulig å få prøvd.

Men det alternativet som kan bli det enkleste og lydmessig bedre enn å bruke uisolert USB er CuBox løsningen som jeg driver å tester ut nå.
Der skal det være mulig å koble (kernel 3.5.xx) til ekstern lav jitter klokke til ARM chip / integrert "lydkort", og med I2S er det veldig enkelt å få til en galvanisk isolering.
En bruker DAC master klokken som en sender isolert til ARM, ARM sender I2S data og klokker tilbake isolert, deretter blir data og klokker re-klokket direkte med DAC master klokke. Jeg bruker noen custom bygde 1ps jitter klokker som jeg er meget fornøyd med.

Har begynt å jobbe med CuBox løsningen og her hadde jeg virkelig trengt hjelp av noen med sort belte i linux