Side 1 av 4 123 ... SisteSiste
Resultater 1 til 20 av 65
Abonnér på denne tråden
  1. #1
    Oblivion
    Guest

    ARM (CPU) MPD musikk server

    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.c...3-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).
    Siste redigert av Oblivion; 06.08.2012 kl. 17:06.

  2. #2
    Hifi-entusiast
    Ble medlem
    Sep 2010
    Innlegg
    248
    Tagget i
    0 Innlegg
    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!

  3. #3
    Hifi Freak marsboer's Avatar
    Ble medlem
    Apr 2010
    Sted
    Akershus
    Innlegg
    3,673
    Tagget i
    0 Innlegg
    Sitat Sitat fra Oblivion Se Innlegg
    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?

  4. #4
    Oblivion
    Guest
    Sitat Sitat fra Goophy Se Innlegg
    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.

  5. #5
    Oblivion
    Guest
    Sitat Sitat fra marsboer Se Innlegg
    Sitat Sitat fra Oblivion Se Innlegg
    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

  6. #6
    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.

  7. #7
    Hifi Freak marsboer's Avatar
    Ble medlem
    Apr 2010
    Sted
    Akershus
    Innlegg
    3,673
    Tagget i
    0 Innlegg
    Sitat Sitat fra Oblivion Se Innlegg
    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.

  8. #8
    Oblivion
    Guest
    Sitat Sitat fra marsboer Se Innlegg
    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

  9. #9
    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.
    Siste redigert av Oblivion; 07.08.2012 kl. 08:36.

  10. #10
    Oblivion
    Guest
    Navn:      CuBox.jpg
Visninger: 533
Størrelse: 51.3 Kb
    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..

  11. #11
    Hifi Freak
    Ble medlem
    Dec 2003
    Innlegg
    4,431
    Tagget i
    1 Innlegg
    Dette er en fin MPD-box..kommer Mars 2013: OUYA: A New Kind of Video Game Console by OUYA — Kickstarter

  12. #12
    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...

    Navn:      SPDIF44.jpg
Visninger: 452
Størrelse: 35.6 Kb

    Navn:      SPDIF176.jpg
Visninger: 493
Størrelse: 37.4 Kb

    Fortsatt mye tweaking og kompilering / konfigurering før alt er optimalt, men det går da framover

  13. #13
    Hifi-entusiast
    Ble medlem
    Sep 2010
    Innlegg
    248
    Tagget i
    0 Innlegg
    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å.

  14. #14
    Oblivion
    Guest
    Sitat Sitat fra Goophy Se Innlegg
    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...

  15. #15
    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

    Navn:      top1.jpg
Visninger: 472
Størrelse: 108.4 Kb

    Navn:      top2.jpg
Visninger: 456
Størrelse: 108.9 Kb

    Navn:      top3.jpg
Visninger: 474
Størrelse: 109.3 Kb

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

  16. #16
    Hifi Freak marsboer's Avatar
    Ble medlem
    Apr 2010
    Sted
    Akershus
    Innlegg
    3,673
    Tagget i
    0 Innlegg
    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.
    Siste redigert av marsboer; 11.08.2012 kl. 01:50.

  17. #17
    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...

  18. #18
    Hifi-entusiast
    Ble medlem
    Sep 2010
    Innlegg
    248
    Tagget i
    0 Innlegg
    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:
    static inline void kirkwood_set_rate(struct kirkwood_dma_data* priv,
                                         unsigned long rate)
    {
            if (rate == 44100 || rate == 48000 || rate == 96000) {
                    /* use internal dco for supported rates */
                    printk (">>> %s :: dco set rate = %lu\n",
                            __FUNCTION__, rate);
                    kirkwood_set_dco(priv->io, rate);
                    writel(KIRKWOOD_MCLK_SOURCE_DCO,
                           priv->io+KIRKWOOD_CLOCKS_CTRL);
            } else if (!IS_ERR(priv->extclk)) {
                    /* use optional external clk for other rates */
                    printk (">>> %s :: extclk set rate = %lu -> %lu\n",
                            __FUNCTION__, rate, 256*rate);
                    clk_set_rate(priv->extclk, 256*rate);
                    writel(KIRKWOOD_MCLK_SOURCE_EXTCLK,
                           priv->io+KIRKWOOD_CLOCKS_CTRL);
            }
    }
    

  19. #19
    Oblivion
    Guest
    Sitat Sitat fra Goophy Se Innlegg
    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:
    static inline void kirkwood_set_rate(struct kirkwood_dma_data* priv,
                                         unsigned long rate)
    {
            if (rate == 44100 || rate == 48000 || rate == 96000) {
                    /* use internal dco for supported rates */
                    printk (">>> %s :: dco set rate = %lu\n",
                            __FUNCTION__, rate);
                    kirkwood_set_dco(priv->io, rate);
                    writel(KIRKWOOD_MCLK_SOURCE_DCO,
                           priv->io+KIRKWOOD_CLOCKS_CTRL);
            } else if (!IS_ERR(priv->extclk)) {
                    /* use optional external clk for other rates */
                    printk (">>> %s :: extclk set rate = %lu -> %lu\n",
                            __FUNCTION__, rate, 256*rate);
                    clk_set_rate(priv->extclk, 256*rate);
                    writel(KIRKWOOD_MCLK_SOURCE_EXTCLK,
                           priv->io+KIRKWOOD_CLOCKS_CTRL);
            }
    }
    
    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.

  20. #20
    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.
    Siste redigert av Oblivion; 11.08.2012 kl. 18:30.

Side 1 av 4 123 ... SisteSiste

Tags for denne Tråden

Skrive Tillatelser

  • Du kan ikke starte nye tråder
  • Du kan ikke svare på innlegg
  • Du kan ikke laste opp vedlegg
  • Du kan ikke redigere dine innlegg
  •  


 

Om Hifisentralen

    Hifisentralen er Norges største webside innen high-end hi-fi og musikk, og vi har vært på nett siden år 2001. Velkommen til en god hi-fi diskusjon eller kjøp og salg av utstyr.
   

Følg oss på sosiale medier:

Facebook Twitter RSS Feed