Voyage MPD

[nma]

Bruker nå Debian Squeeze med enkelte elementer av Wheezy. MPD 0.18 støtter kun å kompileres med GCC 4.7+ som finnes kun for Wheezy. Litt overraskende gikk det helt fint an å installere dette + dependencies i Squeeze buildboxen, samt å installere de nødvendige bibliotekene i runtime-installen.

Så fra nerdesnakk til noe matnyttig.

I den tiden fra ca litt før denne tråden har blitt opprett og til idag, har lyden fra MPD vært på omtrent 4 forskjellige nivåer.
1. veldig bra,
2. litt opp/ned mens jeg utforsket
3. drømmelyden, og den lyden jeg visste var mulig å få.
4. Bedre enn jeg trodde noengang var mulig, og har overgått alle forventninger

Så nå sitter jeg her, lyden er spinnvill, og jeg vet vet liksom ikke hva mer som kan gjøres, bortsett fra å minimere størrelsen på installasjonen (men som ikke har noen spesiell innvirkning på lyden). Konklusjonen må være:
1. Det er uvirkelig forskjell på "bit-perfect" lyd. Det er ikke snakke at det ørrlite forbedringer (les: positive forskjeller) fra native iTunes til f.eks Pure Music/Amarra /BitPerfect/etc hvis man hører godt etter (og mange hører jo ikke denne forskjellen), men det er store og fundamentale positive forskjeller. Større enn kabler (selfølgelig), forsterkere, og gir en renhet som hverken digital romkorreksjon, og akustikk alene kan gi. Jeg mener ikke å være arrogant, men det er nesten pinlig å bruke OSX/Win7 (tweaket eller ei) og høre hvor mye dårligere dette er og i tilleg prøve å høre de ørrsmå forskjellene det er mellom de forskjellige avspiller-programmene.
2. Asynkron USB hjelper deg bare et stykke på vei.
3. "Antijitter deluxe kretsløp", og såkalte jitter-frie innganger på S/Pdif DAC'er, uansett hvor dyre de er, bunner nærmest ut i ren og skjær PR-snakk. Ikke at de ikke har en oppgave, men selv her hører man meget store forbedringer. Asynkrone USB/SPdif adaptere er likevel veien å gå her.

Har også hacket Debian wheezy inn på en AppleTV1 (Pentium M 1ghz, 256MB ram) tilnærmet likt oppsatt bortsett fra at den er 32bit, spiller denne ikke i nærheten og er vel egentlig på pre-1. status. Personlig tror jeg ARM-platformer ikke når opp til denne engang, men det er bare magefølelsen, og det er selfølgelig en sjanse for at disse utklasser selv 64bit-serveren. Kanskje Oblivion er uenig

 

[authentic]

Gleder meg til å begynne med dette om ikke lenge..

 

[Oblivion]

Personlig tror jeg ARM-platformer ikke når opp til denne engang, men det er bare magefølelsen, og det er selfølgelig en sjanse for at disse utklasser selv 64bit-serveren. Kanskje Oblivion er uenig

Du har nok ikke hørt en reduksjon i CPU forbruk til å håndtere USB IRQ på 66 - 200 ganger..
Dette er vel rett og slett en alvorlig funksjons feil som har blitt rettet opp...

 

[authentic]

Da kjører siste versjon Man MPD på min nyinnkjøpte Mac mini. Måtte installere rEFIt, men da bootet den helt fint Linux fra USB laget med unetbootin. Lyden er enda et hakk hvassere, men siste finpuss mMan har gjort med MPD gjorde større utslag enn å byttefra min trofaste tilårskomne DELL laptop til Mac'en. Lyden ble enda mer organisk og bassfundamentet litt bedre definert med Mac'en. For ikke å snakke om at hirez filene spilles sømløst. Mistenker at DELLen min har hart usb1 porter og at de ikke har vært kjappe nok for hirez fra usb disk.

Gratulerer med Minien,...

Har mottat min M2tech TWO men lurer litt på framgangsmåten, er det slik at jeg skal installere programvaren på en USB minnepinne og boote fra denne ?

 

[nma]

Personlig tror jeg ARM-platformer ikke når opp til denne engang, men det er bare magefølelsen, og det er selfølgelig en sjanse for at disse utklasser selv 64bit-serveren. Kanskje Oblivion er uenig

Du har nok ikke hørt en reduksjon i CPU forbruk til å håndtere USB IRQ på 66 - 200 ganger..
Dette er vel rett og slett en alvorlig funksjons feil som har blitt rettet opp...

Jeg velger å tro at 2% på en Intel ikke er det utslagsgivende m.h.t lydkvaliteten Jeg får også dette ned ca 0,1% med standard kernel og mindre aktivitet på interrupts. Det låter bare ikke like bra.

 

[nma]

Da kjører siste versjon Man MPD på min nyinnkjøpte Mac mini. Måtte installere rEFIt, men da bootet den helt fint Linux fra USB laget med unetbootin. Lyden er enda et hakk hvassere, men siste finpuss mMan har gjort med MPD gjorde større utslag enn å byttefra min trofaste tilårskomne DELL laptop til Mac'en. Lyden ble enda mer organisk og bassfundamentet litt bedre definert med Mac'en. For ikke å snakke om at hirez filene spilles sømløst. Mistenker at DELLen min har hart usb1 porter og at de ikke har vært kjappe nok for hirez fra usb disk.

Gratulerer med Minien,...

Har mottat min M2tech TWO men lurer litt på framgangsmåten, er det slik at jeg skal installere programvaren på en USB minnepinne og boote fra denne ?

Tror fremgangsmåten var at Marsboer tar seg en tur..? Neida, fremgangsmåten er å installere refit og å bruke unetbootin til å lage en USB-pinne hvor du kan installere Debian Wheezy fra. Men først kan du jo gi en rapport om hvordan denne står seg i forhold til WEISSen din

 

[gut_man]

Kan gå god for Mans beskrivelse av utviklingen. Lyden er spinnvill i forhold til hva jeg også trodde var mulig å få til. Har nå fått brukt store deler av dagen til lytting etter ha fått Mac mini opp å gå. Foten går og gliset stopper i ørene. Klarer ikke helt å bestemme meg for om jeg ønsker meg bittelitt mer futt og fres helt øverst i diskantområdet. På den ene siden er lyden vanvittig organisk og gjennomsiktig som den er nå. Bassen har et trøkk og definisjon som ennå sjokkerer meg. Med mer nivå i diskantområdet kan lett noe av disse kvalitetene kveles. Har ikke dobbeltsjekket mot vinylriggen min, og burde sikkert ha sjekket både med VdH og XV1s pickupene før jeg konkluderer. Det kan også være at jeg med økt oppløsning på digitalkilden vør justere opp nivået på Fostex supertweeterne mine. Uansett er det nesten synd at ikke flere skal få oppleve forbedringen som ligger i disse strippede MPD spillerne.

 

[Goophy]

Bruker nå Debian Squeeze med enkelte elementer av Wheezy. MPD 0.18 støtter kun å kompileres med GCC 4.7+ som finnes kun for Wheezy. Litt overraskende gikk det helt fint an å installere dette + dependencies i Squeeze buildboxen, samt å installere de nødvendige bibliotekene i runtime-installen.

Så fra nerdesnakk til noe matnyttig.

I den tiden fra ca litt før denne tråden har blitt opprett og til idag, har lyden fra MPD vært på omtrent 4 forskjellige nivåer.
1. veldig bra,
2. litt opp/ned mens jeg utforsket
3. drømmelyden, og den lyden jeg visste var mulig å få.
4. Bedre enn jeg trodde noengang var mulig, og har overgått alle forventninger

Hei,

Har du lyst til å dele imaget du bruker?
Lurer på om jeg hører noe forskjell på det du har fått skikkelig godlyd fra og det jeg bruker nå.

 

[authentic]

Da kjører siste versjon Man MPD på min nyinnkjøpte Mac mini. Måtte installere rEFIt, men da bootet den helt fint Linux fra USB laget med unetbootin. Lyden er enda et hakk hvassere, men siste finpuss mMan har gjort med MPD gjorde større utslag enn å byttefra min trofaste tilårskomne DELL laptop til Mac'en. Lyden ble enda mer organisk og bassfundamentet litt bedre definert med Mac'en. For ikke å snakke om at hirez filene spilles sømløst. Mistenker at DELLen min har hart usb1 porter og at de ikke har vært kjappe nok for hirez fra usb disk.

Gratulerer med Minien,...

Har mottat min M2tech TWO men lurer litt på framgangsmåten, er det slik at jeg skal installere programvaren på en USB minnepinne og boote fra denne ?

Tror fremgangsmåten var at Marsboer tar seg en tur..? Neida, fremgangsmåten er å installere refit og å bruke unetbootin til å lage en USB-pinne hvor du kan installere Debian Wheezy fra. Men først kan du jo gi en rapport om hvordan denne står seg i forhold til WEISSen din

Har ikke testet Weiss imot M2tech, driver og lager en bootable backup av musikkserveren (Mac Minien der installasjonen skal skje) i skrivende stund, Deretter partisjonere disken 10GB som anbefalt og deretter lese myassoff for å skjønne alle disse bootetingreiene... Jeg vil ha dette opp å gå når høytalerene og den nye forsterkeren lander...

 

[authentic]

Bruker nå Debian Squeeze med enkelte elementer av Wheezy. MPD 0.18 støtter kun å kompileres med GCC 4.7+ som finnes kun for Wheezy. Litt overraskende gikk det helt fint an å installere dette + dependencies i Squeeze buildboxen, samt å installere de nødvendige bibliotekene i runtime-installen.

Så fra nerdesnakk til noe matnyttig.

I den tiden fra ca litt før denne tråden har blitt opprett og til idag, har lyden fra MPD vært på omtrent 4 forskjellige nivåer.
1. veldig bra,
2. litt opp/ned mens jeg utforsket
3. drømmelyden, og den lyden jeg visste var mulig å få.
4. Bedre enn jeg trodde noengang var mulig, og har overgått alle forventninger

Hei,

Har du lyst til å dele imaget du bruker?
Lurer på om jeg hører noe forskjell på det du har fått skikkelig godlyd fra og det jeg bruker nå.

Still deg i kø kompis...!!

 

[authentic]

Da kjører siste versjon Man MPD på min nyinnkjøpte Mac mini. Måtte installere rEFIt, men da bootet den helt fint Linux fra USB laget med unetbootin. Lyden er enda et hakk hvassere, men siste finpuss mMan har gjort med MPD gjorde større utslag enn å byttefra min trofaste tilårskomne DELL laptop til Mac'en. Lyden ble enda mer organisk og bassfundamentet litt bedre definert med Mac'en. For ikke å snakke om at hirez filene spilles sømløst. Mistenker at DELLen min har hart usb1 porter og at de ikke har vært kjappe nok for hirez fra usb disk.

Gratulerer med Minien,...

Har mottat min M2tech TWO men lurer litt på framgangsmåten, er det slik at jeg skal installere programvaren på en USB minnepinne og boote fra denne ?

Tror fremgangsmåten var at Marsboer tar seg en tur..? Neida, fremgangsmåten er å installere refit og å bruke unetbootin til å lage en USB-pinne hvor du kan installere Debian Wheezy fra. Men først kan du jo gi en rapport om hvordan denne står seg i forhold til WEISSen din

Hvor stor er installasjonsfila/programmet som skal på USB pinnen ?

 

[nma]

Aner ikke.. er vel en standard Debian som unetbootin laster ned for deg. 5-600MB? Alt som trengs står i wikien til Marsboer. D.v.s du kan hoppe over delen som omhandler å klargjore usb pinnen. siden du bruker Mac kan du simpelthen formatere USB sticken til FAT og starte unetbootin og velge debian wheezy derifra. Det blir ikke stort enklere. Men du må altså installere refit. Og muligens blir ikke refit aktivert etter at du har installert det. Da starter du terminal, skriver

cd /efi/refit ./enable.sh

restart OSX og du vil få valget mellom å starte opp OSX eller minnepinnen (om den står i)
Senere kan du åpne filen /efi/refit/refit.conf og forandre timeout fra 20 til 5. og legge til default_selection 2 slik at den vil starte fra det 2. operativsystemet som default. (eller hvis du foretrekker at rEFIt starter opp OSX som default, lar du det bare være)

ps. Som nevnt tidligere i tråden: Pass på at du installerer GRUB (bootloaderen til Linux) i linux partisjonen. D.v.s /dev/sda2. IKKE /dev/sda1.

 

[marsboer]

Man:
Hvilke optimaliseringer mener du har gitt god effekt hos deg?
Du nevnte f.eks noe om buffere tidligere. Hva slags buffere er det snakk om?

 

[marsboer]

En observasjon:
USB 3.0 er ikke pålitelig på Debian Wheezys kernel versjon 3.2.X. xhci_hcd har fått en enorm mengde oppdateringer i nyere kernels. Jeg får f.eks en rekke xhci_hcd feilmeldinger om jeg stopper og starter låter i hurtig rekkefølge på mitt system om jeg har M2Tech-interfacet på USB 3.0 med kernel versjon 3.2.X. Med en Debian-variant av 3.5.X-kernel forsvinner alle problemer. Jeg legger imidlertid merke til at selv i 3.5.2 står USB 3.0 og xhci_hcd merket som EXPERIMENTAL. Selv om ting ser ut til å fungere knirkefritt rent funksjonelt er det derfor grunn til å tro at USB 2.0 er et mer optimalt portvalg drivermessig selv i nyeste kernelversjoner.

 

[nma]

Man:
Hvilke optimaliseringer mener du har gitt god effekt hos deg?
Du nevnte f.eks noe om buffere tidligere. Hva slags buffere er det snakk om?

Buffere var nok MPD sin buffring, men MPD er ikke laget for å buffre egentlig. Dette har du jo funnet ut selv. Kanskje noen legger til denne funksjonen slik at den blir mer som en memoryplayer i fremtiden. Det går likevel an å bruke større buffer, men dette påvirker funksjonaliteten.
Ellers blir det vanskelig nå i ettertid å trekke direkte paralleller mellom settings og lydkvalitet . Det blir vanskelig å gå tilbake og finsjekke hver enkelt parameter som iogforseg kanskje ikke gjør så mye isolert seg. Og for å gjøre det enda vanskeligere, så har vi kommet fram til ulik konklusjon blant annet ang. RT vs vanilla kernel og nrpacks, to av de mest hørbare parametrene =)
Det jeg tror er viktigst er å ha riktig prioritet på enkelte få ting. Litt av vitsen forsvinner om man bruker en RT kernel på å sette realtime prioritet på alt =)

 

[marsboer]

Det var mer om jeg hadde uteglemt noen morsomme parametre for egen testing skyld. RT vs generic er forøvrig ikke ferdig "konkludert". Heller ikke nrpacks. Spesielt førstnevnte er vel egentlig inne i varmen igjen hos meg nå. I mitt tilfelle er "alt" nytt med tanke på nytt rom for anlegget, ny leilighet, manglende lyttestol (kjøkkenstol gjør nytten om dagen) osv. I tillegg har jeg med boligbytte gått fra festkul til slank mellombass, noe som medfører at anlegget mitt balanserer på grensen til ufint analytisk i rommet. Det låter ikke skarpt oppover, men med lite varm fylde i bunn er det ikke mye oppstramming/slanking av lyden som skal til før det bikker over på alt annet enn akustisk og jazz.

 

[Oblivion]

NRPACKS er ikke noe vesentlig tema når en får ryddet opp i kernel driverne for USB..
Det er noe som trigger en nesten total "feil" situasjon på de standard 3.2.x kernelene (både RT og standard).
Det er dette jeg nå har blitt kvitt på egen konfigurert ARM 3.5.2 kernel.

Når det gjelder MPD og caching så er det mange måter å betrakte dette på og mange måter å sette opp og tweake.
Slik mine oppsett med MPD er satt opp nå så bruker jeg ca. 20 ganger større (MPD) buffer / cache størrelse enn default og en større % andel før musikken starter å spille.
Dette er mest et forhold mellom hastigheten musikken lastes inn med med og da tiden det tar før det spiller og hva en synes er akseptabelt - et tiendels sekund - fem tiendels sekund - et sekund - fem sekunder...

Uansett så gjelder dette kun første gangen en melodi spilles fra en spilleliste og tilgjengelig RAM er stort nok til å cache hele spillelisten.
Når jeg skal teste / evaluere så setter jeg i gang en utvalgt spilleliste slik at hele spillelisten blir liggende i cache / RAM.
Deretter kan en hoppe frem og tilbake mellom melodiene uten at det er tidsforsinkelser eller noen form for I/O mot nettverk eller USB disk eller SATA disk..
Jeg har nå tre ALSA output enheter som en fra MPaD starter og stopper - spiller på en eller to eller tre output enheter samtidig.
Det eneste som skjer er at det startes en MPD prosess ekstra for hver output en spiller på.
I mitt oppsett arver disse nye prosessene prioriteten som er satt på den første output prosessen.
Og når en fra MPaD velger bort alle output så blir spillende melodi satt i "pause".
Velger en en output igjen er det bare på trykke play og det spiller videre fra der det ble satt i "pause".

Når det gjelder USB 3.0 porter så spiller det bedre når en bruker dette fremfor USB 2.0 porter på OSX.
Har ikke testet dette ennå på Linux, men jeg regner med at det samme er tilfelle for Linux.
Regner også med at USB 3.0 kernel driver er brukbar da dette er testet og prøvd lenge med OSX og *nix drivere.


Med 1GB RAM så bruker nå MPD litt over 20MB slik det er satt opp, men resten av tilgjengelig RAM er brukt til å cache spilleliste.
Her spiller MPD en 44.1k/16bit fil - men på tre utganger og da med tre output prosesser.
Selv i dette tilfellet brukes det mindre enn 1% av CPU..

 

[nma]

Hva mener du med at det ikke er vesentlig tema? Og hva mener du med å rydde opp i kerneldriverne? Det er ikke som om disse blir tatt i bruk om ikke aktuell hardware er ilkoblet.

 

[Oblivion]

Hva mener du med at det ikke er vesentlig tema? Og hva mener du med å rydde opp i kerneldriverne? Det er ikke som om disse blir tatt i bruk om ikke aktuell hardware er ilkoblet.

Så lenge som det er 2.7% til 8.3% CPU belastning for å håndtere noe som kunne hatt et lavere CPU forbruk så er det ikke noe vesentlig tema å tweake på noe s før en har rettet opp denne feilen / det som forårsaker det høye CPU forbruket.

For å sette det i perspektiv:
MPD prosessene som gjør (virkelig prosessering av data) en reel jobb bruker mindre enn 1% CPU på alle sine prosesser (ned mot 0.5% når en spiller 44.1k/16bit og måler gjennomsnittet på en 800MHz ARM CPU med 1 core).

Hvorfor skulle da USB IRQ trenge å bruke 2.7% til 8.3% CPU på en oppgave som i utgangspunktet er helt mikroskopisk i forhold ?

Det du har helt rett i er at NRPACKS spm styrer hvor ofte USB kortet skal sjekkes opp OG så lenge det er noe som er svært lite optimalt så vil dette (NRPACKS) kunne ha en vesentlig påvirkning på både funksjon og lydkvalitet.
Men som sagt er løsningen å fjerne årsaken til problemet før en begynner å fintune settinger som NRPACKS.

Når en driver henger seg på et interrupt så vil det for hver eneste driver som henger seg på måtte kjøres en god del CPU klokke sykluser for å overta interrupt kontroll, sjekke om det var noe en skulle gjøre, og enten kjøre en egen kode bit og gi interruptet til den neste i kjeden eller gi interruptet videre fordi det ikke var noe en trengte å gjøre etter å ha sjekket.
Jo flere slike rutiner en må innom jo være blir det.

 

[Oblivion]

Jeg har en ledig (tom) partisjon på i5 systemet og jeg når jeg får tid til det skal jeg bygge et basesystem (wheezy) med debootstrap og kompilere en 3.5.2 kernel som blir optimalisert for nyere i3/i5/i7, USB 2.0 Audio og kompilere en MPD 0.18git med optimal ytelse for FLAC, WAV, AIFF og native DSD, DHCP og avahi slik at MPoD / MPaD automatisk finner MPD serveren, lighttpd som gir lokal cover art / album bilder (hvis det er for eksempel er MPD.local MPaD finner så er det http://MPD.local en skriver i URL feltet).
All musikk som er mountet inn under /var/lib/mpd/music og på USB enheter vil kunne spilles.

Kompilerer kernel slik at kun USB 2.0 Audio lydkort vil bli funnet og brukt, og ingen wi-fi eller Blå tann enheter blir funnet.
Heller ikke USB printere eller USB hubber eller USB nettverkskort eller USB skjermkort etc. blir funnet eller kan brukes.
Kun USB Audio 2.0 lydkort, USB lagringsenheter som fungerer korrekt, mus og tastatur kommer til å virke på USB portene, og eventuelle USB 3.0 porter vil også fungere med de nevnte USB enheter.

Legger inn i mpd.conf støtte for flere samtidige USB 2.0 lydkort samtidig (dette kontrolleres fra MPad / MPoD),
og støtte for memory mapped I/O for de USB 2.0 kort som støtter det etc..
All resampling eller upsampling er slått av for best mulig lydkvalitet.
Kun ALSA output er kompilert inn slik at MPD er slanket ned til det som må være der for at det skal fungere.

Når det gjelder grafikk støtte får jeg se hva som er det minste minimum jeg trenger å kompilere inn.
Optimalt burde ikke noen drivere for grafikk ha vært kompilert inn slik som jeg har gjort på ARM,
men da er det kun "ssh" og eventuellt en konsoll driver for USB som ville fungert (er usikker på Intel platform og konsoll er enkelt å få til (har ikke prøvd)), bruker selv "ssh" mot mitt i5 system.

Eksterne disker / minnepinner med musikk kan være partisjonert og formattert på Linux, OSX eller Windows systemer med stort sett alle typer filsystemer.

 

[marsboer]

Jeg har ikke kikket grundig på USB-kildekoden, men det virker jo veldig rart om de skulle kjøre gjennom den totale sjekklisten med unødvendig enhetsspesifikk "quirk handling" for hver eneste interrupt.
Det logiske er jo å gjøre denne sjekken ved tilkobling/deteksjon av enheten og deretter aktivere nødvendige problemfixer.

 

[Oblivion]

Det er som regel flere måter å gjøre slikt på.
Linux må gjøre det på den mest omfattende og mest komplekse måten fordi "alt" skal forsøkes støttet.
OSX som et eksempel har den fordelen at de gjør det motsatte og støtter kun det de vil støtte og da er ca. 99% av det Linux støtter fjernet.
(kanskje ikke det beste eksemplet fordi de har åpnet opp en god del etterhvert men det er prinsippet som var poenget)
Det jeg har gjort i kernel konfigureringen / kompileringen er også å fjerne støtte og quirk for ALT jeg ikke trenger for å bruke USB 2.0 Audio kort som følger UAC2 standard og USB lagrings enheter som også følger standard.
Men som nevnt blir det normalt også kompilert inn diverse OSS funksjoner og lignende som jeg også har valgt bort fordi det ikke skal brukes.

Kobles det til en Blåtann enhet eller Wi-Fi enhet eller printer så kommer det heller ikke noe særlig feil meldinger fordi jeg også har kompilert bort verbose feilmeldinger...

 

[Oblivion]

Det logiske er jo å gjøre denne sjekken ved tilkobling/deteksjon av enheten og deretter aktivere nødvendige problemfixer.

Da MÅTTE det ha vært en begrensning på en USB enhet pr. IRQ...
Men mange systemer (de fleste Intel ??) bruker en USB HUB slik at to eller gjerne fire USB kontakter deler en IRQ...
På CuBox er det en IRQ til hver av USB portene og det er vel med tanke på at mange vil koble til en USB HUB for å få flere tilgjengelige USB porter.

Også USB HUBer har jeg fjernet støtte for i min kompilering...

Oooops... På Intel platform blir dette kanskje et problem ser jeg nå...
Tror de fleste USB 2.0 porter på Intel hardware er koblet via en USB HUB før den fysiske USB porten..

Men USB 3.0 har ingen USB HUB slik at det kanskje er DET som er årsaken til at jeg med OSX "oppfatter" at USB 3.0 porter gir bedre lydkvalitet...

Hvis det forholder seg slik at det kan "ligge en hund begravet" i det faktum at det er en USB HUB som USB 2.0 Audio kortene må gjennom er det ikke sikkert at det er mulig å få optimert optimalt på de hovedkort hvor dette er tilfelle.

Men for USB 3.0 porter (hvis kernel driveren er brukbar) er det en større sjanse for full optimering.
Har ikke sett på eventuelle ny konfigurerings valg som ligger under det å enable USB 3.0 så det må sjekkes ut.

 

[nma]

Hva mener du med at det ikke er vesentlig tema? Og hva mener du med å rydde opp i kerneldriverne? Det er ikke som om disse blir tatt i bruk om ikke aktuell hardware er ilkoblet.

Så lenge som det er 2.7% til 8.3% CPU belastning for å håndtere noe som skulle hatt et CPU forbruk på 0,025% (med Intel CPU med mange ganger CPU ytelsen kanskje bare en brøkdel av dette igjen) så er det ikke noe vesentlig tema å tweake på noe som helt opplagt er feil / noe som nesten ikke virker - før en har rettet opp denne feilen / det som forårsaker det høye CPU forbruket.

For å sette det i perspektiv:
MPD prosessene som gjør (virkelig prosessering av data) en reel jobb bruker mindre enn 1% CPU på alle sine prosesser (ned mot 0.5% når en spiller 44.1k/16bit og måler gjennomsnittet på en 800MHz ARM CPU med 1 core).

Hvorfor skulle da USB IRQ trenge å bruke 2.7% til 8.3% CPU på en oppgave som i utgangspunktet er helt mikroskopisk i forhold ?
Det som jeg har jobbet med og også fått en løsning på er nettopp dette.
USB IRQ bruker nå mindre enn 0.025% CPU nærmest uansett hvilket USB 2.0 kort en tester.
Nå er CPU forbruket så lavt uansett at jeg har måtte la det spille kontinuerlig 1 - 10 timer for å kunne beregne et noenlunde riktig CPU forbruk for USB IRQ håndtering.

Det du har helt rett i er at NRPACKS spm styrer hvor ofte USB kortet skal sjekkes opp OG så lenge det er noe som er svært lite optimalt så vil dette (NRPACKS) kunne ha en vesentlig påvirkning på både funksjon og lydkvalitet.
Men som sagt er løsningen å fjerne årsaken til problemet før en begynner å fintune settinger som NRPACKS.

Det virker ikke som du helt forstår hva som diskuteres...


Å rydde opp i kernel drivere var ikke ment som å rydde i en skuff eller skap og plassere ting på en litt forskjellig måte,
men hvis du sjekker configurerings scriptene for å kompilere en kernel og også sjekker source koden som ligger bak så vil du oppdage at det for USB (et eksempel som nå er aktuellt) er rimelig mye code som standard blir dratt med for å støtte alt annet enn USB 2.0 / ALSA...
Jeg har fjernet all gammel OSS støtte etc.. og generellt allt som ikke MÅ være der for at et USB 2.0 Audio kort skal fungere med ALSA driveren i kernel, og generering av debug informasjon etc. er også tatt bort for å optimere for bedre ytelse..

En må da noen nivåer dypere ned i konfigureringen og source koden.

Slik USB driverene nå fungerer på mitt oppsett så er det en god del kommandoer som ikke lenger gir noe resultat fordi jeg blant annet har tatt bort den ekstra funksjonen / jobben i kernel som nettopp generere en slik type output.


Hver eneste driver eller tweak for enkelte USB kort eller debug kode må for at en skal kunne koble til et USB lydkort eller hvilket som helst USB produkt etter boot / oppstart kjøre gjennom alt av kode for å sjekke om det skal iverksettes tweak for å støtte enkelt produkter etc.. Og debug delen bruker også CPU og I/O resursser for å skrive debug info til systemet.
Og en skal også kunne koble dette USB produktet bort igjen.
Derfor blir rubbel og bit av all "skrot" kode kjørt for å sjekke og verifisere.
Selvfølgelig blir ikke ALL slik kode kjørt, men "sjekk" delen blir kjørt hele tiden.
Fordi at linux i utgangspunktet støtter det "meste" og skal være fleksibelt så er "straffen" at en ender opp med et slikt CPU forbruk som 2.7% til 8.3% for USB IRQ.

Når en driver henger seg på et interrupt så vil det for hver eneste driver som henger seg på måtte kjøres en god del CPU klokke sykluser for å overta interrupt kontroll, sjekke om det var noe en skulle gjøre, og enten kjøre en egen kode bit og gi interruptet til den neste i kjeden eller gi interruptet videre fordi det ikke var noe en trengte å gjøre etter å ha sjekket.
Jo flere slike rutiner en må innom jo være blir det.
Jeg har heldigvis selv skrevt slik kode selv om det var før linux ble "oppfunnet"..

Jeg skjønner hva du mener, men nrpacks angir hvor mange pakker som blir sendt til USB i sekundet. Det skal ikke ha altfor mye å si. Og jeg har ca 2% der, som er langtifra 9%. Jeg har også disablet USB-støtte for det meste. (men har beholdt debug, men nå som alt er verifisert kan det selfølgelig tas vekk). Men som sagt kan jeg få dette tallet ned i omtrent 0%, lyden blir derimot dårligere. Jeg kan jo ta en liten runde med kernel-optimering, og dobbeltsjekke.

 

[Oblivion]

Jeg skjønner hva du mener, men nrpacks angir hvor mange pakker som blir sendt til USB i sekundet. Det skal ikke ha altfor mye å si. Og jeg har ca 2% der, som er langtifra 9%. Jeg har også disablet USB-støtte for det meste. (men har beholdt debug, men nå som alt er verifisert kan det selfølgelig tas vekk). Men som sagt kan jeg få dette tallet ned i omtrent 0%, lyden blir derimot dårligere. Jeg kan jo ta en liten runde med kernel-optimering, og dobbeltsjekke.

Prøv å kompilere kernel uten støtte for USB HUB og uten OSS, men kun med ALSA.
Mulig du må opp på 3.5 eller 3.5.2 for at ALSA versjonen er den siste..
Jeg trenger ikke å installere noen form for ALSA tools eller bibliotek med ALSA driveren som er i kernel 3.5.2.

Uten USB HUB støtte oppdager du raskt om du har en USB HUB mellom eller ikke som kan lage trøbbel...

 

[nma]

Jeg har en root hub, som 99.99999% av alle PC/Macer har, så dette må jeg vel ha.
Jeg har ikke støtte for annet enn USB-lydkort i ALSA, som forøvrig er siste versjon 1.0.25. Men nå har jeg brukt en time og disablet et tonn av ting i kernel. Toppen på i'en når ting er blitt pastell.. blir bare en bonus om det skulle ha særlig å si på ytelsen.

 

[marsboer]

Oblivion: Hvilke source filer redigerte du?

Det å fjerne drivere fra kjernen gir jo ingen CPU-reduksjon i seg selv siden kjernen uansett bare laster de driverne som trengs. Deaktivering/blacklisting av moduler som faktisk lastes men ikke er ønsket bør gjøre samme nytten, med unntak av å krympe kjernen rent fysisk.

Jeg er derfor mest spent på hvilke source-filer du faktisk har endret på og det hadde også vært fint om du kunne sagt noen ord om hvilke kodepartier du fjernet som du mener ga den store reduksjonen i CPU-bruk.

 

[nma]

Kutta ned .deb filen fra 7.4 til 4.2MB. (med endel å gå på). På USB er alt disablet utenom usb 1 2 3 og mass storage. No difference.

 

[Oblivion]

@marsboer

Hardware konfigurasjon for Marvell ARM SoC 510 og Intel er veldig forskjellig.
Årsaken til at jeg ville prøve SoC 510 (CuBox) var den forenklede og derfor langt mer optimale hardware strukturen.
Stort sett alt av I/O går direkte inn i "system bus" og med DMA - i motsettning til Intel.

Har nå to 3.5.2 "source trees" som begge er modifiserte og patchet for ARM - armhf - CuBox.

Skal installere et tredje "source tree" og se hva jeg får til i forhold til Intel...
Jeg har ikke de største forhåpninger om å få til noe tilsvarende, men skal gjøre et forsøk.

 

[marsboer]

Jeg vet ikke hvordan dere går frem når dere fjerner unødvendige moduler, men siden det refereres til "timesvis" her oppe tenkte jeg likevel at jeg kan informere om denne "shortcuten" til en spesialkernel for en spesiell maskin.

Det er nemlig slik at man kan kjøre "make localmodconfig" for å generere en .config-fil som sørger for å automatisk fjerne alle drivermoduler som ikke trengs på systemet du kjører. Ulempen er at man da må generere config-filen på akkurat det systemet kernelen skal kjøre på, noe som gjør at man trenger en del ekstrapakker som ikke trengs for bruk av mpd. Det kan derfor være lurt å ha et eget "build-image" til maskinen som har disse pakkene, men at den ferdige kernelen brukes på et image uten kernel-build-pakkene.

Når config-filen er laget er det enkelt å gjøre selve kompileringen på en annen maskin om man f.eks jobber på en svak maskin ytelsesmessig.

En kjapp måte å komme frem til et godt utgangspunkt for en nedstrippet config for en ny kernel kan derfor være (basert på Debians medfølgende config).

cd /usr/src/linux-3.5.2/
cp /boot/config-3.2.0-3-amd64 .config

# Dette steget gjøres i dette tilfellet kun for å automatisk svare default på alle nye config-parameteret som har dukket opp mellom config for 3.2.0-3 og 3.5.2
# Om man kjører make localmodconfig først må man svare manuelt på alle disse
make menuconfig
(bare velg exit og save med en gang)

# la deretter localmodconfig gjøre magien sin
make localmodconfig

en "wc -l" på config fil før og etter avslører at langt over tusen linjer er fjernet etter å ha kjørt localmodconfig.

Deretter kan man eventuelt kjøre make menuconfig igjen og finpusse config uten all "driverstøyen".

 

[nma]

Det er greit å bruke som er utgangspunkt, men jeg vet jo hvilke moduler jeg ikke trenger. Det har aldri vært noe poeng å lage en 100% skreddersøm, men man trenger heller ikke inkludere støtte for f.eks PS3-joystick liksom

 

[Oblivion]

Kompilerte en 3.5.2 kernel for 64bit Intel - optimert for mitt system.

Testet først med å installere 3.5.2 kernel til partisjon #4 (ubuntu) og det gikk uten problemer - det eneste jeg merket var at oppstart gikk raskere og at grafikk fikk høyere oppløsning.

Nerde tankegangen til linux utviklere er noe begrenset til tider og jeg skulle ha gjort det neste steget manuellt --- LOL
Med litt nerde "automatikk" innblandet og installasjon av kernel til partisjon #1 så ble hele boot opplegget skrudd opp...
Og boot går rett i memory test...

Det burde vært en sjekk som hadde sett at partisjon #4 var boot partisjon og ikke MBR eller partisjon #1, men det er tydelig vis ingen form for sjekk og "det var det"...

Får vel rydde opp dette etterhvert, men når jeg kjørte menuconfig (Intel) så kan jeg slå fast at det IKKE er helt de samme valgene for Intel og ARM / armhf.. Endel som er støttet og virker på Intel - gjør ikke det på ARM - og motsatt..
Men det er heller ikke helt de samme valg for forskjellige ARM platformer heller, endel valg blir "tristate" endel blir hardkodet og en får ikke velge heller, og når jeg kompilerte første gang ble det en modul, og derfor editerte jeg .config og søkte på "=m" og endret dette til "=y" for å slippe å lete i menyene.

Har defor ikke fått testet den kompilerte 3.5.2 Intel kernel med MPD pga boot problemene - ARM fungerer og rødvinen er god så Intel får vente til en annen anledning --- LOL
Uansett så tror jeg at det i tilfelle kun vil være USB 3.0 porter en kan få til å fungere ordentlig på Intel pga hardware implementasjonen.
(har kompilert inn USB 3.0 for å teste, men har fått en liten misstanke om at det kan være en USB HUB der også..)

 

[marsboer]

USB 3.0 har huber akkurat som USB 2.0 på mine intel-systemer i hvertfall. Men det er gjort en rekke optimaliseringer med USB 3.0, blant annet DMA. Jeg vil imidlertid tro at man ikke får glede av noe av dette om man kobler på USB 2.0 enheter.

USB 3.0 virker å ha marginalt høyere CPU bruk på min laptop, samt at driveren fremdeles er experimental og ikke fungerer helt pålitelig før i de senere kernelversjoner (du kjører jo siste versjon så du har intet å frykte der).

 

[marsboer]

For de som er lei tekst og ønsker å se noen bilder fra en faktisk løsning, så har jeg lagt ut noen bilder av mitt oppsett her: http://www.hifisentralen.no/forumet/mitt-anlegg-og-billedtra-der/42892-phobos-x-4.html#post1413047

 

[Oblivion]

Hadde testet "mikroskopisk" med å boote med 3.2.0-3-rt-amd64 SMP PREEMPT RT kernel og 3.5.2 SMP PREEMPT kernel fra den samme installasjonen.
MDP.conf må editeres og MPD restartes hver gang jeg bytter kernel fordi "bind_to_address" settingene må være forskjellige, men det samme gjelder for forskjellige MPD versjoner..

Skal ikke kommentere mer akkurat nå (før jeg får testet og validert mer)...
Alt av script rett og slett stritter i mot mine konfigurasjons valg og jeg vet ikke hvor mange ganger jeg har editert manuellt for å få dette til... Måtte editere så kjøre kjøre "make -j8 deb-pkg" eller bare "make" etc.. for å finne ut hvordan jeg skulle greie å unngå at min konfigurasjon enten ble automatisk endret eller at konfig meny startet opp igjen for en fire - fem valg som jeg ikke skulle få lov til.....

 

[marsboer]

Har du aktivert "threadirqs" som oppstartsparameter for non-rt 3.5.2? Ser ikke IRQ-trådene i listen i det hele tatt.

 

[Oblivion]

Har du aktivert "threadirqs" som oppstartsparameter for non-rt 3.5.2? Ser ikke IRQ-trådene i listen i det hele tatt.

Det ser ut som at det fra 3.6 kernel kanskje kan velges RT ved kompilering.
3.5.2 har det meste av RT koden og jeg har i allefall enablet dette som et tweak for å få en "nesten" RT kernel...

Det er noen få linjer kode (RT) som er "stable" i hrtimer.h, hrtimer.c og timekeeping.c som må endres / patches for full RT kernel.
Har en diff fil slik at jeg kommer nok til å teste en patching av 3.5.2 etterhvert...

Threadirqs har jeg ikke "rørt" i grub eller andre steder.

Har observert at for avspilling av lyd så er det mulig at en PREEMPT kernel uten RT patch,
men med RT oppsett slik jeg i allefall har prøvd på vil spille bedre enn en RT patchet kernel..

Prøver å finne en måte å styre prioritetene (med min kernel konfigurasjon) slik at RTC0 klokken (IRQ8) får rt prioritet,
og at USB får 90, MPD får 88 etc...

Jeg kommer til å jobbe med ARM armhf kernel for å få den helt optimal som en PREEMPT med RT prioritet, threadirqs og kontroll av dette,
og når jeg har fått en "oppskrift" for oppsett av dette så kan jeg prøve på Intel igjen når 3.6 er i "stable"...

Build a kernel without any patches, and make sure you set preemption to lowlatency, and your kernel clock to 1000Hz. There are a few other tips and tricks out there for configuring a good lowlatency kernel, but those are the two important ones.

'threadirqs' gives you the ability to assign RT priorities (the technical name is SCHED_FIFO) not only to processes (a normal kernel can do this) but also to the hardware interrupts themselves. This is a huge benefit for low-latency audio. To take advantage of this, you'll want to install and set up the rtirq script. This will automagically set things up to for you.

Standard verdier for kernel clock er vel 100Hz for ARM og 250Hz for Intel etter det jeg har sett...

IrqPriorities - FFADO - Trac

 

[marsboer]

CONFIG_HZ er forskjellig fra distro til distro, ikke nødvendigvis styrt av hardwareplattform. Distroer som bruker 1000Hz har vanligvis et rent desktop fokus, mens distroer som retter seg mot servere i tillegg gjerne kjører 250Hz (Debian). Det er også vanlig å sette CONFIG_HZ til 1000 i enkelte serversammenhenger også. Dette er typisk spillservere med høye krav til lav latency for spillerne.

Denne parameteren er visstnok spesiell i SMP systemer, siden verdien i praksis ganges med antall CPUer. 1000Hz i et Quad Core SMP system er i visstnok det samme som 4000Hz på et single core system. Dette er nok en annen grunn til at 250Hz er vanlig i dag for distroer med serverambisjoner, siden disse maskinene gjerne har mange CPU-kjerner i drift.

 

[Oblivion]

CONFIG_HZ er forskjellig fra distro til distro, ikke nødvendigvis styrt av hardwareplattform. Distroer som bruker 1000Hz har vanligvis et rent desktop fokus, mens distroer som retter seg mot servere i tillegg gjerne kjører 250Hz (Debian). Det er også vanlig å sette CONFIG_HZ til 1000 i enkelte serversammenhenger også. Dette er typisk spillservere med høye krav til lav latency for spillerne.

Denne parameteren er visstnok spesiell i SMP systemer, siden verdien i praksis ganges med antall CPUer. 1000Hz i et Quad Core SMP system er i visstnok det samme som 4000Hz på et single core system. Dette er nok en annen grunn til at 250Hz er vanlig i dag for distroer med serverambisjoner, siden disse maskinene gjerne har mange CPU-kjerner i drift.

Debian 3.2.x.x RT kernel har 512 CPUer satt som maksimum...

3.4 kernel er nå den siste RT kernelen...

 

[marsboer]

Jeg kompilerte et program som tester den reelle timer interrupt frekvensen på systemet. Denne viser at dagens moderne kernels på moderne CPUer med tickless kernels, høypresisjonsklokker og tilsvarende ikke egentlig er låst opp mot CONFIG_HZ som gamle kernels.

Output fra en eldre 2.6.X kernel kan se slik ut:
kernel timer interrupt frequency is approx. 249 Hz or higher

Output fra Debians 3.2.0-3-rt-amd64 kernel på mitt system (CONFIG_HZ = 250):
kernel timer interrupt frequency is approx. 4016 Hz or higher

Output fra en Debian-inspirert 3.5.2 PREEMPT kernel med CONFIG_HZ = 1000
kernel timer interrupt frequency is approx. 4016 Hz or higher

Jeg har i tillegg verifisert ved å kikke på "Local Timer Interrupts" i /proc/interrupts og her fikk jeg bare 48.9 interrupts i løpet av 10 sekunder, noe som muligens skyldes optimaliseringer som tickless kernel. Det vil si at det ikke fyres av interrupts uten at det er behov.
"I gamle dager" ville jeg her fått indikasjoner som tydet på 250 interrupts per CPU så vidt jeg har skjønt det jeg har sett på nett.

Moralen er vel egentlig da at man ikke kan ta det som står på et par-tre år gamle nettsider for god fisk når det gjelder dette. Det virker rett og slett ikke å ha betydning i dagens kernels i det hele tatt. Det har skjedd så mye med timere, kernel ticks osv i nyere tid at jeg ikke lenger har oversikt over hva som egentlig foregår, men det er i hvertfall ikke noe begrensende faktor i dag så vidt jeg kan dra ut av data fra systemet mitt.