ARM (CPU) MPD musikk server

Diskusjonstråd Se tråd i gallerivisning

  • O

    Oblivion

    Guest
    Har anskaffet en CuBox (ARM CPU) som skal settes opp til en linux MPD musikk server.
    Denne tråden vil bli brukt til å dokumentere de hardware og software endringer som blir implementert for å få denne til å yte optimalt.

    Foreløpig vil jeg ikke gi en "kjøps anbefaling" av CuBox fordi den må testes og utprøves,
    og det er nå flere andre tilsvarende (med samme prossesor) produkter å få kjøpt som kanskje er bedre til dette bruket.

    Derfor heter tråden ARM (CPU) MPD musikk server og ikke CuBox MPD musikk server.

    Link til CuBox: http://www.solid-run.com/products/cubox
    Link til alternativer: http://www.globalscaletechnologies.com/p-53-d2-plug.aspx

    Det blir litt "ruskete" til å begynne med fordi de planene jeg har for denne ARM baserte MPD musikk serveren trenger en linux kjerne med en source kode 3.5+....

    Årsaken er at det er integrert to I2S / SPDIF "lydkort" i ARM chipen og at det i 3.5+ kjerne er inkludert støtte for å klokke disse lydkortene med en eksterne audio kvalitet klokker.
    Normalt bruker "PC" baserte "lydkort" de standard klokker som er tilgjengelig og med frekvenser som ikke matcher noen samplerate, og hvis de gjør det så er det 48/96/192kHz som klokka passer til.
    Derfor er 44.1k "syntetisk" fordi det brukes feil klokke og resultatet er ikke bra.
    88.2k og 176.4k er ofte ikke støttet eller så dårlige at de ikke bør / kan brukes.

    CD basert musikk som de aller fleste bruker har en samplerate på 44.1k og DSD bruker også den samme klokke frekvens familien.
    Årsaken til at "PC" baserte "lydkort" bruker klokker som matcher 48/96/192k er på grunn av at det er film disse er tiltenkt brukt til og ikke hi-fi audio...

    Den implementerte 3.5+ kjerne støtten med ekstern klokking gjør at også 176.4k og 192k samplerater vil fungere,
    og mest sannsynlig også native DSD64.

    Fordi at det er to "lydkort" integrert er det også en sjanse for at en kan greie å få brukt begge i en dual mono konfigurasjon.
    Da vil en kunne greie også 352.8k/384k og native DSD128.

    Hvis en skriver om source koden for MPD og tweaker til DAC løsningen er kanskje også native DSD256 mulig å få til å fungere.

    Denne bruken av de interne I2S utgangene med kernel støtte kobles via en galvanisk isolator til DAC,
    og klokkes (I2S hardwaren i ARM) fra DACens masterklokke.
    Dette bør spille (dramatisk) mye bedre enn USB basert og standard "PC" lydkort basert avspilling.

    Avhengig av hva som er gjort på hovedkortet (CuBox) så kan en også bruke separate linære spennings regulatorer ikke bare til lyd delen i ARM, men også for grafikk, nettverk, pll, core, etc.. etc..

    For å få alt 100% optimalt må en nok lage et eget hovedkort,
    og da kan en også øke RAM til 2GB og gjøre mange forbedringer.

    Med debian wheezy kan en på CuBox kjøre netinstall for å teste med standard versjoner,
    og en kan også oppgradere til 3.4 eller 3.5 ferdig kompilerte kjerner og kompilere MPD 0.17.1 eller 0.18.git (fungerte heller dårlig)..

    Første runde blir å få en fungerene CuBox med både USB lydkort og I2S / SPDIF utgang.
    Andre runde blir å optimalisere hardware og eventuellt bygge om det som trengs for å få ekstern kvalitets klokking.
    Tredje runde blir å kompilere kjerne og MPD med kun de funksjoner / moduler / bibliotek en MÅ ha for at det fortsatt fungerer.
    Fjerde runde blir å sette opp nettboot fra NAS slik at når en slår på CuBox så booter den fra NAS.
    Fordelen med dette er at CuBox da trenges å kobles opp bare en gang med USB kabel til PC/Mac i konsoll modus og settes opp til nettboot (også NFS boot støttes).
     
    Sist redigert:

    Goophy

    Hi-Fi entusiast
    Ble medlem
    10.09.2010
    Innlegg
    248
    Antall liker
    21
    Torget vurderinger
    4
    Slik jeg forsto det etter å ha snakket litt med en som jobbet for Solid-Run var I2S kun integrert i chipen for HDMI-lyd og var ikke mulig å nå utenfra.
    Har du sett om det er noen tilgjengelige I2S-headere e.l. på selve kretskortet?

    Forøvrig kjempeflott at du starter en slik tråd! :)
     

    marsboer

    Hi-Fi freak
    Ble medlem
    04.04.2010
    Innlegg
    3.748
    Antall liker
    760
    Sted
    Akershus
    Dette bør spille (dramatisk) mye bedre enn USB basert og standard "PC" lydkort basert avspilling.
    Jeg lurer på hvorfor dette vil være tilfelle? Vettuge asynkrone USB og/eller firewire-løsninger har jo helt marginalt med jitter i dag. Jeg tviler selvsagt ikke på at jitterverdiene vil bli enda lavere med et oppsett ala det du skisserer, men jeg er ikke helt overbevist om at dette nødvendigvis resulterer i en merkbar lydmessig gevinst i seg selv når utgangspunktet allerede er så bra. Eller er det totalen under ett som vi gi gevinsten? Det vil si at f.eks oppsampling til høyere enn tradisjonelt støttede bitrater for å unngå filtrering også er en viktig brikke?
     
    O

    Oblivion

    Guest
    Slik jeg forsto det etter å ha snakket litt med en som jobbet for Solid-Run var I2S kun integrert i chipen for HDMI-lyd og var ikke mulig å nå utenfra.
    Har du sett om det er noen tilgjengelige I2S-headere e.l. på selve kretskortet?

    Forøvrig kjempeflott at du starter en slik tråd! :)
    I følge han som har laget kernel koden for ekstern klokking er hardwaren koblet slik at audio0 er koblet til HDMI og audio1 er koblet til den optiske SPDIF utgangen...
    Selve printet har jeg ikke sett nøye på ennå fordi jeg har studert datablad og innhentet informasjoner,
    men jeg skal på med "lupe" brillene og studere kretskortet snart.

    I første omgang blir det nok den ene I2S / SPDIF utgang som en får til å fungere (audio1).
    Men det er en header på kortet (mellom hovedkort og I/O kort) som jeg håper at noen av signalene er rutet til og lettere å få tak på.
    Hvis det ikke hadde vært fysisk mulig å koble til ekstern "audio fil" klokke så hadde nok ikke kernel source koden blitt oppdatert for dette for CuBox...

    Som sagt så er det ikke umulig at jeg senere lager et eget kretskort hvor begge I2S utgangene blir koblet optimalt,
    en egen 32bit (plus kontroll signaler) bus for å sende lyddata klokket med word klokke til min egen DAC som har en slik inngang.
    Dette med en hardware FIFO mellom slik at ARM kan jobbe optimalt med å fylle FIFO og DAC kan jobbe optimalt med lave jitter klokker.
    Kontroll signalene vll være samplerate, bit dybde, PCM / DSD info til DAC og selvfølgelig FIFO kontroll.
    Men dette blir ikke realisert før det meste er testet og funnet godt nok.
     
    O

    Oblivion

    Guest
    Dette bør spille (dramatisk) mye bedre enn USB basert og standard "PC" lydkort basert avspilling.
    Jeg lurer på hvorfor dette vil være tilfelle? Vettuge asynkrone USB og/eller firewire-løsninger har jo helt marginalt med jitter i dag. Jeg tviler selvsagt ikke på at jitterverdiene vil bli enda lavere med et oppsett ala det du skisserer, men jeg er ikke helt overbevist om at dette nødvendigvis resulterer i en merkbar lydmessig gevinst i seg selv når utgangspunktet allerede er så bra. Eller er det totalen under ett som vi gi gevinsten? Det vil si at f.eks oppsampling til høyere enn tradisjonelt støttede bitrater for å unngå filtrering også er en viktig brikke?
    Hvis en får implementert de forskjellige linære spennings regulatorene,
    og fjernet så og si all kernel og MPD kode som en ikke trenger regner jeg med at det blir en bedring.
    Høyere bitrater enn normalt vil også være et bidrag til forbedring.
    Den diskrete DACen jeg jobber med er en NOF DAC (No Oversampling Filter) :)
    Tiden vil vise om 44.1k/16 er godt nok eller om en må høyere opp,
    men jeg regner med at ytelse / lydkvalitet ikke blir dårligere enn på de 16bit NOS/NOF DACene som jeg brukte på 80 tallet :)
     
    O

    Oblivion

    Guest
    Hadde tenkt å prøve en debian wheezy netinstall etter marsboers wiki (med noen få steg i begynnelsen som blir forskjellige) i dag,
    men oppdaget at USB konsoll kontakten på CuBox var av en mindre type enn det jeg hadde liggende...

    Deretter installerer jeg en 3.5.x kjerne for å sjekke ut hvordan det fungerer..
    Og så en 0.17.1 versjon av MPD.

    På Intel i5 har jeg laget 4 primær partisjoner fordi jeg trenger en maskin med minimum 3.4.x kjerne (har de som har prøvd rapportert) for å krysskompilere når en skal bruke en 3.5.x kjerne på ARM.

    En partisjon med fungerende linux 64bit RT MPD, en partisjon for test og utprøving av nye Intel 64bit kjerner og MPD,
    en partisjon for krysskompilering etc. til ARM og den siste partisjonen med siste utgave (også 3.2.xx kjerne) av linux Mint (ubuntu).

    Linux Mint er den eneste installasjonen med desktop og med Gparted, grafisk Grub editor etc..
    Installerte linux Mint først, opprettet og formaterte alle de andre partisjonene, installerte de andre linux variantene etterpå uten å formatere eller å installere Grub (debian netinstall gjør dette uansett feil (installerer Grub til USB og ikke mSATA) når en har bootet fra USB og installert til mSATA).
    Når en booter linux Mint og kjører en Grub oppdatering blir boot menyen for maskinen riktig (med riktig kernel versjoner) og en har et "kontroll senter" som fungerer.

    For å ha sagt det - jeg har prøvde alt for mange linux varianter og desktop varianter i leting etter noe som både er stabilt, fungerer bra og hvor en kan rette opp og tweake andre linux variant installasjoner som det har "krøllet" seg for.
     

    marsboer

    Hi-Fi freak
    Ble medlem
    04.04.2010
    Innlegg
    3.748
    Antall liker
    760
    Sted
    Akershus
    For å ha sagt det - jeg har prøvde alt for mange linux varianter og desktop varianter i leting etter noe som både er stabilt, fungerer bra og hvor en kan rette opp og tweake andre linux variant installasjoner som det har "krøllet" seg for.
    Jeg kan legge til litt under "troubleshooting" i Wikien for flere av tingene du har opplevd som faktisk har enkle løsninger.
    - Installasjon av en minimal variant av Gnome3 på Wheezy dersom du skulle ønske dette etter å ha installert en minimal mpd variant fra netinst uten fullt desktop miljø som installerer alt mellom himmel og jord av applikasjoner
    - Enkelt fikse grub via CLI dersom denne av ymse årsaker skulle havne på USB-minnepinnen og ikke på disken du ønkser
    - Hvordan du kan laste ned nyere versjoner av pakker fra Debian Unstable selv om du kjører Debian Wheezy. Her ligger mpd 0.17.1 allerede ferdig med dependencies, slik at du i praksis bare kan apt-get'e den ned for kjapp testing før siste finpuss med en nedskrelt egenkompilert variant.
     
    O

    Oblivion

    Guest
    Enkelt fikse grub via CLI dersom denne av ymse årsaker skulle havne på USB-minnepinnen og ikke på disken du ønkser
    debian netinstall er et enkelt problem, men hvis en har prøvd å installer Voyage MPD og en del av de andre distroene så kjører de sitt eget "løp" og tar ikke på noen måte hensyn til at det kan være andre partisjoner eller OS på disken.
    Derfor har det vært greit å ha et fungerende "backup/rescue" alternativ.

    Wikien blir bedre og bedre :)
     
    O

    Oblivion

    Guest
    USB -> I2S adapter basert på en ARM prossesor er snart ferdig som prototype.
    Det er Amanero Technologies ved Domenico Vellante (tidligere M2Tech) som har utviklet grunnproduktet http://amanero.com/
    Firmwaren til dette produktet har blitt endret etter mine spesifikasjoner.
    Det meste av firmware endringene vil nok være / bli tilgjengelige i standard produktet fra Domenico,
    men automatisk galvanisk USB isolering blir bare implementert i min versjon og two´s complement format & LSB correction med mer blir vel også unikt. I utgangs punktet var det ikke implementert volum kontroll etc. fra OS / remote control app eller styring av DAC med I2C kommandoer. Dette har nå blitt implementert slik at at de forskjellige "eventer" kan sende I2C kommandoer, og disse I2C kommandoene kan konfigureres etter behov og tilpasses den DAC som tilkobles.
    Til forskjell fra standard produktet (i tillegg til firmware) blir min versjon galvanisk isolert på USB siden og kortet må forsynes med en egen 5 volt strømforsyning, den integrerte buck converteren i ARM chip blir erstattet med en diskret JFET regulator, alle andre regulatorer blir også erstattet med JFET regulatorer, det er implementert en master clock modul (2 stk 1ps jitter klokker) slik at DAC klokkes synkront med korrekt (44.1/48k familie og 1, 1/2, 1/4 og 1/8 av master klokkene slik at de fleste DAC chiper han brukes) frekvens, det blir to USB 2.0 innganger (en standard ekstern og en intern tenkt brukt mot CuBox etc.), med ES9018 DAC tilkoblet blir DAC omprogrammert til SPDIF inngang hvis ikke noen av USB inngangene er aktive (enumerert) (dette er et bi-produkt av USB isolerings kontroll rutinene)...

    Det skal bli spennede å teste denne ARM MPD -> USB 2.0 -> ARM -> I2S konfigurasjonen mot direkte koblet I2S fra ARM MPD avspilleren til DAC.
    Med ES9018 baserte DACer og min egen diskrete DAC i tankene får dette USB -> I2S kortet også I2C kontroll av DAC i tillegg til at MPoD / MPaD og OSX remote etc. kan styre volum kontroll via I2C kommandoer til DAC.
    Men også andre DAC chiper kan brukes da I2C kommandoene enkelt kan konfigureres (adresse, register, verdier etc.) pr. event, og det blir også mute og DSD enable logiske signaler til DAC.

    Skulle det spille bedre å gå via USB drivere -> USB hardware -> USB kabel -> USB hardware -> ARM prossesor -> CPLD enn direkte koblet "riktig klokket" I2S så blir jeg forundret..

    Men for andre kilder enn en modifisert ARM basert MPD avspiller er nok USB 2.0 det beste alternativet.
     
    Sist redigert:
    O

    Oblivion

    Guest
    CuBox.jpg

    Da var CuBox oppe med 3.5.0-rc5 kernel...
    I headless utgave slik at grafikk ikke er initiert og all RAM er tilgjengelig for MPD.

    Nå skal MPD kompileres i en 0.18 versjon..
     
    • Liker
    Reaksjoner: H.R
    O

    Oblivion

    Guest
    Har installert CuBox med wheezy på nytt med manuell debootstrap og konfigurering...
    MPD og MPoD / MPaD fungerer og jeg har fått begynt å teste litt praktisk :)
    Fortsatt 3.5.0-rc PREMPT kernel.

    Parametre fra den innebygde SPDIF utgangen ved avspilling av 44.1k/16bit og 176.4k/24bit
    viser at "extclk" nå blir enablet med samplerate over 96k...

    SPDIF44.jpg


    SPDIF176.jpg


    Fortsatt mye tweaking og kompilering / konfigurering før alt er optimalt, men det går da framover
     
    • Liker
    Reaksjoner: H.R

    Goophy

    Hi-Fi entusiast
    Ble medlem
    10.09.2010
    Innlegg
    248
    Antall liker
    21
    Torget vurderinger
    4
    Er lydmodulen stabil med samplerate på over 96kHz via SPDIF?
    Leste at enkelte hadde en del problemer med det, dog litt annen hardware.

    Hvis den faktisk er det er det jo nesten likegreit å bare bruke den innebygde. Fantastisk!
    Håper jeg får min snart, begynner å bli utolmodig nå.
     
    O

    Oblivion

    Guest
    Er lydmodulen stabil med samplerate på over 96kHz via SPDIF?
    Leste at enkelte hadde en del problemer med det, dog litt annen hardware.

    Hvis den faktisk er det er det jo nesten likegreit å bare bruke den innebygde. Fantastisk!
    Håper jeg får min snart, begynner å bli utolmodig nå.
    Eneste årsak til at jeg "gidder" å sjekke ut den innebygde I2S / SPDIF hardwaren i CuBox er det faktum at det er en ekstern klokke inngang som i kernel 3.5.0-rc.xxxxx er enablet og tillater I2S og SPDIF med riktig klokke frekvens og med lavt jitter.
    Det tar kanskje noen revisjoner av kernel source koden før dette er perfekt, og kanskje noe hardware tweak, men potensialet er der.

    "Alle" (alt er relativt og her betyr "alle" de jeg har sjekket ut) andre PC baserte I2S og SPDIF løsninger er alt for dårlige til å legge noe arbeid i... Noen er så "hårreisende" elendige at de nesten ikke kan beskrives...
     
    O

    Oblivion

    Guest
    Det er ikke lett å få "top" via USB konsoll til å oppføre seg bra,
    men her er tre skjerm dump som viser at med den innebygde (kernel tweaket) I2S / SPDIF utgangen og MPD som spiller 44.1k/16bit så er ARM CPUen totalt på tomgang :)
    Og den høye CPU belastningen som Intel platform med USB "lydkort" gir ikke har noen tilsvarende tendenser her :)

    top1.jpg


    top2.jpg


    top3.jpg


    Så langt overgår CuBox med RT kernel og minimums oppsett alle forventninger :)
    NB! RT prioritetene etc. er ikke satt opp riktig ennå...
     

    marsboer

    Hi-Fi freak
    Ble medlem
    04.04.2010
    Innlegg
    3.748
    Antall liker
    760
    Sted
    Akershus
    Jeg leste en del i standarddokumentene for USB Audio Class 2.0 og USB 2.0 standarden her om dagen. I tillegg undersøkte jeg ganske mye for å finne ut nøyaktig hvordan asynkron usb fungerer på standardnivå, i den hensikt å finne ut hva som er en fornuftig fremgangsmåte for å optimalisere dette i Linux. Her kom det frem at USB i seg selv overlater svært mye til hosten og at måten USB er lagt opp til å fungere i seg selv er CPU-intensivt. Hensikten bak den kompliserte og tildels krevende host-implementasjonen er at enhetene man skal koble til kan lages vesentlig enklere. Dette i seg selv er en logisk og fornuftig tilnærming. Det medfører også at USB sannsynligvis ikke er det optimale om man ønsker å minimere CPU-bruk.
     
    Sist redigert:
    O

    Oblivion

    Guest
    Har nå studert kernel source koden for den innebygde I2S / SPDIF enheten..
    Og kontaktet SolidRun (CuBox) med noen spørsmål om hvordan jeg får "tak" i de signalene jeg trenger,
    og om det er noen GPIO eller I2C utgang en kan bruke / få tilgang til.

    Den innebygde SPDIF enheten fungerer med den nåværende kernel source koden (3.5.0-rc) slik:
    44.1k, 48k og 96k bruker intern klokke, 176.4k og 192k bruker ekstern klokke, og 88.2k er ikke støttet.

    Det er ikke vanskelig å få alle samplerater til å fungere, men for 44.1k og 88.2k vil det med intern klokke bli dårligere og dårligere kvalitet med høyere samplerater.

    Med ekstern "audio fil" klokke vil alle samplerater fungere utmerket.

    Et klokke modul som kan gi ut de 8 klokke frekvensene (8 og ikke 6 fordi det ser ut til at source koden har 384k som maksimal verdi og da er det ikke helt umulig at 352.8k og 384k vil kunne fungere via I2S) trenger å bli styrt fra kernel source koden slik at riktig ekstern klokke blir brukt.
    Det er her en må finne en måte (GPIO, I2C eller lignende) som kernel source koden kan bruke til å styre klokke modulen.

    Klokke modulen vil i tilfelle fungere som følger:
    1. Master klokke frekvenser på 90/98M eller 45/45M eller 22/24M eller 11/12M til DAC for synkron klokking vil være valgbart slik at de fleste DAC chiper kan brukes.
    2. En synkront ned klokket Master klokke blir sendt til CuBox lydkort og er galvanisk skilt.
    3. CuBox lydkort sender I2S signaler tilbake over det galvaniske skillet og blir re-klokket med høy hastighets Flip-Flopper og levert til DAC med ekstremt lavt jitter og uten jord eller strømforsynings støy fra CuBox.
    4. Klokke modulen blir styrt fra CuBox (kernel RT kode) via galvanisk skillt I2C eller GPIO signaler.

    Hvis en får til dette vil lyd kvaliteten med MPD spiller bli noe av det beste som er teknisk mulig å oppnå.
    Også ALSA driver, nettverks kort driver, SATA driver ligger i kernel og kan optimaliseres.
    USB driver kan også ligge i kernel, men den ville jeg enten ha disablet eller kun konfigurert for masselager (USB disk, USB minne pinne) og lagt i en ekstern modul.

    Selv om det er I2S jeg ser som det optimale vil SPDIF optisk fungere optimalt, og SPDIF med RCA eller BNC er enkelt å inkludere (ren hardware).

    Uansett om CuBox brukes slik den er med kernel 3.5.0-rc eller nyere bør den optiske SPDIF utgangen gi like bra eller bedre lydkvalitet enn USB lydkort for 44.1k, 48k, 96k, 176.4k og 192k (må sjekkes om den optiske senderen henger med) samplerater.
    En får galvanisk skille og kraftig redusert CPU forbruk som vil forbedre lydkvaliteten i forhold til USB...
     

    Goophy

    Hi-Fi entusiast
    Ble medlem
    10.09.2010
    Innlegg
    248
    Antall liker
    21
    Torget vurderinger
    4
    Ser ikke veldig vrient ut å bruke ekstern klokke på alle samplerates.
    44,1, 48 og 96 er satt statisk i kirkwood-i2s.c

    Tittet bare kjapt gjennom og det ser ut som man kan la alle samplerates gå utenom DCO uten problemer.
    Bare la alt kjøres via clk_set_rate istedet.

    Kode:
    [COLOR=#000000][FONT=arial]static inline void kirkwood_set_rate(struct kirkwood_dma_data* priv,[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                                     unsigned long rate)[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]{[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]        if (rate == 44100 || rate == 48000 || rate == 96000) {[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                /* use internal dco for supported rates */[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                printk (">>> %s :: dco set rate = %lu\n",[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                        __FUNCTION__, rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                kirkwood_set_dco(priv->io, rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                writel(KIRKWOOD_MCLK_SOURCE_DCO,[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                       priv->io+KIRKWOOD_CLOCKS_CTRL);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]        } else if (!IS_ERR(priv->extclk)) {[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                /* use optional external clk for other rates */[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                printk (">>> %s :: extclk set rate = %lu -> %lu\n",[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                        __FUNCTION__, rate, 256*rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                clk_set_rate(priv->extclk, 256*rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                writel(KIRKWOOD_MCLK_SOURCE_EXTCLK,[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                       priv->io+KIRKWOOD_CLOCKS_CTRL);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]        }[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]}
    [/FONT][/COLOR]
     
    O

    Oblivion

    Guest
    Ser ikke veldig vrient ut å bruke ekstern klokke på alle samplerates.
    44,1, 48 og 96 er satt statisk i kirkwood-i2s.c

    Tittet bare kjapt gjennom og det ser ut som man kan la alle samplerates gå utenom DCO uten problemer.
    Bare la alt kjøres via clk_set_rate istedet.

    Kode:
    [COLOR=#000000][FONT=arial]static inline void kirkwood_set_rate(struct kirkwood_dma_data* priv,[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                                     unsigned long rate)[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]{[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]        if (rate == 44100 || rate == 48000 || rate == 96000) {[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                /* use internal dco for supported rates */[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                printk (">>> %s :: dco set rate = %lu\n",[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                        __FUNCTION__, rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                kirkwood_set_dco(priv->io, rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                writel(KIRKWOOD_MCLK_SOURCE_DCO,[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                       priv->io+KIRKWOOD_CLOCKS_CTRL);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]        } else if (!IS_ERR(priv->extclk)) {[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                /* use optional external clk for other rates */[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                printk (">>> %s :: extclk set rate = %lu -> %lu\n",[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                        __FUNCTION__, rate, 256*rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                clk_set_rate(priv->extclk, 256*rate);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                writel(KIRKWOOD_MCLK_SOURCE_EXTCLK,[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]                       priv->io+KIRKWOOD_CLOCKS_CTRL);[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]        }[/FONT][/COLOR]
    [COLOR=#000000][FONT=arial]}
    [/FONT][/COLOR]
    Har sett det - og det vil være det enkleste og raskeste, men.....

    Vi kan programmere om en kernel til å bruke extclk på alle samplerater og så sjekke ut om det fungerer brukbart.
    Hvis det fungerer brukbart trenger en bare å få til et galvanisk skille på I2S og så re-klokke med DAC master klokke med flip-flopper på DAC siden av det galvaniske skillet.

    For SPDIF er det for optisk allerede optimalt.
    For å få ut RCA / BNC trengs en 75ohms driver og en puls transformator og da er det også optimalt.
     
    O

    Oblivion

    Guest
    Begynner å få orden på debian wheezy 3.5.0-rc RT kernel og MPD...

    Slik oppsettet er nå er totalt CPU forbruk ved å spille ut på SPDIF med 44.1k/16bit ca. 1 til 1.5% og 176.4k/24bit ca. 5 til 6%.
    Av dette står MPD for ca. halvparten og system prosesser for resten.

    Hittil har jeg kun testet innebygd SPDIF som kernel driveren gir ALSA støtte slik at jeg ikke har hatt behov for å installere ALSA...

    Men nå skal jeg teste ut to - tre USB -> I2S enheter og da må jeg installere ALSA...

    Derfor kan en senere installere en veldig "minimums" installasjon med full funksjon hvis en kun skal bruke SPDIF / I2S utgangen.
     
    Sist redigert:
    O

    Oblivion

    Guest
    Hmmm...

    Fikk problemer med å få USB -> I2S enhetene til å fungere og det tok litt tid før jeg fant ut av det :)
    Fordi dette er et egen bygd minimums oppsett hadde jeg "glemt" å kopiere inn kernel modulene til /lib/modules og USB var ikke kompilert inn i kernel. En "tar" kommando og kernel moduler var på plass og USB -> I2S enhetene fungerte.

    Når jeg har funnet ut av hva som er det minste minimum som trengs for å fungere som en 100% funksjonerende MPD server regner jeg med at kernel blir kompilert slik at det ikke trengs noen separate moduler.

    Med USB -> I2S enheter er totalt CPU forbruk så likt med å bruke den innebygde SPDIF / I2S enheten at jeg ikke kan kvantifisere noen forskjell.

    Og med den kernel og ARM kompilering som jeg nå tester med så er det faktisk mye som ikke fungerer likt med de Intel versjonene Man og marsboer jobber med.
    IRQ - interrupt fungerer helt forskjellig.
    Selv om USB kortene bruker IRQ 24 eller 25 (avhengig av om det er USB bus 1 eller 2) så skjer det lite eller ingenting på disse IRQ, men kworker prosessene bruker CPU resursser og disse skalerer proporsjonalt med sampleraten MPD spiller av med.
    Og dette fungerer også likt for den innebygde SPDIF / I2S enheten og USB -> I2S enheten.

    Med NRPACKS = 1 eller 8 eller 20 er det ikke vesentlige forskjeller å se på CPU forbruket.

    Dette er både morro og frustrerende fordi kart og terreng er veldig forskjellig i forhold til Intel versjonene :)

    At en reboot nå er lynrask er en "enorm bonus" når en driver og tester og prøver ut forskjellige funksjoner og parametre.
     

    nma

    Hi-Fi freak
    Ble medlem
    07.12.2003
    Innlegg
    4.456
    Antall liker
    401
    Torget vurderinger
    1
    med realtime kernel, høy prioritet på USB, og med nrpacks=1 bruker USB mellom 2 og 3% av 1 core på min Intel. Tror jeg kan leve med dette. Du skriver at du bruker RT-kernel på ARM, men det gjør du vel strengt tatt ikke iogmed den ikke er ute for kernel 3.5 enda. Prøv dette først, sammen med høy prioritet, nrpacks=1, før du drar de endelige konklusjonene.
    Min erfaring er at relativt CPU-bruk har null å si for lydkvalitet når det er i denne størrelsesordenen. Jeg mener du henger deg opp i uvesentlige småting. Men det er nå meg.. =)
    ps. bruker jeg nrpacks=8 , bruker både MPD og USB mellom 0 og 1% på min Intel. Men det låter fortsatt bedre med nrpacks=1 og høyere CPU-bruk.
     
    O

    Oblivion

    Guest
    med realtime kernel, høy prioritet på USB, og med nrpacks=1 bruker USB mellom 2 og 3% av 1 core på min Intel. Tror jeg kan leve med dette. Du skriver at du bruker RT-kernel på ARM, men det gjør du vel strengt tatt ikke iogmed den ikke er ute for kernel 3.5 enda. Prøv dette først, sammen med høy prioritet, nrpacks=1, før du drar de endelige konklusjonene.
    Min erfaring er at relativt CPU-bruk har null å si for lydkvalitet når det er i denne størrelsesordenen. Jeg mener du henger deg opp i uvesentlige småting. Men det er nå meg.. =)
    ps. bruker jeg nrpacks=8 , bruker både MPD og USB mellom 0 og 1% på min Intel. Men det låter fortsatt bedre med nrpacks=1 og høyere CPU-bruk.
    Jeg forstår hva du mener...
    Det blir som med et digitalt filter - en må velge mellom vondt eller værre - og det blir en slags form for matching med resten av systemet...
    Ofte er det mest korrekte tilsynelatende ikke det beste fordi det avslører andre skavanker.

    Jeg regner ikke med at du har tatt deg bryet med å justere en millimeter eller tre på høyttalerne eller noen slik form for tilpassing mellom bytter av for eksempel NRPACKS :)
    Da vil jeg påstå at du ikke på noen måte kan dra noen endelig konklusjon - kun din private...

    Hvis du hadde tweaket til minimum CPU forbruk (er lik lavest støy og jitter) og optimert det akustiske til best mulig og deretter igjen tweaket til høyere CPU forbruk med mer støy og jitter - og fortsatt hatt den samme konklusjonen...

    Jeg har ikke hørt "en tone" med hverken Intel eller ARM basert MPD etter at jeg begynte å tweake.
    Dette er helt bevist fordi jeg vil ha tweaket programwaren og hardwaren til det optimale basert på helt konkrete tekniske årsaker.
    Når jeg er ferdig tweaket skal jeg starte og spille og justere anlegget - høyttaler plassering, lytteposisjon etc. til jeg får det mest optimale total resultatet.
    Deretter skal jeg teste ute de alternative - teknisk mindre gode programware settingene for å se om de har noe for seg.
    Med denne rekkefølgen slipper jeg å bli lurt av placebo og tidligere akustiske tweak som passet sammen med det jeg engang har hatt og brukt.


    Det er forresten godt gjort å bruke 0% for både MPD og USB når du spiller musikk - MPD sender ut "0" data selv når du ikke spiller aktivt.
    MPD må jo sende en kontinuerlig data strøm som USB må motta.
     

    nma

    Hi-Fi freak
    Ble medlem
    07.12.2003
    Innlegg
    4.456
    Antall liker
    401
    Torget vurderinger
    1
    Hehe.. jeg bruker jo ikke "0" da, som i absolutt ingen CPU, men det varierer mellom 0 og 1.
    Nei jeg justerer faktisk ikke en millimeter på høyttalerne. Jeg har allerede altfor store høyttalere til den lille stuen min =)
    Det er selfølgelig vanskelig å trekke universale konklusjoner, YMMV etc. Uansett, selv om lavest mulig CPU noe man skal tilstrebe, tror jeg ikke lavest mulig CPU er det samme som automatisk lavere jitter, om det går på bekostning av andre ting.
     
    O

    Oblivion

    Guest
    Har nå satt opp med tre output fra MPD.
    Den interne SPDIF utgangen, WaveIO USB -> I2S og QNKTC USB -> DAC.

    Fra MPC eller MPoD / MPaD kan en enable / disable disse utgangene, og spille på en eller flere samtidig.

    Hvis en ser på "top" og ser på totalt forbrukt CPU og forbrukt CPU for de forskjellige prosessene, når en spiller 44.1k/16bit, 176.4k/24bit, setter MPD på pause og sjekker CPU forbruket så er det tydelig at det må forskes mye mer på hva det er som forbruker CPU og hva som genererer IRQ I/O.

    Uansett (på ARM versjonen) hvilken utgang en spiller på så er det rimelig likt CPU forbruk, og det er kun "kworker" prosessene og ikke IRQ som forbruker CPU.

    Om en spiller på flere utganger samtidig så øker MPD CPU forbruket kun litt (med 44.1k/16bit ca. 0.3 - 0.5%) og "kworker" prosessene øker også helt minimalt i CPU forbruk....
    Dette indikerer at det IKKE er den enkelte utgang som trigger CPU forbruket, men at det er en eller annen "core" prosess som forbruker CPU.

    Det som er merkelig er at det på Intel platform er IRQ prosessene som får CPU forbruket, men på ARM platform "kworker" prosessene.
    Fordi intern SPDIF forbruker like mye / lite CPU som USB på ARM, og at total forbruket av CPU ikke øker nevneverdig når en spiller på både intern SPDIF og USB samtidig så er det ikke USB / SPDIF drivere som forbruker CPU.

    På ARM platform er CPU forbruket nesten identisk selv om en bruker NRPACKS 1 eller 20, men på Intel platform varierer CPU forbruket mellom 2.7% og 9% for IRQ avhengig av NRPACK setting, USB enhet og USB hardware port.
    På ARM kommer ikke CPU forbruket til sammenligning over 2% uansett NRPACK setting og om en spiller på flere utganger samtidig og spiller High-Rez 176.4k/24bit.

    Forskjellen er vel egentlig enda større fordi Intel systemets CPU kjerner kjører 1.6GHz og ARM kjerne 800MHz.
    Sett i perspektiv i forhold til klokkefrekvens og CPU % så blir Intels 2.7% - 9% å sammenligne med ARMs (2%) 1%..
    Da forbruker Intel 2.7 til 9 ganger mer CPU kraft for å spille av og holde styr på et USB kort når ARM spiller av på både SPDIF og USB og holder styr på begge enhetene....

    For min del tror jeg at "CuBox" / ARM har kommet for å bli og at mye av årsaken til at ARM fungerer så bra er at kernel / drivere er spesifikt kompilert for hardwaren i den "SoC" som er i bruk...

    EDIT: Tok en test og spilte på inten SPDIF utgang, WaveIO USB og QNKTC USB samtidig...
    Og tre utganger avspilt øker så og si ikke CPU forbruket og "kworker" CPU forbruket øker ikke...
    Legger ved "screen shot" av "top" og lydkortenes audio-parametre i realtime.


    3-out-data.jpg


    top-3-out.jpg
     
    O

    Oblivion

    Guest
    Har nå kun en problemstilling igjen å løse (tror jeg) før en kan begynne med fin tuning av systemet.

    Det er å få MPaD til å hente "cover art" fra NAS uten at jeg må kjøre en web server på MPD serveren.

    Av en eller annen grunn så får jeg ikke dette til å virke satt opp mot et Netgear Readynas Business Edition NAS med http enablet mot sharet som musikk biblioteket ligger på...

    Det er mulig at det kanskje er smartest å installere en webserver på MPD serveren og at det er /var/lib/mpd/music som blir delt ut...
    Dette fordi det under /var/lib/mpd/music kan bli mountet også musikk på USB enheter og SATA enheter, og fordi en også kan mounte mer enn et NAS share med musikk...

    Får tenke litt på dette og undersøke hvilken webserver som er den beste å bruke til dette enkle formålet..

    Noen input rundt dette hadde vært flott.

    EDIT: ser at jeg har et problem til som må jobbes med - og det er at den interne SPDIF utgangen ikke kjører mer enn 16bit..
    Får håpe at det ikke er en begrensning i hardware, men at det ligger i kernel coden som alikevel skal tweakes på..
     

    Goophy

    Hi-Fi entusiast
    Ble medlem
    10.09.2010
    Innlegg
    248
    Antall liker
    21
    Torget vurderinger
    4
    EDIT: ser at jeg har et problem til som må jobbes med - og det er at den interne SPDIF utgangen ikke kjører mer enn 16bit..
    Får håpe at det ikke er en begrensning i hardware, men at det ligger i kernel coden som alikevel skal tweakes på..
    Følgende er skrevet inn i driverene, så det ville vært rart om hardwaren ikke støttet det...

    #define KIRKWOOD_FORMATS \ (SNDRV_PCM_FMTBIT_S16_LE | \
    SNDRV_PCM_FMTBIT_S24_LE | \
    SNDRV_PCM_FMTBIT_S32_LE)
     

    nma

    Hi-Fi freak
    Ble medlem
    07.12.2003
    Innlegg
    4.456
    Antall liker
    401
    Torget vurderinger
    1
    kworker kan være alskens prosesser, og grunnen til økt CPU-forbruk kan like godt være at nettverksporten bruker mer cpu når du avspiller hi-rez. I en kraftig Intel-maskin har dette lite å si, men en 800mhz ARM er fantastisk treg i forhold. Det har neppe med at kernel er spesifikt kompilert for hardwaren. Hvorfor i all verden bruker du RT prioritet på disse?
     
    O

    Oblivion

    Guest
    EDIT: ser at jeg har et problem til som må jobbes med - og det er at den interne SPDIF utgangen ikke kjører mer enn 16bit..
    Får håpe at det ikke er en begrensning i hardware, men at det ligger i kernel coden som alikevel skal tweakes på..
    Følgende er skrevet inn i driverene, så det ville vært rart om hardwaren ikke støttet det...

    #define KIRKWOOD_FORMATS \ (SNDRV_PCM_FMTBIT_S16_LE | \
    SNDRV_PCM_FMTBIT_S24_LE | \
    SNDRV_PCM_FMTBIT_S32_LE)
    Ja - jeg hadde sett dette tidligere og ble forundret når jeg oppdaget at det kun var 16bit som kjøres.
    Har også testet med å kun bruke SPDIF utgangen, spille musikk som er 24 og 32bit og å spesifisere format til 24 og 32bit i mpd.conf uten at dette hjelper.
    Så det er nok noe i driverene som begrenser...


    Kode:
        [B]switch[/B] (params_format(params)) {
        [B]case[/B] SNDRV_PCM_FORMAT_S16_LE:
            i2s_value [B]|=[/B] KIRKWOOD_I2S_CTL_SIZE_16;
            value [B]|=[/B] KIRKWOOD_PLAYCTL_SIZE_16_C;
            [B]break[/B];
        [COLOR=#999988][I]/*[/I][/COLOR]
    [COLOR=#999988][I]     * doesn't work... S20_3LE != kirkwood 20bit format ?[/I][/COLOR]
    [COLOR=#999988][I]     *[/I][/COLOR]
    [COLOR=#999988][I]    case SNDRV_PCM_FORMAT_S20_3LE:[/I][/COLOR]
    [COLOR=#999988][I]        i2s_value |= KIRKWOOD_I2S_CTL_SIZE_20;[/I][/COLOR]
    [COLOR=#999988][I]        value |= KIRKWOOD_PLAYCTL_SIZE_20;[/I][/COLOR]
    [COLOR=#999988][I]        break;[/I][/COLOR]
    [COLOR=#999988][I]    */[/I][/COLOR]
        [B]case[/B] SNDRV_PCM_FORMAT_S24_LE:
            i2s_value [B]|=[/B] KIRKWOOD_I2S_CTL_SIZE_24;
            value [B]|=[/B] KIRKWOOD_PLAYCTL_SIZE_24;
            [B]break[/B];
        [B]case[/B] SNDRV_PCM_FORMAT_S32_LE:
            i2s_value [B]|=[/B] KIRKWOOD_I2S_CTL_SIZE_32;
            value [B]|=[/B] KIRKWOOD_PLAYCTL_SIZE_32;
            priv[B]->[/B]spdif [B]=[/B] [COLOR=#009999]0[/COLOR];
            [B]break[/B];
        [B]case[/B] SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE:
        [B]case[/B] SNDRV_PCM_FORMAT_IEC958_SUBFRAME_BE:
            [B]if[/B] (substream[B]->[/B]stream [B]==[/B] SNDRV_PCM_STREAM_CAPTURE)
                [B]return[/B] [B]-[/B]EINVAL;
            i2s_value [B]|=[/B] KIRKWOOD_I2S_CTL_SIZE_16;
            value [B]|=[/B] KIRKWOOD_PLAYCTL_SIZE_16_C;
            priv[B]->[/B]i2s [B]=[/B] [COLOR=#009999]0[/COLOR];
            priv[B]->[/B]iec958 [B]=[/B] [COLOR=#009999]1[/COLOR];
            [B]break[/B];
    Kan det være her "problemet" ligger ?
    At det ved SPDIF output blir hardcoded til 16bit..
     
    Sist redigert:
    O

    Oblivion

    Guest
    kworker kan være alskens prosesser, og grunnen til økt CPU-forbruk kan like godt være at nettverksporten bruker mer cpu når du avspiller hi-rez. I en kraftig Intel-maskin har dette lite å si, men en 800mhz ARM er fantastisk treg i forhold. Det har neppe med at kernel er spesifikt kompilert for hardwaren. Hvorfor i all verden bruker du RT prioritet på disse?
    RT prioritet gir en mye roligere prosessering og på ARM blir dette nok det samme som å gi USB IRQ RT prioritet.
    Det ser ut til at ARM / kernel 3.5.0-rc bruker "work que" / "kworker" / "worker" og ikke IRQ direkte mot USB lydkort etc..
    Du bør prøve ut en slik CuBox ARM løsning og se forskjellene...

    Her er det litt info om kworkers:
    https://raw.github.com/torvalds/linux/master/Documentation/workqueue.txt
     
    Sist redigert:
  • Laster inn…

Diskusjonstråd Se tråd i gallerivisning

  • Laster inn…
Topp Bunn