Voyage MPD

[Oblivion]

@marsboer:
Jeg har prøvd "pinning" metoden og installert MPD etc. med denne metoden.
Jeg prøvde også en komplett "unstable" installering og fant ut at "testing" og "unstable" for amd64 installerer den samme kernel versjonen.
Og jeg har også kompilert MPD 0.18git og testet..

For alt "over" stable (inklusive egen kompilering) får jeg noen kompatibilitets problemer med blant annet MPC.
MPC bruker jeg for å kontrollere MPD og jeg får sjekke dette nærmere ...

 

[marsboer]

3.5 kernelen ligger kun i Debian experimental (dvs et bleeding edge område hvor problemer nærmest er garantert) som er enda mer upålitelig enn "Unstable". Du kan nok derfor bare hente ned linux-image pakken med wget fra experimental og installere denne med dpkg -i <pakkenavn>.
Jeg har ikke testet dette, så det er mulig du går på kvist.

amd64-varianten:
Debian -- Details of package linux-image-3.5-trunk-amd64 in experimental

andre platformer:
http://packages.debian.org/search?s...h=any&searchon=names&keywords=linux-image-3.5

 

[marsboer]

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

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

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

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

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

Det høres jo ut som om det er noe som er noenlunde greit å prøve. Er strømforsyningsmodifikasjonene av den enkle sorten? Kretskortkunnskapene er rimelig rustne for å si det slik, så jeg trenger en t-skje oppskrift i hvertfall nå i begynnelsen.

Jeg skulle gjerne hjulpet til på CuBox, men de som kjenner meg vet at jeg har relativt lite til overs for PCer basert på disse løsningene som i utgangspunktet er ment for embedded eller mobil bruk. Det kan jo imidlertid være et morsomt nerdeprosjekt, og prisen er lav, så med det som inngangsverdier kan jeg muligens overtale meg selv på sikt

 

[Oblivion]

Det høres jo ut som om det er noe som er noenlunde greit å prøve. Er strømforsyningsmodifikasjonene av den enkle sorten? Kretskortkunnskapene er rimelig rustne for å si det slik, så jeg trenger en t-skje oppskrift i hvertfall nå i begynnelsen.

Skal ta noen bedre bilder av min PSU "oppgradering" og lage en liten skisse eller beskrivelse - som jeg legger ut senere i dag.

Jeg skulle gjerne hjulpet til på CuBox, men de som kjenner meg vet at jeg har relativt lite til overs for PCer basert på disse løsningene som i utgangspunktet er ment for embedded eller mobil bruk. Det kan jo imidlertid være et morsomt nerdeprosjekt, og prisen er lav, så med det som inngangsverdier kan jeg muligens overtale meg selv på sikt

Tror jeg i første omgang bare installerer wheezy rimelig likt slik jeg har installert i5 systemet.
Og tweaker litt på PSU slik at CuBox og i5 har sammelignbar software og sammelignbar PSU kvalitet.
Når begge er oppe og går med lik spilleliste kan jeg enkelt gjøre en grov sammenligning med identisk USB tilkobling..

Hvis jeg senere kan rapportere om at CuBox spiller like bra eller bedre enn en +10k Intel løsning med 50x ytelsen så får vi håpe at "overtalelsen" er noget nærmere...

Ellers kan jeg slå fast at CuBox med 1920x1080 oppløsning ikke er det jeg kommer til å bruke som grafisk arbeidsstasjon.
Og det tar vesentlig lenger tid å behandle og installere "pakker" som hentes ned enn på en i5.
Når i5 nå er nedklokket og RAM og grafikk hastighet er satt ned maksimalt og linux med MPD avspilling av 44.1k bruker omtrent 1% (USB 3% eller mindre av en kjerne = 0.75% av total CPU kraft) av CPU kapasiteten så regner jeg med at CuBox kanskje vil måtte opp i overkanten av 10% og med 352.8k/32bit og DSD128 er det ikke mye mer kraft som trengs så lenge en spiller bitperfect og bare leverer orginal data til DAC.

EDIT: Lurer fortsatt på hvorfor USB bruker så mye urimelig mye CPU kraft for å sende musikk data i linux MPD... Data skulle i allefall i teorien ha blitt overført med DMA til USB porten, kan det være mulig at det er på grunn av kompatibilitet med noe "gammel" hardware eller hardware som ikke er UAC1 eller UAC2 kompatibel istedenfor blir brukt CPU I/O til å flytte data?? Har tidligere sett noen drivere for Windows og OSX for USB enheter som ikke var UAC1 eller UAC2 kompatible som brukte veldig mye CPU fordi DMA da ikke er mulig.
USB -> I2S kortet har bare en "lillebror" ARM chip med under 100MHz klokke og tar imot 384k/32bit musikk data utfører two´s complement correction og LSB extension + styrer DAC med I2C kommandoer +++

 

[marsboer]

USB rammeverket i Linux skal jo være rimelig greit, så jeg tviler på at de har implementert en stor flaskehals uten at dette i såfall er en tvungen del av designet.
Lave NRPACS verdier vil jo dramatisk øke antall interrupts. Det vil si at NRPACKS 1 vil gi åtte ganger flere IRQ interrupts enn 8 ms, så vidt jeg har skjønt. Jo høyere NRPACKS jo lavere CPU-bruk for USB audio avspilling. Jeg regner også med at rt-kernelen og en rt-prioritering på 99 på USB-porten også øker CPU-bruken vesentlig.

Jeg kjører jo fremdeles NRPACKS 8 i mitt oppsett, og har ikke sjekket CPU-bruken spesielt, men har ikke lagt merke til noe. Jeg skal sjekke når jeg kommer hjem i kveld.

Som en "sanity check" kan du jo teste generic kernel med threadirq aktivert (for å kunne se CPU-bruk på IRQ-tråden til USB huben) uten å røre hverken prioritet eller nrpacks. Hvis CPU-bruken da er lav, er det jo naturlig å tro at økt CPU-bruk skyldes rt-kernel i kombinasjon med høy prioritet og muligens lav NRPACK i tillegg.

 

[Oblivion]

@marsboer:

Strømforsyningen din har en 12 volt inngangs spenning (sort og hvit kabel), og fra DC / DC modulet går det ut forskjellige spenninger som går til hovedkortet med kabel. Sort er jord og orange er 3.3 volt, rød er 5 volt, gul er 12 volt, fiolett er 5 volt og BLÅ (NB!) er - (minus) 12 volt.
Til alle spenninger utenom - 12 volt kobles kondensatorene normalt mellom jord og spenning, men på - 12 volt skal (+) pluss på kondensatoren til jord (sort ledning) og (-) minus på kondensatoren til - 12 volt (blå ledning.

På DC / DC kortet er det merket slik at du ser hvilke spenninger som går ut på hvilke kabler.
Hvis du bruker 16, 25, 35 volt eller høyere spennings elektrolytt kondensatorer så kan du bruke like elektrolytter på alle spenningene.
Jeg fikk plass til tre elektrolytter på 12 volt inngangs spenningen i mitt lille kabinett.
Jeg brukte 6800uF / 35 volt, men 1000uF til 3300uF vil nok holde.
Over alle elektrolyttene kobler du noen raske polypropylen på 10nF til 100nF.

Husk også å koble kondensatorer på 5 og 12 volt som går til SSD / DISK / CD-ROM.

Har lagt ved noen bilder av min "minst" modifiserte maskin fordi den er lettere å åpne / lukke

 

[Oblivion]

@marsboer:
Jeg har prøvd "pinning" metoden og installert MPD etc. med denne metoden.
Jeg prøvde også en komplett "unstable" installering og fant ut at "testing" og "unstable" for amd64 installerer den samme kernel versjonen.
Og jeg har også kompilert MPD 0.18git og testet..

For alt "over" stable (inklusive egen kompilering) får jeg noen kompatibilitets problemer med blant annet MPC.
MPC bruker jeg for å kontrollere MPD og jeg får sjekke dette nærmere ...

@marsboer:
Slik mpd.conf er satt opp og uten Zeroconf / Avahi så er saken så enkel at med ´bind to "localhost"´så fungerer MPC - og ikke MPoD,
med ´bind to "xxx.xxx.xxx.xxx" så fungerer MPoD - og ikke MPC.

Har du en anbefaling til en oppskrift slik at både MPC og MPoD fungerer?

Hadde jeg oppdaget dette litt tidligere så hadde jeg ikke trengt å slette en MPD 0.18.git kompilering som så ut til å fungere utenom MPC
Men det blir uansett endel kompileringer slik at jeg får prøvd ut hva som blir minste minimum av encodere, decodere og bibliotek jeg kan komme ned i og fortsatt ha full funksjon for det som skal fungere.

MPC kan uansett anbefales fordi en da fra kommando linje kan styre MPD på en brukbart avansert måte.

 

[nma]

Det er vel bare å kommentere den linjen ut. Evt bind to 0.0.0.0.

Jeg har nå også hatt en halvveis gjennomgående test av nrpacks=1 mot 8 (og andre ting imellom, og 20, 20+, tom 1000). Faktum er at nrpacks=1 spiller best på alle parametre.

 

[marsboer]

Har du en anbefaling til en oppskrift slik at både MPC og MPoD fungerer?

Siden "any" som jo ville vært det naturlige valget kommer i konflikt på ipv6 siden (med mindre du har en egenkompilert versjon av mpd uten ipv6) er følgende metode anbefalt:

bind_to_address "10.0.0.151"
bind_to_address "localhost"

Bytt ut IPen med din egen.

Det skal ihvertfall fungere fint å legge til mange bind_to_address linjer i følge "man mpd.conf".

 

[Oblivion]

Har du en anbefaling til en oppskrift slik at både MPC og MPoD fungerer?

Siden "any" som jo ville vært det naturlige valget kommer i konflikt på ipv6 siden (med mindre du har en egenkompilert versjon av mpd uten ipv6) er følgende metode anbefalt:

bind_to_address "10.0.0.151"
bind_to_address "localhost"

Bytt ut IPen med din egen.

Det skal ihvertfall fungere fint å legge til mange bind_to_address linjer i følge "man mpd.conf".

Løsningen er at du må oppdatere wiki for nettverks oppsett (/etc/network/interfaces) og legge til:

auto lo
        iface lo inet loopback

Når jeg nå har bygd debian wheezy (armhf) fra bunnen med debootstrap og har konfigurert alt 100% manuellt fra USB konsoll på CuBox og fant jeg ut at både nfs og mpd trenger dette for å fungere.
Mye mulig at dette kan gjøres på andre måter, men jeg setter nå opp linux på den enkleste måten jeg greier å få til...

Sliter nå egentlig kun med et problem (luxus) og det er at USB konsoll med VT100 emulering og nano som editor har problemer med å editere enkelte filer slik som RC.local hvor formatteringen blir helt feil når jeg lagrer slik at RC.local ikke kjører det jeg har lagt der, men gir feilmelding.. Men også mange andre filer blir "skrudd" opp slik at ting går feil.

Noen forslag til noe som kan løse dette USB konsoll / nano problemet ??

 

[marsboer]

Løsningen er at du må oppdatere wiki for nettverks oppsett (/etc/network/interfaces) og legge til:

auto lo
        iface lo inet loopback

Når jeg nå har bygd debian wheezy (armhf) fra bunnen med debootstrap og har konfigurert alt 100% manuellt fra USB konsoll på CuBox og fant jeg ut at både nfs og mpd trenger dette for å fungere.
Mye mulig at dette kan gjøres på andre måter, men jeg setter nå opp linux på den enkleste måten jeg greier å få til...

Oi, du har fjernet loopback-oppføringen ja. Det forklarer litt. Da er det egentlig rart at du ikke har opplevd en masse krøll generelt.
Wiki'en sier at du skal redigere konfigurasjonen for nettverkskortet ditt, dvs at loopback-konfigurasjoen skal stå i fred. Jeg ser imidlertid at det kanskje ikke er intuitivt for personer uten nettverksbakgrunn at loopback-interfacet alltid må være tilstede.

Forstår jeg deg rett når jeg oppfattet det som om at du har skrevet hele konfigurasjonen selv fra et blankt utgangspunkt?

Alle mine eksempler på wiki'en tar utgangspunkt i eksisterende filer med Wheezy's standardinnhold mindre den sier noe annet. Dette gjelder både mpd.conf og interfaces-filen. Det vil si at man ikke kan starte med en blank fil og bare lime inn konfigurasjonen på wikien. I en vanlig installasjon vil loopback-interfacet alltid være definert i /etc/network/interfaces slik at man kun trenger å redigere det ordinære nettverkskortet fra dhcp til statisk om man ønsker manuelt definert fast adresse.
Jeg tenkte på å lime inn full konfigurasjon fra hver fil, men jeg føler dette legger til mye lengde på wikien samtidig som det ikke synliggjør hvilke endringer man faktisk trenger å gjøre.

Sliter nå egentlig kun med et problem (luxus) og det er at USB konsoll med VT100 emulering og nano som editor har problemer med å editere enkelte filer slik som RC.local hvor formatteringen blir helt feil når jeg lagrer slik at RC.local ikke kjører det jeg har lagt der, men gir feilmelding.. Men også mange andre filer blir "skrudd" opp slik at ting går feil.

Noen forslag til noe som kan løse dette USB konsoll / nano problemet ??

På hvilken måte blir formateringen feil? Ser det riktig ut før du lagrer og feil ut om du åpner filen etter lagring?
Har du et eksempel på hvordan formateringen ser ut før og etter?

 

[Oblivion]

Forstår jeg deg rett når jeg oppfattet det som om at du har skrevet hele konfigurasjonen selv fra et blankt utgangspunkt?

Det er ingen problemer å ta ting fra bunnen av (bare en vet at det er forutsettningen).

Koblet til et microSD kort i USB adapter og partisjonerte, formaterte og satte opp slik "jeg" mente ville være mest riktig og slik at jeg ikke skulle få med meg noe "rusk" i config filer eller på andre måter.
Ble litt jobb å få alt til å fungere, men så er det heller ingen feilmeldinger under oppstart slik det "normalt" er...
ARM systemet med RT kernel og som headless jobber faktisk merkverdig raskt og en mye ble kompilert fra source kode med en hastighet som var helt akseptabel. Boot tar ikke mange sekundene når en har fått satt opp noenlunde riktig.

På hvilken måte blir formateringen feil? Ser det riktig ut før du lagrer og feil ut om du åpner filen etter lagring?
Har du et eksempel på hvordan formateringen ser ut før og etter?

Det blir på enkelte filer "skrudd" opp med en gang nano åpner fila.
Noen filer "skrur" seg opp når en editerer.
Andre igjen ser normale ut når de lagres, men har blitt "skrudd" opp alikevel.

rc.local:
Her blir "exit" flyttet opp på linja over og lar seg ikke bli korrigert.
"0" blir liggende på egen linje...

mpd.conf:
Her blir parametre som ligger under hverandre "flyttet" slik at de blir liggende etter hverandre..

/etc/apt/sources.list:
Her er det ikke mulig å få gjort endringer uten at alt blir "skrudd" opp.
Prøver jeg å legge inn en deb linje blir denne delt opp i flere linje fragmenter mens jeg skriver,
og det er ikke mulig å rette dette opp...

 

[marsboer]

Merkelig. Jeg mistenker egentlig at "new line" blir overført feil med vt100 emulatoren, men siden Linux-installasjonen din er skreddersydd så kan det jo godt være noe der også.

 

[Oblivion]

Merkelig. Jeg mistenker egentlig at "new line" blir overført feil med vt100 emulatoren, men siden Linux-installasjonen din er skreddersydd så kan det jo godt være noe der også.

Det enkleste er vel å lage en USB stick med kernel / kernel moduler med grafikk som blir automatisk bootet før MicroSD kortet med headless kernel / kernel moduler, og boote opp med grafikk og "fin" editere ved behov..

 

[authentic]

Du får be Oblivion bygge en til deg =) Ellers har jeg ikke peil. Har kjørt det på en Mac mini 2011 inntill videre, og vifta går i den, men ikke noe særlig mer enn når jeg kjører OSX. D.v.s ganske stille. Største problemet er standardviften i Readynas'en som dessverre må stå hvor anlegget er. Jeg er villt begeistret for lydkvaliteten fra Linux. Den er helt magisk Apropos det: Etter å ha lagt merke til at AIFF låter betydelig bedre enn komprimert, har jeg prøvd å omgå dette ved å bruke større buffer og diverse andre ting, men har kommet til konklusjonen at jeg muligens må konvertere alt til AIFF. Et nederlag, menmen..

Må si jeg har veldig lyst til å sette igang med dette prosjektet men er litt usikker om jeg har kunnskaper nok til å få dette opp og gå, er det noen som kan dytte meg i riktig retning slik at jeg for lest meg opp fra A til Å ? Da tenker jeg framgangsmåten for å installere dette på en Mac Mini.

 

[Oblivion]

Da tenker jeg framgangsmåten for å installere dette på en Mac Mini.

Da er Man den som har det optimale oppsettet fungerende allerede på sin Mac Mini.

 

[marsboer]

Merkelig. Jeg mistenker egentlig at "new line" blir overført feil med vt100 emulatoren, men siden Linux-installasjonen din er skreddersydd så kan det jo godt være noe der også.

Det enkleste er vel å lage en USB stick med kernel / kernel moduler med grafikk som blir automatisk bootet før MicroSD kortet med headless kernel / kernel moduler, og boote opp med grafikk og "fin" editere ved behov..

Har du prøvd med "vi" editoren da? Helt uintuitiv i bruk for den uinnvidde, men det er nå så

 

[authentic]

Da tenker jeg framgangsmåten for å installere dette på en Mac Mini.

Da er Man den som har det optimale oppsettet fungerende allerede på sin Mac Mini.

Takker, for håpe the Man stikker ut en hjelpenede hånd etterhvert..

 

[marsboer]

Jeg kjørte nettopp opp en Debian Wheezy installasjon med mpd på en Samsung 9-serie laptop for å ha en pen, stillegående og portabel løsning som også kan kjøre med batteridrift, noe jeg skal teste i helgen. I den forbindelse dukket det opp noen behov som jeg måtte ta høyde for i scriptet mitt. For det første var det mest praktisk å bruke USB 3.0 portene til audio på denne maskinen. USB 3.0 benytter xhci_hcd modulen, mens USB 2.0 benytter ahci_hcd. "Problemet" var at lydkortet skifter IRQ mellom reboots når den står på USB 3.0. Siden USB lydkortet er eneste bruker av USB 3.0, noe man ser på /proc/interrupts også, tok jeg den enkle løsningen ved å gi alle USB 3.0 IRQ-trådene full prioritet med:

USB_IRQ_THREAD="irq/[0-9]{2}-xhci_hcd"

I tillegg har Samsung 9-serien en meget stusselig BIOS hvor man ikke kan slå av innebyggede lydkort, wifi, bluetooth og annen unødvendig hardware. Jeg la derfor til enkel fjerning og blacklisting av moduler i scriptet, slik at kernelen aldri laster modulene som aktiverer denne funksjonaliteten. I praksis oppnår man det samme som å ha en egenkompilert kernel hvor modulene ikke er tatt med, riktignok uten å gjenvinne diskplass

Eksempel på min config parameter i scriptet:

BLACKLIST="snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel btusb iwlwifi"

Modulene jeg svartelister her er HDMI-lydkortet, realtek/intel HDA lydkortet, bluetooth og wifi-kortet. De fjernes først med modprobe -r i et kjørende system før de legges til i en blacklist-fil som gjør at de aldri lastes påfølgende omstarter.

http://www.marsboer.net/shared/hifi-linux/hifi.sh

 

[Oblivion]

Hvis en kobler fra og til på USB2 portene blir det også ny IRQ og nytt device nummer..
Så når en sjekker IRQ og lager script så bør det være etter en reboot..

 

[marsboer]

Hvis en kobler fra og til på USB2 portene blir det også ny IRQ og nytt device nummer..
Så når en sjekker IRQ og lager script så bør det være etter en reboot..

Ikke hos meg. Både på ITX-maskina og laptopen får USB 2.0 huben lydkortet står på alltid IRQ 23. Det kan imidlertid ha med chipset å gjøre. Begge har nyere varianter fra Intel.

Uansett kan samme logikk benyttes der også, men man bør selvsagt sjekke at det ikke står andre enheter på IRQene man gir prioritet på. Jeg ser for meg en svært ugunstig situasjon om f.eks en USB-disk skulle få rt-prioritet..

 

[nma]

Nåja, det blir hipp som happ. Kobler du til en usb hdd, og du har kun en irq usb, f.eks 23, så vil usb disken bruke dette uansett.
Jeg setter ihvertfall samme prioritet på alle USB2 hubene, iogmed jeg kun bruker USB til USB-lydkortet og det ser ut til å fungere fint også med en USB HDD tilkoblet.

 

[marsboer]

Nåja, det blir hipp som happ. Kobler du til en usb hdd, og du har kun en irq usb, f.eks 23, så vil usb disken bruke dette uansett.

Ja, dersom alle USB 2.0 hubene er på samme IRQ. Det er de kanskje? Har ikke testet.

 

[nma]

Det så nå slik ut hos deg. Det er ikke anbefalt å kjøre USB hdd og USB-lydkort på samme USB-kontroller. Men hvis USB-disken er tilkoblet en annen kontroller (og dertil annen irq), tror jeg ikke det gjør så mye om USB prioriteringen er høy.

 

[nma]

Takker, for håpe the Man stikker ut en hjelpenede hånd etterhvert..

Johnny, du bruker en Weiss INT Spdif-sak om jeg husker riktig? Denne er mulig å støtte i Linux men det er ikke noe jeg kan hjelpe deg med. Jeg har ikke en slik selv, og FW saker krever manuell konfigurering i MPD. Dog kan jeg hjelpe deg, om du går til anskaffelse av f.eks en M2Tech Hiface TWO. (no disrespect til din Weiss, men denne billige saken tror jeg ikke står noe tilbake i lydkvalitet).
Trøsten er at om du bruker en FW-disk, så byr ihvertfall ikke dette på problemer.

 

[marsboer]

Man: Er det noen annerledes prosedyre for å installere linux på Mac mini enn ordinære PCer. Dvs boote fra USB og installere på normalt vis?

 

[nma]

Ja. Macer støtter ikke å boote fra (non-HFS/OSX)USB-disker. Bortsett fra 2011-modeller (muligens 2011-modeller uten DVD-drev), som kan gjøre det på bestemte betingelser. Heldigvis kan man benytte rEFIt til å boote fra USB uansett årsmodell.

edit: har kommet til konklusjonen om at at 2011-modeller støtter non-HFS USB-booting om du holder nede alt-knappen ved oppstart. Dette er nok en ny funksjon i firmwaren som skal støtte nyere versjoner av BootCamp, som altså støtter installering av Windows over USB (som igjen er p.g.a DVD-drevet er forsvunnet/ fra endel nyere Macer).
Det krever at man først partisjonerer USB-disken med MBR-partisjoner (kun HFS/OSX partisjoner støtter GPT-booting)

 

[authentic]

Takker, for håpe the Man stikker ut en hjelpenede hånd etterhvert..

Johnny, du bruker en Weiss INT Spdif-sak om jeg husker riktig? Denne er mulig å støtte i Linux men det er ikke noe jeg kan hjelpe deg med. Jeg har ikke en slik selv, og FW saker krever manuell konfigurering i MPD. Dog kan jeg hjelpe deg, om du går til anskaffelse av f.eks en M2Tech Hiface TWO. (no disrespect til din Weiss, men denne billige saken tror jeg ikke står noe tilbake i lydkvalitet).
Trøsten er at om du bruker en FW-disk, så byr ihvertfall ikke dette på problemer.

Setter en slik M2Tech sak opp i bestilling.

 

[marsboer]

Ja. Macer støtter ikke å boote fra (non-HFS/OSX)USB-disker. Bortsett fra 2011-modeller (muligens 2011-modeller uten DVD-drev), som kan gjøre det på bestemte betingelser. Heldigvis kan man benytte rEFIt til å boote fra USB uansett årsmodell.

edit: har kommet til konklusjonen om at at 2011-modeller støtter non-HFS USB-booting om du holder nede alt-knappen ved oppstart. Dette er nok en ny funksjon i firmwaren som skal støtte nyere versjoner av BootCamp, som altså støtter installering av Windows over USB (som igjen er p.g.a DVD-drevet er forsvunnet/ fra endel nyere Macer).
Det krever at man først partisjonerer USB-disken med MBR-partisjoner (kun HFS/OSX partisjoner støtter GPT-booting)

Ok. Det høres ut som om man bør ha en fysisk boks å teste på med andre ord. Jeg bor jo antakeligvis såpass nær johnnygrandis at vi kunne hatt en mpd-konfigurasjonskveld

 

[Oblivion]

Merkelig. Jeg mistenker egentlig at "new line" blir overført feil med vt100 emulatoren, men siden Linux-installasjonen din er skreddersydd så kan det jo godt være noe der også.

Det enkleste er vel å lage en USB stick med kernel / kernel moduler med grafikk som blir automatisk bootet før MicroSD kortet med headless kernel / kernel moduler, og boote opp med grafikk og "fin" editere ved behov..

Har du prøvd med "vi" editoren da? Helt uintuitiv i bruk for den uinnvidde, men det er nå så

For "vi" har jeg langt tilbake i tid skrevet ut et ark med de uintuitive kommandoene, men "vi" er noe av det siste jeg vil bruke...
Nå har jeg "krøpet til korset" og installert ssh på CuBox´en og da er "problemene" løst.
Men jeg kjører med både USB konsoll og ssh vindu samtidig fordi 3.5.0-rc kernel har endel "debug" info som sendes til dette konsollet
Og når jeg begynner å tweake på kernel source koden for alvor så kommer jeg til å bruke denne "RT" loggingen til konsoll inntil jeg har fått alt til å fungere korrekt.
Nå ser jeg på top i et vindu og konsoll i et annet og kan se hva konsekvensene blir av å skifte samplerate etc..

 

[nma]

Ja. Macer støtter ikke å boote fra (non-HFS/OSX)USB-disker. Bortsett fra 2011-modeller (muligens 2011-modeller uten DVD-drev), som kan gjøre det på bestemte betingelser. Heldigvis kan man benytte rEFIt til å boote fra USB uansett årsmodell.

edit: har kommet til konklusjonen om at at 2011-modeller støtter non-HFS USB-booting om du holder nede alt-knappen ved oppstart. Dette er nok en ny funksjon i firmwaren som skal støtte nyere versjoner av BootCamp, som altså støtter installering av Windows over USB (som igjen er p.g.a DVD-drevet er forsvunnet/ fra endel nyere Macer).
Det krever at man først partisjonerer USB-disken med MBR-partisjoner (kun HFS/OSX partisjoner støtter GPT-booting)

Ok. Det høres ut som om man bør ha en fysisk boks å teste på med andre ord. Jeg bor jo antakeligvis såpass nær johnnygrandis at vi kunne hatt en mpd-konfigurasjonskveld

Tror Johnny har en 2010 modell, disse vil ikke boote fra USB med mindre rEFIt er installert.
Men ellers er det ganske rett frem. Bruk Disk Utility i OSX til å resize gjeldende HFS partisjon, slik at det f.eks er 10GB ledig (holder i massevis).
Hvis det er planer om å installere Mountain Lion, og dette ikke har blitt gjort, så bør dette gjøres først. (Gjøres det etterpå, vil Mountain Lion overskrive Linux sin Boot Manager, Grub)
Så er det bare å lage en Wheezy bootstick med unetbootin og boote denne via rEFIt. Mac bruker en skjult EFI partisjon, en recoverypartisjon, samt en HFS partisjon til selve operativsystemet. Wheezy installeres altså på partisjon 4. Sørg også for å installere GRUB til partisjon 4. Ellers er dette grei skuring.

 

[nma]

Takker, for håpe the Man stikker ut en hjelpenede hånd etterhvert..

Johnny, du bruker en Weiss INT Spdif-sak om jeg husker riktig? Denne er mulig å støtte i Linux men det er ikke noe jeg kan hjelpe deg med. Jeg har ikke en slik selv, og FW saker krever manuell konfigurering i MPD. Dog kan jeg hjelpe deg, om du går til anskaffelse av f.eks en M2Tech Hiface TWO. (no disrespect til din Weiss, men denne billige saken tror jeg ikke står noe tilbake i lydkvalitet).
Trøsten er at om du bruker en FW-disk, så byr ihvertfall ikke dette på problemer.

Setter en slik M2Tech sak opp i bestilling.

Imens kan du laste ned Image Fetch fra ChorusDS Downloads
Den scanner gjennom alle albumene i iTunes. Lagrer all coverart fra hvert album som Folder.jpg i deres respektive kataloger. Perfekt til MPD..

 

[authentic]

Ja. Macer støtter ikke å boote fra (non-HFS/OSX)USB-disker. Bortsett fra 2011-modeller (muligens 2011-modeller uten DVD-drev), som kan gjøre det på bestemte betingelser. Heldigvis kan man benytte rEFIt til å boote fra USB uansett årsmodell.

edit: har kommet til konklusjonen om at at 2011-modeller støtter non-HFS USB-booting om du holder nede alt-knappen ved oppstart. Dette er nok en ny funksjon i firmwaren som skal støtte nyere versjoner av BootCamp, som altså støtter installering av Windows over USB (som igjen er p.g.a DVD-drevet er forsvunnet/ fra endel nyere Macer).
Det krever at man først partisjonerer USB-disken med MBR-partisjoner (kun HFS/OSX partisjoner støtter GPT-booting)

Ok. Det høres ut som om man bør ha en fysisk boks å teste på med andre ord. Jeg bor jo antakeligvis såpass nær johnnygrandis at vi kunne hatt en mpd-konfigurasjonskveld

Høres ut som en plan..- Trenger vel den M2Tech saken først samt bli ferdig å male det fordømrande huset

 

[Oblivion]

@marsboer

Fra wikien din har jeg quotet det følgende avsnittet:

Blokkere en drivermodul

Det kan være praktisk å blokkere en drivermodul om du f.eks ønsker å disable andre lydkort i maskinen. Navnet på den aktuelle drivermodulen for maskinvaren finner man typisk ved å studere output fra kommandoen "lspci -v" og se etter "Kernel driver in use" for den enkelte hardware komponent. Du kan se alle kjørende moduler med "lsmod".
Scriptet har en BLACKLIST variabel som gjør akkurat dette, men om du ønsker å gjøre det manuelt oppretter du en fil som heter "/etc/modprobe.d/blacklist.conf" med individuelle "blacklist <navn på modul>"-linjer listet opp nedover.

Når du skriver drivermodul betyr dette da "modul" som i en ekstern driver modul eller som også en driver som er kompilert inn i kernel?
Jeg holder på å få kompilert en kernel som kun inneholder de drivere jeg vil ha med og alt annet er fjernet.
Det blir derfor ikke noen eksterne moduler - kun selve kernel,
og det hadde vært optimalt at en ved run-time kunne få kernel til å laste kun de aktuelle driver modulene en trenger (en kan da kompilere inn flere moduler slik at en kernel kan dekke flere behov / oppsett)..

Alternativet er å måtte kompilere flere versjoner av kernel og boote med den som har de aktuelle driverene kompilert inn.

 

[marsboer]

Så vidt jeg vet gjelder dette kun moduler som kan lastes ut og inn, det vil si at dette ikke gjelder for moduler kompilert direkte inn i kernel.

 

[Oblivion]

Så vidt jeg vet gjelder dette kun moduler som kan lastes ut og inn, det vil si at dette ikke gjelder for moduler kompilert direkte inn i kernel.

Disse config valgene har en i kernel og default er CONFIG_MODULE_UNLOAD=y

[/FONT]

CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=n
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=n

Jeg er ikke sikker på om dette sikter til eksterne eller interne moduler,
men jeg skal ta og teste dette ved å prøve å blackliste for eksempel cifs eller NTFS driverne og se hva som skjer.

Det optimale ville være om en i et gitt oppsett kunne disable for eksempel USB driverne for lagringsenheter og andre drivere en ikke trenger / bruker.

 

[marsboer]

Man kan fint disable usb-enheter, og faktisk hele USB-huben. Siden jeg benytter kun USB 3.0 på det ene systemet mitt disabler jeg USB 2.0 modulen.
Alt som dukker opp med "lsmod" kan vel generelt blacklistes teknisk sett, men flere av modulene er sannsynligvis i bruk så om du ikke får lastet ut modulen direkte med "modprobe -r <modul>" må du restarte etter at du har lagt til blacklist oppføringen.

Dette er imidlertid med debians standard kerneler, så hvordan "lsmod" ser ut på en kernel uten loadable kernel moduler vet jeg ikke.

CONFIG_MODULES=y sier vel bare at du kernelmessig har støtte for moduler, men siden du kun har innkompilerte drivere vil du ikke benytte deg av funksjonaliteten selv om den er der.

 

[Oblivion]

Man kan fint disable usb-enheter, og faktisk hele USB-huben. Siden jeg benytter kun USB 3.0 på det ene systemet mitt disabler jeg USB 2.0 modulen.
Alt som dukker opp med "lsmod" kan vel generelt blacklistes teknisk sett, men flere av modulene er sannsynligvis i bruk så om du ikke får lastet ut modulen direkte med "modprobe -r <modul>" må du restarte etter at du har lagt til blacklist oppføringen.

Dette er imidlertid med debians standard kerneler, så hvordan "lsmod" ser ut på en kernel uten loadable kernel moduler vet jeg ikke.

CONFIG_MODULES=y sier vel bare at du kernelmessig har støtte for moduler, men siden du kun har innkompilerte drivere vil du ikke benytte deg av funksjonaliteten selv om den er der.

Dette og forskjellige kernel parametre blir noe som må prøves ut i praksis etterhvert.
Heldigvis er det utrolig enkelt å bytte kernel på CuBox (sikkert like enkelt på andre platformer også).
På NAS har jeg laget en "kernel" katalog på musikk sharet.
Når jeg har kompilert en ny kernel kopierer jeg den dit fra ubuntu systemet.
På CuBox via ssh tar en og renamer kjørende kernel og kopierer inn den nye.
En "reboot" kommando og en starter med ny kernel.
Og blir det trøbbel med en kernel så er det bare å ta ut uSD kortet mounte det på ubuntu systemet og rename kernel for å være tilbake (en kan også gjøre dette fra konsoll kommando linje, men da må en koble til USB kabler etc. og det er mer jobb enn å flytte uSD kortet).

 

[Oblivion]

Hmm...
Med min 3.5.2 kernel og ekstremt minimale wheezy basesystem så finnes ikke lsusb, eller lspci kommandoene og mange andre kommandoer og funksjoner før jeg eventuellt installer usbutils, pciutils etc. etc..

Jeg får ikke output fra lspci eller lsmod etter å ha installert "xxxutils"....

Det skyldes vel min kernel som ikke har kompilert inn veldig mye for PCI og at alle moduler (som trengs er kompilert inn i kernel)
På CuBox ARM så er USB og det meste andre fysisk koblet direkte inn i SoC chipen til en DMA / I/O bridge / crossbar.
Det er PCI hardware og PCI støtte i CuBox, men fordi det ikke er noen enheter som bruker PCI så har jeg utelatt dette ved kompilering.
På Intel platform er USB og det meste andre koblet via en PCI bridge og "isolert" fra system bussene.
Ikke umulig at dette gir det økte CPU forbruket for USB enheter på Intel platform..

"lsmod" viser kun innholdet i /proc/modules som på mitt system er "tom"..
/var/modules på min installasjon er også "tom"..

På "runtime" systemet kommer jeg ikke til å installere noen av de bibliotek som ikke må være der for at MPD skal fungere optimalt.

Det er nå kun avahi eller Zeroconf som eventuellt mangler for at MPoD / MPaD skal finne MPD serveren..

 

[gut_man]

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.