ARM (CPU) MPD musikk server

[Goophy]

Du kan jo prøve å diffe cubox sin .config og din. Ser du noen ekstra CONFIG_ARCH_-linjer er problemet løst.

Angående ekstern klokking: Ser ut som den støtten aldri har vært upstream i Linux. Det var noe cubox-utviklerene la til i sin egen kodestrøm.
Burde dog ikke være noe problem å bare patche inn den støtten i upstream-kjerne. Metodene som kalles er generiske.

 

[Oblivion]

Du kan jo prøve å diffe cubox sin .config og din. Ser du noen ekstra CONFIG_ARCH_-linjer er problemet løst.

Angående ekstern klokking: Ser ut som den støtten aldri har vært upstream i Linux. Det var noe cubox-utviklerene la til i sin egen kodestrøm.
Burde dog ikke være noe problem å bare patche inn den støtten i upstream-kjerne. Metodene som kalles er generiske.

Det startet med at SolidRun sin cubox_defconfig fil ga disse filmeldingene...
Og derfor er det vel noe "feil" i mitt oppsett..

Får vel starte i5 og krysskompilere der fordi jeg har observert ut på nettet at de feilmeldingene jeg får har opptrådt ofte ved nye versjoner...
Og ARM / armhf og 3.5.1 kernel er vel å strekke strikken i lengste laget kanskje...

 

[Oblivion]

Endelig er CuBox opp og går med egen kompilert 3.5.2 PREEMPT kernel.

Det viste seg at cubox_defconfig fil fra SolidRun ikke var "god" og lot seg ikke kompilere med kernel 3.5.0 eller 3.5.1 eller 3.5.2.
På i5 systemet med ubuntu Mint så tar det nå bare et par minutter å krysskompiler en kernel source til armhf.
Endte opp med å lage en totalt ny defconfig fil og jeg har fortsatt noen detaljer å sjekke ut før alt er helt på plass.
Første versjon av kernel er på 2.9MB med alle drivere er kompilert inn (ingen eksterne moduler).

Oppdaget at defconfig fil som jeg laget med 3.5.1 kernel blir automatisk forandret av 3.5.2 kernel source scriptene
Det er kanskje det som har skjedd med cubox_defconfig som var laget til release candidat 5 av 3.5.0 kernel.

Det må til litt "hacking" (manuell editering) av defconfig for å få all hardware til å fungere eller ikke fungere slik en ønsker - eller kanskje en må ha en editert .config for at scriptene ikke skal "rette" opp "hackingen".
Hvis en hadde akseptert at CuBox som kun har 1GB RAM lar grafikk ta 256/320MB av dette og en hadde godtatt at alle drivere for SoC lydkort hadde blitt kompilert inn for å få SPDIF / I2S utgangen til å fungere så hadde nok scriptene laget mindre "krøll".

Slik SolidRun´s cubox_defconfig var laget ble det også kompilert over 90MB (komprimert) med drivere som moduler (som en ikke har bruk for til en MPD server eller som NAS)..


USB 2.0 lydkort er designet med tanke på "feedback polling time typically 16ms" fra kernel og det er vel her NRPACKS kommer inn i bildet.
Hvis USB 2.0 lydkort er designet slik at 16ms er det optimale intervallet så burde NRPACKS vel optimalt tilpasses dette, men dette er basert på at USB 2.0 lydkortet får "the usb requested bandwidth" - får ikke USB 2.0 lydkortet tilstrekkelig båndvidde så vil dette påvirke ytelse og CPU forbruk.

På CuBox så er det to USB 2.0 porter som er separate med hver sin IRQ etc.
På Intel bokser er det ofte en USB hub eller to slik at ofte er de fleste USB 2.0 portene fysisk tilkoblet en IRQ og en risikerer at mus, tastatur, BT, USB disker / minnepinner, trådløst nettverk etc. sloss om båndbredde og generere interrupt på en og samme fysiske USB port...
Da er det nok kanskje best å bruke lave NRPACKS verdier.

Har fått endel spørsmål om endel av de "fancy spesifisert" ARM baserte systemene som nå selges er brukbare - og svaret er at de aller fleste IKKE er brukbare til en MPD server.
Dette fordi de aller fleste implementasjonene er USB baserte: Det vil si at USB går via en USB hub og på denne huben er det tilkoblet et 10/100Mbit nettverkskort, BT, trådløst nettverk, disker etc..
Så en "fancy" enhet som også hadde SATA docking - fin løsning hvor en kan ha musikk på SATA disker (SSD) og bytte etter behov..
Det som var problemet var at også denne SATA tilkoblingen gikk via USB huben - ikke noe problem rent funksjonsmessig, men ikke brukbart når en skal bruke USB 2.0 lydkort samtidig.

 

[BURMESTER BOB]

Fatter ikke hvordan du klarer å holde orden på og manøvrere innenfor alle disse begrepene; en annen stakkar har mer enn nok med å få de fire ledningene fra arm til pick-up riktig..

 

[Oblivion]

En liten status rapport før jeg har fått optimert oppsettet...

Med egen kompilert 3.5.2 kernel og egen kompilert MPD 0.18git for CuBox ARM får jeg nå resultater som er meget oppløftende

Det første som var oppløftende var at Da Vinci DAC USB 2.0 kortet som jeg venter på ny firmware til (fungerer på OSX og Windows) nå "nesten" fungerer - tidligere ga linux kun feilmeldinger og kortet kunne ikke brukes - nå fungerer det 99%.
Det vil si at det under spilling går i "pause" etter noen sekunder og må startes igjen med "play".
Den nye firmwaren trengs fortsatt, men det er gledelig at opprenskingen av kernel source koden hadde denne positive effekten.

Også USB kort slik som WaveIO som linux tidligere også ga feilmeldinger for ved oppstart, men fungerte blir nå sett av kernel uten feilmeldinger og blir for første gang (gjelder alle USB kort jeg nå har prøvd) rapportert av kernel med riktig navn og pid etc..

24bit kilder gjør at MPD forbruker mer CPU enn når kilden allerede er i 32bit format.
Dette har jeg "hørt" tidliger og det er positivt at dette nå kan direkte relateres til CPU forbruk - det jeg har "hørt" er at en 32bit kilde spiller bedre enn en 24bit kilde selv om det ikke er musikk data i de ekstra 8bit.

Det er et forbehold som jeg må ta med: Fordi jeg ikke har testet / prøvd med en standard kompilert 3.5.2 kernel så vet jeg ikke om de forbedringene jeg nå erfarer skyldes min "configurering" av 3.5.2 eller om det i 3.5.2 er gjort forbedringer som vil gitt tilsvarende gode resultater uten mine "tweak"...

 

[Oblivion]

Når USB tilkoblede lyd enheter nå fungerer like optimalt (CPU forbruk) som den innebygde SPDIF / I2S enheten i CuBox så kommer jeg til å fjerne støtten for denne innebygde enheten i denne versjonen av kernel og heller slanke og optimere kernel for USB...
Jeg fikk ikke den innebygde SPDIF / I2S enheten til å fungere slik jeg har konfigurert kernel

Og når @Goophy får sin CuBox så regner jeg med at han kompilerer en optimal kernel med denne innebygde SPDIF / I2S enheten med "extclk" støtte. Den innebygde SPDIF bør kunne spille (med "extclk" fungerende for alle samplerater) minst like bra som noen eksterne USB løsninger opp til 192k....

Nå skal jeg se nærmere på hardwaren i CuBox og begynne å tweake og se om jeg får til å koble I2S signalene ut av kortet.
Med I2S så ser det ut til at opp til 384k/32bit kanskje kan fungere fordi det i source koden er definert 384k som maksimum samplerate.
Men tiden vil vise hva som blir mulig med I2S og SPDIF...

Den kjølingen som CuBox har som standard gir en CPU temperatur på 60 grader og oppover...
Dette er det første jeg kommer til å se på og 40 grader eller lavere er målet...

 

[Oblivion]

Har begynt å verifisere funksjoner som jeg har kompilert inn i kernel og disker med Mac OSX Extended (journalført) kan mountes og leses (blir mounted som read-only).
Dette var en USB disk som jeg partisjonerte og formaterte på MacBook Air en tid tilbake og var tiltenkt brukt kun med OSX,
men at min linux installasjon nå kan lese stort sett alle partisjons metoder og stort sette alle partisjons formater, og skrive til de fleste med unntak av OSX så kan musikk bibliotek på disker som er partisjonert og formatert fra Windows, Linux og OSX kobles til direkte på USB og / eller SATA port og spilles av uten behov for konverteringer.

Siste versjon av ALSA er også kompilert inn og fungerer utmerket.

Selv MPD 0.18git fungere uten store problemer (testet med opp til tre samtidige lydkort etc..), men her har jeg rapportert to "bug" - et installasjons script bug og en "bug" med for høy CPU bruk når en spiller 24bit filer (spilling av 32bit bruker 20% mindre CPU).

Totalt sett er hele installsjonen stabil og bruker veldig lite ressurser og dette er den eneste installasjonen hvor MPoD og MPaD har fungert korrekt.
Også lokal coverart fungerer som det skal.

EDIT: Det viser seg at "bug" med for høy CPU bruk ved avspilling av 24bit filer skyldes at MPD bruker dobbelt så mye CPU på å dekode en 24bits fil som en 32bit, og at QNKTC 1.1 som jeg brukte når jeg spilte og kjørte "perf recorder" for å samle data forårsaker ekstra CPU forbruk fordi QNKTC 1.1 ikke støtter å ta imot 24bit data og MPD må konvertere til 32bit før data sendes.

Har vel nevnt dette tidligere i denne tråden eller i Voyage MPD tråden at jeg har hørt tydelig forskjell på å spille en fil som er upsamplet til henholdsvis 24bit og 32bit, og hvor 32bit definitivt har spilt bedre.
I begge tilfellene vil det være helt identiske I2S data som kommer frem til DAC - eneste forskjell er CPU forbruk og alternative metoder og hvor i prosessen dette skjer.
Å få bekreftet at det jeg har hørt og også observert teknisk har sin berettigelse er faktisk tilfredstillende...

 

[Oblivion]

Da var endelig CuBox oppe og gikk konfigurert slik jeg har hatt håp om å få til.
Men lett har det ikke vært og det blir en større jobb å oppgradere til nyere kernel, nyere MPD etc.. fordi jeg har måtte patche / editere i konfigurasjons skript og kode... Og noen "hack" for å få de siste detaljene slik som at MPoD / MPaD skulle finne MPD serveren automatisk på plass.. Denne funksjonen fungerte eller fungerte ikke helt avhengig hvilke moduler MPD ble kompilert med og løsningen ble å la avahi ta seg av dette og at MPD da kan kompileres helt etter ønske..

Når jeg får de USB adapterne jeg skal bruke opp og gå så kan jeg kompilerer de forskjellige variantene av bibliotek for MPD og sjekke den tekniske ytelsen og lyd kvalitet - alle varianter er nå kompilert og verifisert med de USB adapterne som nå fungerer.

Selv om jeg nå bruker en 3.5.2 kernel og har kompilert MPD 0.18git i mange variasjoner har det ikke vært et eneste heng eller crash..

 

[nma]

Det blir spennende å se hvordan dette vil spille i forhold til Intel-versjonen din. Uansett kommer dette i et veldig fint format til f.eks kontor/hyttebruk, om ikke annet

 

[Oblivion]

Mens Goophy venter på sin CuBox kjører jeg nå en 3.5.2 kernel med full CuBox støtte (grafikk, SPDIF med extclk etc..).
Dette er en standard kompilert kernel som også har en god del moduler,
men jeg skal nå se om jeg greier å patche 3.5.2 kernel source slik at de spesifikke CuBox forskjellene kommer med.
Hvis dette går greit kan jeg i første omgang redusere størrelse av kernel og bli kvitt modulene.
Deretter kan jeg / Goophy forandre source koden slik at SPDIF (I2S) bruker extclk på alle samplerater og få rettet opp "bug" i koden som gjør at SPDIF nå kun kjører i 16bit modus.
Med standard 3.5.2 kernel gikk RAM fullt etter tre melodier og CPU bruken var ca. det doble av min tweakede kernel.
Når RAM går fullt så virker ikke MPDs caching og det hentes stadig data fra NAS.
Med 176.4k/32bit filer så bruker nettverksdriverne 2 - 4% CPU slik oppsettet er uten optimalisering.
Hvor mye en kan få dette ned er ikke godt og si, men en eSATA SSD disk med musikk biblioteket som kjører DMA kan kanskje være en utmerket løsning.
Da har en den musikken som det er viktig at spiller optimalt på SSD og resten av biblioteket på NAS.
Da vil MPD skanne både NAS og SSD, og alt er tilgjengelig for avspiling.

EDIT: Patchingen tok 2 sekunder og jeg har nå kompilert noen varianter av 3.5.2 kernel med CuBox drivere.
Selve kernel vokser da med 1MB, men bruker ikke mer RAM enn tidligere kernel varianter uten CuBox drivere.

Ytelsen etter at jeg har konfigurert og kompilert er nå også identisk med tidligere kompilasjoner og minne forbruket til selve kernel er redusert med 73MB. Standard 125MB med MPD og resten lastet mot 52MB i tweaket versjon - MPD alene tar godt over 20MB av dette.

Tilgjengelig RAM for caching av spillelister er økt fra ca. 450MB til nesten 1GB (950MB)..

 

[Goophy]

Da har endelig min Cubox ankommet og ting blitt satt opp.

Var i utgangspunktet ute etter en greie med liten formfaktor og ingen vifter.
Cubox var det beste alternativet da det meste annet som hadde gigabit NIC var latterlig overkill.

Skrev om driveren til lydchipen så alle samplerates blir klokket eksternt i DACen ved bruk av SPDIF og lot ellers alt være rimelig standard.
Det fungerer ypperlig, med noen små unntak. 176KHz er maks samplerate og 24bit output fungerer visst ikke.

Funderer på om jeg bare skal beholde det slik eller om jeg skal bruke USB. Veldig greit med en boks mindre.

RT-kernel, prioritering og whatnot har jeg aldri klart å høre forskjell på, så det har jeg hoppet glatt over.
MPD bruker rundt 1% CPU og det er veldig få interrupts generelt.

 

[Oblivion]

Da har jeg fått jobbet såpass mye med USB og ALSA source koden at interrupt mengde / nivå kan styres for både USB tilknyttede enheter og for andre type hardware tilknyttede løsninger.

Millisekunder og microsekunder etc. er ikke involvert i det hele tatt i ALSA driverene og godt er det.
Det er det lavnivå code i USB som styrer med på egenhånd.

Så langt kan det optimeres for den enkelte fysiske ALSA enhet med en faktor på 15 - 30 ganger.
Og jeg har funnet ytterliger optimerings potensiale som vil kunne redusere CPU forbruket vesentlig for både MPD og USB / IRQ håndteringen.
Antall interrupter bør kunne reduseres ytterligere med en faktor på 2 til 4 - da er en på et reduksjons nivå på 30 - 120 ganger.

Forskjellen nå mot tidligere er at jeg nå vet hva og hvor kildene til det høye IRQ nivået og CPU forbruket ligger.

Med mitt ARM baserte USB -> I2S / DSD adapter som nå har den grunnleggende firmwaren på plass så er interrupt nivået allerede 15 ganger redusert (med identiske USB / ALSA settinger) i forhold til de andre USB 2.0 Audio adapterne jeg har testet.

ALSA device list:
  #0: Kirkwood S/PDIF
  #1: Luckit Luckit USB Audio 2.0 at usb-orion-ehci.0-1, high speed
  #2: ObliUSB 2.0 A r0.1 at usb-orion-ehci.1-1, high speed

Med neste firmware oppgradering bør en kunne nærme seg en reduksjon i CPU forbruk for MPD med 30 - 60% og ALSA / USB på 30 - 50 ganger.
Uansett blir det spennende å se om en får firmwaren korrekt og om USB / ALSA drivere og MPD utnytter de nye mulighetene / alternativene direkte.

usb 2-1: new high-speed USB device number 2 using orion-ehci
usb_audio: Warning! Unlikely big volume range (=32767), cval->res is probably wrong.
usb_audio: [10] FU [ObliUSB 2.0 A r0.1 Playback Volume] ch = 2, val = -32767/0/1
usb_audio: Warning! Unlikely big volume range (=32767), cval->res is probably wrong.
usb_audio: [10] FU [ObliUSB 2.0 A r0.1 Playback Volume] ch = 1, val = -32767/0/1

Første firmware versjon må debugges slik at alle funksjoner så langt blir funksjonelle...
Det blir full I2C styring av DAC (ES9018 og alle DAC som kan kontrolleres med I2C) inklusive volum fra MPoD / MPaD etc..
Med for eksempel en Buffalo II/III DAC vil en med fordel kunne fjerne firmware og klokke og la Buffalo blir styrt av ObliUSB.

 

[Oblivion]

@Goophy

Slik SPDIF driveren nå er kompilert med extclk og en kernel jeg har optimert ALSA settingene for denne og også endret DMA buffer størrelsene så blir det bare 12 - 13 interrupt i sekundet sammen med den MPD 0.18git kompileringen jeg nå bruker og de MPD settingene jeg bruker.
Er ikke sikker på hvordan kun kernel ville fungere uten min MPD med settinger.

Har du mulighet til å sjekke hva som skjer på din installasjon med ´watch -n1 "cat /proc/interrupts"´ når du spiller 44.1k/16bit..

192k samplerate burde også fungere - paste fra ´dmesg´

>>> kirkwood_spdif_hw_params : substream = d03c6680, params = d0494800
>>> kirkwood_spdif_hw_params : rate = 192000
>>> kirkwood_spdif_hw_params : codec_dai = dit-hifi
>>> kirkwood_set_rate :: extclk set rate = 192000 -> 49152000
>>> SPDIF Playback Ctrl = 00000000
>>>  - Non-PCM             = 0
>>>  - Register Validity   = 0
>>>  - Force Parity Error  = 0
>>>  - Mem User Enable     = 0
>>>  - Mem Validity Enable = 0
>>>  - Block Start Mode    = 0

 

[Goophy]

Kirkwood-i2s har i snitt 11.2 interrupts i sekundet gjennom en 4min sang i 44/16.
NICet har 5.

Driveren sender under 192KHz uten problemer, men det ser ut som pakkene ikke kommer frem hele til DACen.
Kjent problem at optisk sliter litt med 192KHz.

Har ikke noe utstyr til å debugge hva som blir mottatt, så jeg la den på is.

 

[Oblivion]

Har nå kjørt gjennom en god del kernel kompileringer og testet interrupt nivå for (kun interrupt nivå og ikke CPU load som vil variere med forskjellige settinger selv om interrupt nivå er konstant):

ALSA device list:
#0: Kirkwood S/PDIF
#1: Luckit Luckit USB Audio 2.0 at usb-orion-ehci.0-1, high speed
#2: ObliUSB 2.0 A r0.1 at usb-orion-ehci.1-1, high speed

Det er kjørt nøyaktig 100 sekunder via script slik at det bootes med ny kernel - MPD startes - det spilles i 100 sekunder og interruptene leses av.

Det som viser seg i praksis er at:
#0 SPDIF ikke påvirkes av NRPACKS settingene for 44.1k/16bit og det er logisk når det kjøres DMA utenom USB.
#1 WaveIO viser en svak nedgang i interrupt nivå med økende NRPACKS setting.
#2 ObliUSB viser en markert nedgang i interrupt nivå med økende NRPACKS setting.

44.1k/16bit NRPACKS=1
 21:       1071  orion_irq  kirkwood-i2s
 24:     187697  orion_irq  ehci_hcd:usb1
 25:     106494  orion_irq  ehci_hcd:usb2
 29:       1033  orion_irq  eth0

44.1k/16bit NRPACKS=8
 21:       1071  orion_irq  kirkwood-i2s
 24:     187213  orion_irq  ehci_hcd:usb1
 25:      19732  orion_irq  ehci_hcd:usb2
 29:       1079  orion_irq  eth0

44.1k/16bit NRPACKS=16
 21:       1071  orion_irq  kirkwood-i2s
 24:     185296  orion_irq  ehci_hcd:usb1
 25:      13999  orion_irq  ehci_hcd:usb2
 29:       1024  orion_irq  eth0

44.1k/16bit NRPACKS=32
 21:       1071  orion_irq  kirkwood-i2s
 24:     184471  orion_irq  ehci_hcd:usb1
 25:      13947  orion_irq  ehci_hcd:usb2
 29:       1148  orion_irq  eth0


176.4k/32bit NRPACKS=32
 21:       4231  orion_irq  kirkwood-i2s
 24:     185155  orion_irq  ehci_hcd:usb1
 25:      13781  orion_irq  ehci_hcd:usb2
 29:       3338  orion_irq  eth0


352.8k/24bit NRPACKS=32
 21:       4439  orion_irq  kirkwood-i2s
 24:     177722  orion_irq  ehci_hcd:usb1
 25:      13234  orion_irq  ehci_hcd:usb2
 29:       4221  orion_irq  eth0


352.8k/32bit NRPACKS=32
 21:       4663  orion_irq  kirkwood-i2s
 24:     186351  orion_irq  ehci_hcd:usb1
 25:      13923  orion_irq  ehci_hcd:usb2
 29:       5319  orion_irq  eth0

De optimale NRPACKS (MAX_PACKS) settingene for USB kortene ligger høyere enn NRPACKS=16 og MAX_PACKS=20,
og også andre settinger er forandret i det oppsettet jeg oppfatter som det mest optimale (men ikke vist her),
men NRPACKS settinger i området 16 til 64 vil bli evaluert i form av lyd kvalitets forskjeller da det enn så lenge blir små forskjeller når en har passert 16...
Det jobbes med en ny firmware versjon og det er en liten sjanse for at de 140 interruptene pr. sekund ved avspilling av 44.1k/16bit til 352.8k/32bit kan reduseres ytterligere med 2 - 4 ganger for 16 og 24bit, men om det lar seg realisere i praksis vil vise seg.

Hadde det forholdt seg slik at det måtte ha vært et interrupt hvert millisekund eller åtte ganger pr. millisekund så ville det ikke ha vært mulig å få noe særlig bedre resultater enn med en NRPACKS=1 setting, men heldigvis er det ikke slik og da fungerer det riktig så bra med høyere NRPACKS settinger så lenge hardwaren henger med (DMA virker?), men for mange eldre USB lydkort "kan det se ut" som at nærmere 2000 interrupt i sekundet er det laveste som er praktisk mulig av en eller annen årsak.

Interrupt antallet pr. sekund øker fra 10.7 til 42 - 46 for SPDIF med høyere samplerater.
Dette er også logisk fordi data mengden øker.
Årsaken til at det ikke øker mer ved 352.8k/24bit/32bit er fordi det da er 192k/16bit som blir overført.

Interrupt antallet pr. sekund for nettverket skalerer også med fil størrelsen og er logisk.

Årsaken til at ObliUSB ligger med ca. 140 interrupt pr. sekund selv om det er 44.1k/16bit eller 352.8k/32bit er delvis "kjent" og det jobbes det med, men det er fortsatt en "ukjent faktor" som det letes etter.
Den kjente årsaken er at ObliUSB foreløpig kun er et 32bit device og 16bit og 24bit musikk blir konvertert til 32bit av MPD og overføres over USB som 32bit.
Når dette er løst vil MPD bruke vesentlig mindre CPU når en spiller 16bit og 24bit musikk filer.
USB interruptene pr. sekund bør også gå ned jo lavere bit dybde og samplerate som spilles fordi datamengden som overføres over USB går ned til det halve (50% forbedring) for 16bit ...

Det interresante er at det er for 44.1k/16bit eller mer korrekt 16bit format det vil bli de største forbedringene, for 352.8k/32bit eller mer korrekt 32bit format er det allerede rimelig optimalt...

For de som måtte "lure" så har jeg også tidliger fått laget custom firmware i produkter og custom drivere for å få både bedre ytelse og bedre lydkvalitet.
Også denne gangen har jeg fått laget en custom firmware for et produkt som i utgangspunktet var brukbart.
Og med VID-PID så får jeg også "custom device name" og unikt produkt ID nummer, og en kan for eksempel legge inn alternativ kode og eller parametre i for eksempel "quirks" filene for USB.
Jeg trengte dette fordi min versjon av USB adapteret blir ganske så forskjellig fra standard versjonen.

 

[Oblivion]

Kernel 3.5.2 og MPD 0.18git foreløpig tweaket noenlunde optimalt for CuBox og slik den innebygde SPDIF utgangen nå er kodet og slik ObliUSB firmware er / fungerer i øyeblikket.

Når det nå spilles 352.8k/32bit materiale så er totalt CPU forbruk ca. 5%....
Foreløpig er ikke de forskjellige buffer nivåene optimalisert fordi både SPDIF source koden skal modifiseres og ObliUSB firmware skal optimeres og den avsluttende optimaliseringen får vente på dette.

Fra 44.1k/16bit til 352.8k/32bit er det en 16 gangers økning i datamengden.
44.1k/16bit bruker nå ca. 0.5% og 352.8k/32bit 10 ganger mer (ca. 5%) så det er helt tydelig at både SPDIF source koden og ObliUSB firmware har et ganske stort potensiale til forbedring.
352.8k/32bit (32bit kilder) er det foreløpig mest optimalt med ObliUSB fordi enn så lenge er dette et rent 32bit device og 16bit / 24bit musikk materiale må konverteres til 32bit (dette bruker unødvendige resursser) og det blir også overført opp til 2 ganger for mye data over USB bussen (også helt unødvendig resurss forbruk).
For SPDIF er dette motsatt fordi det kun er definert som et 16bit device og det er kun 16bit musikk materiale som fungerer optimalt.

Med 5% total forbruk av CPU for å spille 352.8k/32bit på en CPU med en kjerne på 800MHz så bruker til sammenligning min Intel i5 med 4 x 2.5GHz (3.2GHz turbo) => 10GHz / 12.8GHz ca. 4% CPU når en spille den samme musikk fil med OSX - iTunes / BitPerfect / exaU2I USB adapter.

5% av 800MHz er 40MHz - 4% av 10GHz er 400MHz...
Dette er ikke en eple vs. eple sammenligning, men indikerer i allefall at det er et rimelig stort gap (10 ganger) i CPU (MHz) forbruk og dette er godt hørbart.

Har også kompilert MPD 0.18git slik at en ved runtime velger hvilke bibliotek en laster ( eller ikke laster) og hvilke kildeformater en da støtter eller hviket bibliotek en vil bruke for WAV og AIFF etc..
I forbindelse med dette er det også et irritasjons moment - med kommandoen ´mpd -V´ så ser en hvilke bibliotek, outputs etc. som det er KOMPILERT inn støtte for -> det vil si at alt som er kompilert inn vises / listes, når en starter MPD og ikke laster FLAC eller en laster eller ikke laster sndfile eller audiofil etc.. så viser ikke ´mpd -V´ hva som faktisk er enablet og disablet.

 

[Oblivion]

Kommer til å teste ut en variant av firmware til ObliUSB hvor ALSA vil se tre forskjellige "lydkort".
Et 32bit slik som nå, men også et 24bit og et 16bit..

De 16ms feedback som 32bit interfacet nå bruker har en sammenheng med FIFO størrelsen i kortet,
og hvis 384k/32bit data ikke skal kunne gi overflow/underflow i FIFO så kan ikke feedback tiden på 16ms økes ubegrenset.

Men for 16bit interfacet hvor det vil være 44.1k/16bit som skal spilles så overføres det kun 1/16 av datamengden pr. sekund (dette gjelder for musikk data - antall sync URB etc. vil ikke gå ned, men det er rene data i forhold til FIFO som gjelder), og siden FIFO i kortet er den samme så kan feedback tiden rent teknisk økes helt opp til 256ms...
Kommer til å teste ut med forskjellige settinger og det ser ut til å kunne være teknisk mulig å komme ned godt under 40 interrupt totalt pr. sekund når en spiller 44.1k/16bit...

Nå har jeg allerede tre "lydkort" tilkoblet og skal forske litt på om jeg greier å få til at 44.1k/16bit spiller på et av dem, og at 24bit musikk spiller på nummer to, og 32bit musikk spiller på nummer tre
Men det er kanskje enklere å la firmwaren i kortet ordne dette slik at 16bit interfacet kun er aktivt ved 16bit musikk etc..

Har sjekket noen av de andre USB 2.0 Audio kortene og de er faktisk satt opp med 2ms feedback tid (som vil generere 1000 interrupt pr. sekund) og det er også fra USB kortet sin side satt / kontrollert hvor mange byte med data som skal sendes i hver ´packs´ slik at da forstår jeg hvorfor for eksempel WaveIO kortet med lave NRPACKS verdier vil ha tett ved 2000 interrupt pr. sekund og også hvorfor det går en grense ved ca. 1400 interrupts pr. sekund som det laveste en greier å få til ved å forandre NRPACKS, MAX_PACKS etc..
Når en har satt i kortet at det kun skal være 1 eller 2 eller 4 byte i hver ´packs´ så må det brukes et (for WaveIO) et minimum av URBS og ´packs´ for å få overført musikk data og dette genererer da ca. 400 interrupts pr. sekund når en får redusert antall URBS til det laveste en greier med NRPACKS og MAX_PACKS settingene.

Hvis en betrakter settingene i "standard" USB kortene fra hva som vil kunne være begrensningen i maksimal ytelse med standard ALSA settinger, med NRPACKS=1 og med det mest optimale NRPACKS og MAX_PACKS settingene så har jeg følgende betraktning:
Med de mest optimale settingene (i ALSA) og en spiller 176.4k (det spiller ingen rolle om det er 16bit, 24bit eller 32bit fordi USB kortet krever 32bit data overført) og en genererer 400 interrupt pr. sekund så er det "plass" til 600 interrupt i tillegg og da ville en kunne greid ca. 384k samplerate før det ville bli "under run" av data.
Med NRPACKS=1 så er en med 176.4k og 192k allerede på grensen til "under run", men 352.8k eller 384k samplerater ville hvis de fungerte gi problemer både for ALSA, USB drivere og kanskje MPD.
Det er mulig at et skyhøyt CPU forbruk ville ha greid å få dette til å fungere tilsynelatende (har opplevd 100% CPU forbruk med OSX og 352.8k/32bit og beta firmware / drivere - som etter forandring av settinger fungerte problemfritt)
USB 2.0 Audio har ingen feil korrigering slik at når en begynner få problem med sync så vil det først begynne å låte hardt og anstrengt, og i neste omgang når en begynner å mister data vil det begynne å "hikke" og til slutt mister DAC lock...
Men det må understrekes at settingene i disse USB kortene ikke er tiltenkt å greie mer enn 192k, og det greier de med NRPACKS=8 uten noen store problemer.

 

[Oblivion]

En QUAD CORE løsning med 1MB 2nd nivå cache og 4GB RAM kommer til test ganske snart..
Dette er også en ARMv7 type CPU med GigaBit nettverk, SATA etc...
Men det spennede blir at I2S også kan brukes / testes.

Og det kan kobles til en 8 (SATA) port RAID kontroller hvis en vil lage en 16 - 24TB NAS fil server.

Men i første omgang blir det utprøving av hvordan ARM flerkjerne og I2S og USB 2.0 Audio fungerer med 4GB RAM i forhold til MPD.

For å slå fast et faktum: Intel er stolpe og UT for alt som har med musikk og datalagring å gjøre for mitt vedkommende

 

[Goophy]

Hvilken SoC er den basert på?

Jeg har et imx6 quad-core kort liggende som jeg prøvde meg frem litt på.
Driverene der for i2s og spdif er fullstendig ubrukelige.

 

[Oblivion]

Hvilken SoC er den basert på?

Jeg har et imx6 quad-core kort liggende som jeg prøvde meg frem litt på.
Driverene der for i2s og spdif er fullstendig ubrukelige.

Hvilket kort har du ?
Greit å vite hva som ikke virker..

Jeg har flere alternativer som jeg ikke helt har bestemt meg for..
Venter på svar på noen tekniske spørsmål som jeg måtte ha på plass en NDA for å få svar på

 

[Goophy]

Er et devkort jeg fikk fra Freescale (de som lager imx-greiene) via Genesi
Har gjort noen småjobber for de. Men imx6 er ansett som "beta" fortsatt, så mulig de har noe på lur.

 

[Oblivion]

Etter å ha studert skjema til et Quad Core ARM hovedkort ser det ut til at I2S inn og ut, I2C kontroll etc. vil kunne fungere, men venter fortsatt på nøyaktige spesifikasjoner....

@Goophy - har sjekket opp lyd hardwaren som Freescale bruker og sitter det en SGTL5000 chip i kortet ditt så forstår jeg at du ikke fikk "god lyden"..
Og jeg regner vel med at det var analog utgangen du hørte på - kanskje SPDIF på det kortet du har, men I2S har jeg ikke sett lagt ut på noen av Freescale hovedkortene..
Men sitter det en SGTL5000 chip på kortet kan denne loddes ut og du kan bruke I2S signalene.

SATA - både med SSD og vanlige HDD skal jeg teste ut galvanisk isolasjon...
SSD med stor nok kapasitet med galvanisk isolasjon burde gi en vesentlig forbedring i lydkvalitet i forhold til NAS.
Det galvaniske skillet stopper jord og strømforsynings støy (galvanisk skille også mot NAS).
Data overføringen bruker DMA direkte uten å gå via PCI eller USB etc..

 

[Goophy]

Dette passer vel bedre her enn i Voyage MPD-tråden:

Hvis man vil ha åpne i2s-headere på Cubox kan man lodde av hdmi transmitteren (helt eller delvis).
Datasheet for TDA19988 ligger tilgjengelig på nett.

Den tar i2s som input rett fra Marvell SoCen.

 

[nma]

Da er Cubox-I på vei. Quad core 2GB RAM, Gigibit. Da blir det boller

 

[coolbiz]

The Raspyfi Project
raspberry pi + mpd = cheap and lovely audiophile source