Voyage MPD

[marsboer]

Ser interessant ut den der! Hvordan er det å kjøre dualboot på en sånn installasjon? Burde vel funke fint det! Har en 90GB SSD stående med i5 CPU, det hender jo man spiller av musikk med Spotify også - ihvertfall her i huset...

Hvis du uansett har en ipad eller iphone kan du benytte airplay og sende lyden fra disse til linux-boksen. Jeg gjør i hvertfall dette her hjemme.
iPad har i hvertfall fått en veldig fin Spotify-app etterhvert.

Oppsett av airplay er ikke dokumentert på wikien siden det er noe grisete i forhold til formålet med wikien, men det fungerer knakende bra her hjemme i hvertfall.
Jeg kan sikkert skrive noen ord om oppsett om det er av allmenn interesse.

 

[Nido]

@marsboer; ja det er av allmenn interesse at du skriver noen ord om oppsett av airplay

 

[nma]

Går utifra du bruker Shairport til Airplay. Dette fungerer, og også i native 44.100khz om man konfigurerer alsa riktig. Problemet med Shairport er at det ikke videreutvikles i noen særlig stor grad og har fra dag 1 slitt med underruns. Dette er mest følsomt fra iOS-enheter, mens iTunes er litt mer stabilt. Tilslutt er antall underruns såpass høyt at det hele må resynce og musikken stopper i noen sekunder. Ytterst irriterende.


Det vil kreve litt kløktig programmering å omgå dette, da roten til problemet egentlig er forskjellige klokkereferanser, og at airplay (lyd-delen) er en push-teknologi som ble utviklet med tanke på at en Airport Express sin interne klokke ble avledet direkte av datastrømmen. Dette er ikke tilfelle med en datamaskin, aller minst en datamaskin med en asynkron dac/interface.

Også derfor resampler alltid ATVene lyden, da dette er en "grei" måte å omgå problemet med, mens Airport Express kan være bitperfect.

 

[marsboer]

Ja, det er snakk om shairport og jeg kjenner til problematikken du snakker om. I tillegg sluttet shairport å fungere ved oppgradering til ios6 siden airplay formatet ble endret noe.

Men som alltid i open source miljøet finnes det alltid en nerd med en fix.
Det er nemlig flere luringer som har klonet det semioffisielle git-repoet og ryddet opp litt i resync-problematikken, som i tillegg har implementert fiksen for formatendringen i ios6. Problemet med dette er selvsagt at de jobber på hver sin øy og at det derfor blir opp til deg selv å plukke det du trenger. Dette er gjerne ting som ikke akkurat lyser opp øverst i google-søket heller.

"Min" variant av shairport er en krysning mellom den "offisielle" shairport og endringene fra 3. parts git-repo slik at jeg har endt opp med en variant som sitter igjen med det beste fra alle. Jeg har aldri opplevd lydmessige dropouts med varianten jeg kjører i hvertfall, selv om det helt sikkert er en sample som droppes i ny og ne (tjenesten kjører som en bakgrunnstjeneste hos meg så jeg vet ikke)

Nettopp fordi dette er "grisete" har jeg ikke lagt det ut i offentligheten. Selv om det offisielle shairport git-repoet ikke opplever mye aktivitet er det utviklere som kloner kodebasen og implementerer fixer. Støtte for ios6 ble f.eks lagt til i et slikt git-repo mens ios6 var i beta flere måneder før offisiell release. Det er derfor ingen grunn til å tro at funksjonaliteten skal dø med det første. Det er faktisk nok folk som bruker funksjonaliteten med interesse og evne til å sørge for at dette fungerer.

Uansett er dette noe som er for spesielt interesserte selv om det er greit å sette opp når noen andre har "tenkt først". Jeg skal se om jeg jeg får klasket opp noe i løpet av dagen. Tenkte jeg skulle ta to varianter, den som stort sett får de ferdige filene fra meg, og en som viser hvordan man går frem for å gjøre dette fra grunnen av selv.

 

[Ludo]

Jeg anser meg selv for å være 'spesielt interessert'

 

[Ludo]

Atheros AR8151 funker dårlig med Wheezy ser det ut til...

 

[Just4Fun]

Mopidy er det noen som har prøvd denne for å streame Spotify over MPD?

 

[Ludo]

Ser spennende ut, må prøves!

 

[coolbiz]

In related news... Revisjon 2.0 av Raspberry Pi er nå utstyrt med I/O-pinner for I₂S.

 

[Oblivion]

Samtidig har du også endret ståsted på NRPACKS etter vår siste runde med krangling rundt denne parameteren. Før sto du knallhardt på at NRPACKS var antall pakker per URB. Men etter denne posten: http://www.hifisentralen.no/forumet/datahja-rnet/64040-voyage-mpd-15.html#post1419752
... hvor det ble helt stille fra din side i etterkant, har du nå plutselig åpnet for at NRPACKS i realiteten er:

Det du kaller "krangling" fører ikke noe positivt med seg.

NRPACKS er antall pakker per URB.

Det burde vel ikke være nødvendig å bråke mer om det, og med de USB kort som jeg har testet så må standardverdien på 8 NRPACKS økes for at ikke feedback IRQ (CPU bruk) skal tvinges opp på et kunstig høyt nivå.

Nå har jeg fått ferdig muligheten til å sette feedback tiden i USB kortet interaktivt, og da er det mulig å endre settinger i både Linux / ALSA og i USB kortet og optimere for det en ønsker og også optimere for det som spiller / lyder best.

USB kortet skal også kodes slik at ALSA ser dette som både en 32bit enhet hvor alle støttede PCM bit dybder og samplerater og DSD kan spilles, og som en 16bit enhet hvor MPD leser musikk filen som 16bit og sender 16bit med 32FS slik at også USB overførings data mengden blir halvert. Fordi det trengtes mer fysisk RAM / SRAM på USB enheten for å få både 16bit og 32bit enheten til å fungere samtidig så drøyer dette litt..

Ideen her er å spille 44.1k/16bit (WAV, AIFF, FLAC) via den logiske 16bit enheten og alle andre formater via den logiske 32bit enheten.

 

[marsboer]

Det burde vel ikke være nødvendig å bråke mer om det

Der er vi i det minste enige.

NRPACKS er antall pakker per URB.

Min forståelse, utelukkende basert på en gjennomgang etter beste evne av den relevante kildekoden er som følger:
Variabelen som angir det faktiske antall pakker per urb er en konsekvens av en rekke sjekker og operasjoner mot den interne variabelen packs_per_ms, bInterval (som hentes fra lydkortet), MAX_PACKS (som er 20 som standard, men som du vel har økt) og nrpacks.
Etter at den midlertidige urb_packs variabelen er beregnet kjøres ting gjennom en kjøttkvern av operasjoner som sjekker mot max og min-verdier i forhold til alt i fra hw_params på lydkortet, gitte kø-lengder, logiske max og min verdier for antall pakker og tilsvarende.
Når alt dette er gjort og det endelig er tid for å allokere og initialisere en faktisk URB, så brukes den resulterende verdien for å sette antall pakker som skal benyttes i akkurat den nåværende URBen. Om man tar seg tid til å sette inn tallverdier i alle operasjonene underveis ser man at denne verdien, dvs u->packets når det allokeres en URB, ikke ligner på nrpacks i verdi i det hele tatt.

Din forståelse er at nrpacks angir dette direkte. Med andre ord at u->packets = nrpacks i URBen som allokeres.

Siden disse to "forståelsene" er fullstendig ulike må vi nesten være enige om at vi er fullstendig uenige.

og med de USB kort som jeg har testet så må standardverdien på 8 NRPACKS økes for at ikke feedback IRQ (CPU bruk) skal tvinges opp på et kunstig høyt nivå.

Slik er det heldgvis ikke hos meg, så jeg slipper både å ta høyde for dette og slite med lydmessig degradering som en konsekvens av dette. Jeg vil tro at dette gjelder alle som kjører noe tilsvarende M2Tech Hiface Two og en standard x86 Debian Wheezy amd64-platform.

Jeg har allerede vist tidligere i tråden at jeg ikke opplever noen reell forskjell på trafikken som går over USB-grensesnittet med endringer i NRPACKS ved hjelp av å ta opp selve dataflyten på grensesnittet, men siden jeg ikker noen fan av å dytte ut påstander uten å backe dem opp med faktiske data skal jeg for korrekthetens skyld underbygge med flere tester i forhold til interrupts og CPU-bruk.
Alle testene både på interrupts og CPU-bruk er gjort over 60 sekunder for å unngå små lokale variasjoner. I tillegg er samme låt (16bit 44.1kHz) benyttet i alle tilfeller og alle testene er startet umiddelbart etter oppstart av låt. ( mpc play && <test-kommando> )

NRPACKS = 1

root@hifi:~# cat /sys/module/snd_usb_audio/parameters/nrpacks
1


Resultat av procinfo -d -n 60:
99624  ehci_hcd:usb1, eh = 1660.4 int/s

[I]Resultat av pidstat 60 -t -p 192,151,2260 (prosentvis bruk av 1 CPU-kjerne)[/I]
Linux 3.2.0-3-rt-amd64 (hifi)   10/05/2012      _x86_64_        (4 CPU)


05:09:37 PM      TGID       TID    %usr %system  %guest    %CPU   CPU  Command
05:10:37 PM       192         -    0.00    2.20    0.00    2.20     2  irq/23-ehci_hcd
05:10:37 PM         -       192    0.00    2.20    0.00    2.20     2  |__irq/23-ehci_hcd
05:10:37 PM       151         -    0.00    0.93    0.00    0.93     2  irq/23-ehci_hcd
05:10:37 PM         -       151    0.00    0.93    0.00    0.93     2  |__irq/23-ehci_hcd
05:10:37 PM      2260         -    0.33    0.03    0.00    0.37     2  mpd
05:10:37 PM         -      2260    0.00    0.00    0.00    0.00     2  |__mpd
05:10:37 PM         -      2263    0.00    0.00    0.00    0.00     2  |__mpd
05:10:37 PM         -      2264    0.32    0.00    0.00    0.32     2  |__mpd
05:10:37 PM         -      2412    0.00    0.02    0.00    0.02     2  |__mpd

NRPACKS = 8

root@hifi:~# cat /sys/module/snd_usb_audio/parameters/nrpacks
8


Resultat av procinfo -d -n 60:
irq  23:      96302  ehci_hcd:usb1, eh = 1605.03 int/s


[I]Resultat av pidstat 60 -t -p 192,151,2260 (prosentvis bruk av 1 CPU-kjerne)[/I]
Linux 3.2.0-3-rt-amd64 (hifi)   10/05/2012      _x86_64_        (4 CPU)


04:47:28 PM      TGID       TID    %usr %system  %guest    %CPU   CPU  Command
04:48:28 PM       192         -    0.00    2.20    0.00    2.20     2  irq/23-ehci_hcd
04:48:28 PM         -       192    0.00    2.20    0.00    2.20     2  |__irq/23-ehci_hcd
04:48:28 PM       151         -    0.00    0.97    0.00    0.97     2  irq/23-ehci_hcd
04:48:28 PM         -       151    0.00    0.97    0.00    0.97     2  |__irq/23-ehci_hcd
04:48:28 PM      2260         -    0.30    0.03    0.00    0.33     2  mpd
04:48:28 PM         -      2260    0.00    0.00    0.00    0.00     2  |__mpd
04:48:28 PM         -      2263    0.02    0.00    0.00    0.02     2  |__mpd
04:48:28 PM         -      2264    0.28    0.00    0.00    0.28     2  |__mpd
04:48:28 PM         -      2412    0.02    0.02    0.00    0.03     2  |__mpd

NRPACKS = 20

root@hifi:~# cat /sys/module/snd_usb_audio/parameters/nrpacks
20


[I]Resultat av procinfo -d -n 60:[/I]
98951  ehci_hcd:usb1, eh = 1649.18 int/s


[I]Resultat av pidstat 60 -t -p 192,151,2260 (prosentvis bruk av 1 CPU-kjerne)[/I]
Linux 3.2.0-3-rt-amd64 (hifi)   10/05/2012      _x86_64_        (4 CPU)


04:43:08 PM      TGID       TID    %usr %system  %guest    %CPU   CPU  Command
04:44:08 PM       192         -    0.00    2.20    0.00    2.20     2  irq/23-ehci_hcd
04:44:08 PM         -       192    0.00    2.20    0.00    2.20     2  |__irq/23-ehci_hcd
04:44:08 PM       151         -    0.00    0.95    0.00    0.95     2  irq/23-ehci_hcd
04:44:08 PM         -       151    0.00    0.95    0.00    0.95     2  |__irq/23-ehci_hcd
04:44:08 PM      2260         -    0.32    0.00    0.00    0.32     2  mpd
04:44:08 PM         -      2260    0.00    0.00    0.00    0.00     2  |__mpd
04:44:08 PM         -      2263    0.00    0.02    0.00    0.02     2  |__mpd
04:44:08 PM         -      2264    0.28    0.00    0.00    0.28     2  |__mpd
04:44:08 PM         -      2412    0.02    0.02    0.00    0.03     2  |__mpd

I mitt tilfelle er det ingen signifikant, faktisk neppe eksisterende i det hele tatt, forskjell i hverken interrupt-rater eller CPU-bruk med ulike NRPACKS-verdier. Jeg konkluderer derfor med at dine observasjoner i det minste ikke er relevante for mitt oppsett.

 

[nma]

nrpacks=1 kontra 8/20 har her en bitteliten økning i cpu, men det er marginalt. Og låter dessuten bedre, så jeg ser ikke problemet.
Uansett, legger du ut kildekoden til den shairport-versjonen du bruker Marsboer? Sist jeg testet låt det fantastisk bra fra Airplay, men jeg endte med avinstallere det siden det ikke var 100% stabilt.

 

[marsboer]

Ved asynkron USB-avspilling så er det, slik jeg har forstått det, feedback-kanalen som benyttes for å at PCen skal kunne synkronisere seg til klokken fra lydkortet.
Rent logisk sett virker det derfor naturlig for meg at jo oftere det kommer feedback fra klokken på lydkortet jo mer nøyaktig blir PCen synkronisert mot den eksterne klokken. Dette vil implisitt også si høyere interruptrater slik jeg foreløpig har forstått ting.

Jeg regner med at det er gode grunner til at mange produsenter av asynkrone USB-lydkort legger seg på 1000+ interrupts. Kanskje de har funnet ut at dette er den gyldne middelvei mellom maksimal evne til å synkronisere seg mot ekstern klokke, og ressursbruk av hensyn til øvrig aktivitet på datamaskinen?
Jeg kan i hvertfall ikke tro at det er evnen til å faktisk sette en lavere standard feedbackrate det skal stå på for produsentene.

At det skulle ha noe å si for datamaskinens evne til å etterleve den eksterne lydkortklokken om det brukes 1 eller 3% CPU har jeg aldri sett dokumentert på etterprøvbart og overbevisende vis noe sted, og inntil jeg ser det tar jeg personlig dette med CPU-bruk med knusende ro.

Dette er vel og merke mine tanker, og jeg kan selvsagt være helt på jordet.

 

[marsboer]

Uansett, legger du ut kildekoden til den shairport-versjonen du bruker Marsboer? Sist jeg testet låt det fantastisk bra fra Airplay, men jeg endte med avinstallere det siden det ikke var 100% stabilt.

Jeg har ikke glemt det.. det er bare litt tiltak

 

[marsboer]

Shairport ble faktisk enklere enn jeg trodde. Endringene fra 3. parts-repoet ble nemlig merget inn i det offisielle shairport-repositoriet for litt over en uke siden. Jeg tok en diff på de relevante filene og de er nå identiske. Det er derfor ikke lenger behov for å kludre med å kombinere kode fra flere repositories.

Her er veiledningen:
Oppsett av shairport - marsboer.net wiki

 

[marsboer]

Jeg vil bare minne om at du ved å installere AirFoil på din Windows-maskin også kan streame lyd til Shairport direkte fra PCen din også. Du MÅ derfor ikke ha en iPad eller et Apple-produkt for å få glede av dette. Du kan like gjerne ha en laptop på fanget eller en PC på kontoret med Spotify, Wimp eller hva du måtte ønske oppe.

http://rogueamoeba.com/airfoil/

 

[Oblivion]

Slik mitt nåværende USB adapter fungerer med de settinger i kernel / ALSA og i adapteret så brukes klokke / klokkene på PC / ARM siden der og ikke i / av USB adapteret.

Når en monitorerer det som sendes av lyddata når en spiller for eksempel 352.8k så kan overførings sampleraten (monitor av USB) variere med flere kiloherts slik at det kan være 348k eller 354k som i et gitt sample tidspunkt overføres.
Feedback fra USB adapteret er styrt av FIFO fyllingsgraden i USB adapteret.
Ut av FIFO klokkes data med klokker av høy kvalitet og hva som skjer i PC / ARM eller over USB bussen så lenge FIFO har tilstrekkelig data mengde er kun viktig sett fra et støy perspektiv.

Pr. nå er det 20 - 25 ppm klokker som brukes, men både i ARM og USB adapter og DAC skal nå 0 ppm klokker testes ut for å se om det har noen praktisk eller lydmessig innvirkning. Jeg får også muligheten til å justere klokkeflankene i forhold til hverandre tidsmessig på de forskjellige klokkene selv om de er synkrone. Om dette har noe som helst praktisk betydning vet jeg ikke, men både måleresultater og hva som høres vil gi et svar på dette.

 

[marsboer]

Helt off topic:
Er det noen som egentlig kjører Voyage MPD i denne tråden nå? Burde den blitt renamed til noe slik som "Tråden for DIY MPD-baserte avspillersystemer" eller tilsvarende?

Dette er i hvertfall feil tråd å lete i om man ønsker erfaringer rundt vanilla Voyage MPD

 

[Ludo]

Kjører din wiki med ditt oppsett på HiFace Two... MEN!!! En ting skal sies; det tok veldig kort tid for å finne ut at det lydmessig er mye å gå på her! Har også exaDevices U2I-kortet koblet på og når det kjøres mot Foobar2000 så er lyden veldig mye bedre. Åpnere, mer transparant og mer dynamisk - uten tvil... Vi får håpe at det snart kommer støtte for denne i Linux en eller annen gang...!

 

[marsboer]

Kjører din wiki med ditt oppsett på HiFace Two... MEN!!! En ting skal sies; det tok veldig kort tid for å finne ut at det lydmessig er mye å gå på her! Har også exaDevices U2I-kortet koblet på og når det kjøres mot Foobar2000 så er lyden veldig mye bedre. Åpnere, mer transparant og mer dynamisk - uten tvil... Vi får håpe at det snart kommer støtte for denne i Linux en eller annen gang...!

Jeg kjenner ikke exaDevices-løsningen lydmessig så det er det helt sikkert! Hiface Two er ingen spesiell lydmessig anbefaling fra min side, det er bare en rimelig og velegnet sak for formålet som man vet ikke vil by på problemer for de som vil kjøre opp sin egen MPD-løsning.
Inntil videre sover jeg veldig godt om natta med denne i min kjede i hvertfall.

 

[gut_man]

Vi skal huske på at HiFace two er en forholdsvis rimelig sak. Jeg har planer om å teste ut mer eksklusive ting etterhvert. Jeg har primært brukt M2tech adapteret for å teste ut om MPD var veien å gå for meg. Jeg har sammenlignet med JRiver og Lynx aes16 pci lydkort og her vinner Man MPD virkelig på knockout! Mye mer oppløsning, en helt annen vekt, kontroll og detaljeringsevne i bass samt mye bedre 3d gjengivelse av innspillingene. Alt flyter lettere på en måte. Dette er mer enn godt nok for å overbevise meg om at MPD er veien å gå for meg. Hvor bra dette kan bli med en high end usb->spdif løsning kan jeg bare glede meg over. Nå er fokus på høyttalersystem for min del, men når det er i boks kommer fokuset til å rettes mot en endelig overgangsløsning fra MPD spiller til dac!

 

[quade777]

Takk for inntrykk Ludo. Da sover jeg fint på gjerdet inntil exadevices får ut fingeren og lager en linux-driver Da blir det nok litt eksperimentering med MDP. En strippet W7 får gjøre jobben inntil videre!

 

[marsboer]

Jeg kommer til å gå for Brystons nye DAC med asynkron USB integrert etterhvert, så M2Tech representerer kun en grei mellomløsning for min del også.
Det lydmessige resultatet vil selvsagt primært komme an på DACen i enden uansett. M2Tech er jo trossalt bare en USB->S/PDIF konverter.

 

[Ludo]

Joa, bare å sove godt videre - mener det ikke som noe angrep på løsningen! Bare det at jeg gleder meg til at I2S finner veien inn i denne jungelen også

 

[Ludo]

Takk for inntrykk Ludo. Da sover jeg fint på gjerdet inntil exadevices får ut fingeren og lager en linux-driver Da blir det nok litt eksperimentering med MDP. En strippet W7 får gjøre jobben inntil videre!

Strippet W7? Fortell, start gjerne en W7-strippe tråd

 

[quade777]

Tror ikke vi trenger en strippet w7 tråd forklares godt her Black Viper’s Windows 7 Service Pack 1 Service Configurations | Black Viper | www.blackviper.com

 

[marsboer]

Joa, bare å sove godt videre - mener det ikke som noe angrep på løsningen! Bare det at jeg gleder meg til at I2S finner veien inn i denne jungelen også

Ingen behov for eksterne I2S løsninger når man har asynkron USB direkte til DAC. I disse tilfellene vil jeg anta at de aller fleste internt kjører I2S uten å gå veien om S/PDIF.

 

[gut_man]

Kunne godt tenke meg en oversikt over aktuelle high end linux kompatible usb->spdif adaptere. Lager en egen tråd om det tror jeg.

 

[authentic]

Joa, bare å sove godt videre - mener det ikke som noe angrep på løsningen! Bare det at jeg gleder meg til at I2S finner veien inn i denne jungelen også

Ingen behov for eksterne I2S løsninger når man har asynkron USB direkte til DAC. I disse tilfellene vil jeg anta at de aller fleste internt kjører I2S uten å gå veien om S/PDIF.

Vil jeg (i teorien) klare og kjøre dette inn i min Asynkrone Mytek dac fra min Mac Mini over USB med Man sitt image ?

 

[Goophy]

Joa, bare å sove godt videre - mener det ikke som noe angrep på løsningen! Bare det at jeg gleder meg til at I2S finner veien inn i denne jungelen også

Finnes mange usb->i2s-kort og mange ferdige ARM-kort med i2s.
Bare å lodde rett inn i DACen.

Prøvde en Raspberry Pi rett i DACen senest igår, hørte null forskjell på det og toslink fra Cuboxen.

 

[nma]

Joa, bare å sove godt videre - mener det ikke som noe angrep på løsningen! Bare det at jeg gleder meg til at I2S finner veien inn i denne jungelen også

Ingen behov for eksterne I2S løsninger når man har asynkron USB direkte til DAC. I disse tilfellene vil jeg anta at de aller fleste internt kjører I2S uten å gå veien om S/PDIF.

Vil jeg (i teorien) klare og kjøre dette inn i min Asynkrone Mytek dac fra min Mac Mini over USB med Man sitt image ?

Kun USB 1,1-inngangen. 2.0-inngangen krever driver fra Mytek som helt sikkert ikke finnes til Linux.

 

[marsboer]

Joa, bare å sove godt videre - mener det ikke som noe angrep på løsningen! Bare det at jeg gleder meg til at I2S finner veien inn i denne jungelen også

Ingen behov for eksterne I2S løsninger når man har asynkron USB direkte til DAC. I disse tilfellene vil jeg anta at de aller fleste internt kjører I2S uten å gå veien om S/PDIF.

Vil jeg (i teorien) klare og kjøre dette inn i min Asynkrone Mytek dac fra min Mac Mini over USB med Man sitt image ?

Gitt at du har Mytek Digital Stereo192-DSD DAC så virker det på meg som om denne kun har driver for Windows og Mac. Dette er vanligvis en klar indikasjon på at denne ikke benytter seg av standarddriveren for USB audio class 2.0, noe som igjen vil si at den med høy sannsynlighet ikke vil fungere på Linux.

 

[nma]

Yes yes, da har jeg fått Airplay opp å gå igjen. Og det faller ikke ut. Meget bra

Det bør brukes plug istedet for dmix i asound.rc for best mulig lyd. Da går det ikke gjennom alsa sin mixer. (exlusive mode).

 

[marsboer]

Yes yes, da har jeg fått Airplay opp å gå igjen. Og det faller ikke ut. Meget bra

Det bør brukes plug istedet for dmix i asound.rc for best mulig lyd. Da går det ikke gjennom alsa sin mixer. (exlusive mode).

Tenker du da på å endre pcm.!default til plug? Kan du gi et kjapt eksempel? Fikk ingen lyd når jeg prøvde det her da jeg satte opp shairport første gang, men det var helt sikkert brukerfeil. Brukte ingen kalorier på å finne ut av det når mitt mål først og fremst var å unngå resampling. Direkte hardwareaksess er selvsagt å foretrekke uansett så jeg oppdaterer gjerne wikien med dette.

 

[nma]

Will do. (Etter helgen) Regnet med at du hadde stålkontroll på det.

 

[marsboer]

Fant ut av det. Det var grisete greier. Selve konfigurasjonen var helt enkel, men veien dit var lite intuitiv selv om man visste hva målet var.
Til slutt måtte jeg rett og slett bare ta aplay for å finne ut av ting systematisk.

Det jeg prøvde meg med sist som ikke ga noen lyd selv om det logisk sett ga mening var følgende:

pcm.!default {
    type hw
    card 1
}
ctl.!default {
    type hw
    card 1
}

Dette fungerte ikke, noe som var merkelig siden nøyaktig samme oppsett ser ut til å fungere knirkefritt med mpd.
Dette feilet imidlertid med shairport og med en ordinær 16-bits wav-fil i aplay. aplay gir imidlertid ut gode feilmeldinger og det viste seg at M2Tech-lydkortet kun støtter S32_LE, noe som i seg selv ikke er noe problem. I "hw"-modus vil det derimot bli et problem, siden "hw" ikke endrer lydstrømmen på noe vis. Når man da avspiller 16-bits lyd (S16_LE) feiler det rett og slett siden lydkortet ikke støtter dette formatet direkte.

Løsningen er da å bytte fra "hw" til "plughw". Forskjellen på disse er at "plughw" faktisk vil tilpasse lydstrømmen dersom lydkortet ikke støtter strømmen direkte i maskinvare. Dette vil si at formatet konverteres fra S16_LE til S32_LE. Så vidt jeg har forstått det vil lyden også resamples, men kun dersom en samplerate som ikke støttes av lydkortet avspilles. Siden lydkortet støtter alle normale samplerater vil det ikke foregå noen resampling, og mixeren er ikke i loopen.
plughw konfigurasjonen i alsa var heller ikke intuitiv. Dersom man ser på oppsett på nettet lages det slave-enheter osv, noe som kompliserer ting unødvendig. For kun å sette default avspillingsenhet til en plughw-enhet trenger man kun å gjøre følgende i /etc/asound.conf.

pcm.!default "plughw:M20,0"

# alternativt
pcm.!default "plughw:1,0"

M20 er navnet på lydkortet. Du kan bytte ut dette med card id, men da får man problemer om card id endres, f.eks når linux finner ut at første kort skal være 1 ikke 0, eller du har flere lydkort som detekteres noe tilfeldig ved oppstart.

Men da er spørsmålet, hvorfor fungerer direkte hardware-aksess i MPD med de samme filer? Er det
- mpd som konverterer all avspilt musikk til S32_LE internt?
- mpd som i praksis kjører plughw som igjen gjør denne jobben?

audio_output {
    type        "alsa"
    name        "M2Tech HiFace Two"
    device      "hw:M20,0"
}

Det spiller selvsagt ingen rolle lydmessig, men jeg ønsker å få klarhet i den logiske sammenhengen her.

 

[marsboer]

Jeg har forøvrig en Apple TV (gen. 2) koblet opp optisk mot anlegget også. Denne resampler lyden via airplay til 48kHz. Jeg opplever at linux-boxen med shairport og riktige alsa-innstillinger låter bedre enn denne, og da må man jo si seg fornøyd siden Apple selv jo må sees på som benchmark for Airplay.
Lydstrømmen virker også å starte omtrent like raskt, så det er ingen merkbare forskjeller i brukeropplevelse heller.

 

[Just4Fun]

Det finnes jo MPD client til ATV via XBMC. Har du prøvd denne? Eventuelt hvordan opplevde du lyden på denne?

 

[marsboer]

Det finnes jo MPD client til ATV via XBMC. Har du prøvd denne? Eventuelt hvordan opplevde du lyden på denne?

Jeg har ikke prøvd denne, men dersom det kun er snakk om en klient så vil ikke dette påvirke lyden. Det er mpd-serveren som gjør hele jobben.

 

[stianG]

Leser denne tråden med stor interesse selv om mesteparten går rett over hodet på meg. For en enkel innlandsbonde og apple fanboy blir mesteparten kaudervelsk, men jeg biter meg merke i at det meldes om tildels store lydmessige forbedringer i forhold til os x og win løsninger. Har da lyst til å prøve en linux variant, men har tildels låst meg til os x siden firewire lydkortet mitt er mac only og jeg har gjort meg litt avhengig av pure vinyl både på grunn av delefilteret og riaa korreksjonen. Lydkortet har dog masse aes/ebu innganger og jeg har en stello u3 liggende et sted. Delefilter kan flyttes til dsp i lydkortet. Behøver vel da bare en ekstra maskin med linux/mpd for å få det i gang. Har en gammel 17" imac, en like gammel macbook og en boxee boks tilgjengelig. Vil noen av disse fungere, eller bør jeg kjøpe noe nytt?