Raspyfi: raspberry pi + voyage mpd. Progetto per un ottima sorgente low cost

Dai uno sguardo anche a questa distro only mpd per il cubox arm...fatta dal solito pazzo..

http://www.symphonic-net.com/kubotayo/articles/articles013.html#005

Pulizie di inizio anno: sto creando un'immagine dell'ultima raspbian ridotta all'osso... Sarà la base della prossima release di raspyfi... Qualcuno ha voglia di darmi una mano per il kernel?

mikelangeloz ha scritto:Qualcuno ha voglia di darmi una mano per il kernel?

È il tempo che manca
Premesso che non ho grande familiarità con Debian, e non ho nemmeno un Raspberry cosa vorresti fare?

Siamo in 2, tempo tiranno e laurea in arrivo... Mah, precisamente solo 2 cose:

1-real time
2-ottimizzazione per uso audio (più generico di così...)

mikelangeloz ha scritto:Siamo in 2, tempo tiranno e laurea in arrivo... Mah, precisamente solo 2 cose:

1-real time
2-ottimizzazione per uso audio (più generico di così...)

Monolitico o modulare?

Si può ancora scegliere?

mikelangeloz ha scritto:Siamo in 2, tempo tiranno e laurea in arrivo... Mah, precisamente solo 2 cose:

1-real time
2-ottimizzazione per uso audio (più generico di così...)

Il punto 2 faccio fatica a metterlo a fuoco
Il primo non credo che porti grandi vantaggi, anzi, se ho ben capito con l'introduzione degli spinlock per il real time si rischia qualche controindicazione, a meno che non sia cambiato qualcosa con le ultime patch. Comunque ho il sospetto che agendo sulle priorità dei processi e giocando con i parametri degli scheduler il real-time potrebbe essere superfluo. Però fino a quando non si prova non si può dire, il problema poi è misurare le differenze, tu hai qualche idea su come verificare e misurare eventuali differenze?

fritznet ha scritto:Monolitico o modulare?

Si può ancora scegliere?

Una volta una delle prime cose che facevo quando installavo Linux era riconfigurare il kernel togliendo tutti i moduli che non servivano e linkando staticamente quelli necessari. Ho smesso dopo un po' che sono aumentati i driver nel kernel ed è arrivato l'USB, non avevo voglia di riconfigurare e ricompilare il kernel ogni volta che attaccavo un gingillo USB che non fosse un disco fisso o una chiavetta di memoria, o che cambiavo una scheda di rete
Se si accettano limitazioni del genere anche questa potrebbe essere una prova interessante da fare. Il problema però è sempre lo stesso: come misuriamo le differenze?

Ottima domanda... Senza scendere nella filosofia e nel dibattito ascoltoni vs misuroni, direi che può bastare misurare il jitter, e verificare se permangono i problemi di riproduzione oltre i 96 khrtz...
Ammetto però che mi piacerebbe avere il RT sopratutto perchè molti dicono che serva, un pò come i cavi all'argento... Una moda quasi... E' una bella occasione per capire il perchè...

Ok, non prometto nulla ma nei prossimi giorni vedo se riesco a installare un emulatore ARM. Che kernel c'è nella Raspyfi ? Quale boootloader è usato, uboot?

Switters ha scritto:Ok, non prometto nulla ma nei prossimi giorni vedo se riesco a installare un emulatore ARM. Che kernel c'è nella Raspyfi ? Quale boootloader è usato, uboot?

se l'emulatore usa il Player MPD , riesce a saltare i problemi dei driver USB e funziona come server allora ci siamo o no...

sontero ha scritto:

Switters ha scritto:Ok, non prometto nulla ma nei prossimi giorni vedo se riesco a installare un emulatore ARM. Che kernel c'è nella Raspyfi ? Quale boootloader è usato, uboot?

se l'emulatore usa il Player MPD , riesce a saltare i problemi dei driver USB e funziona come server allora ci siamo o no...

Quali problemi dei driver USB?
L'emulatore (qemu) lo userei solo per provare a vedere se si riesce a compilare un kernel.
Gira in ambiente Linux o Windows, non su Raspberry.

Complimenti per la lodevole iniziativa.

Ho appena acquistato anch'io il Raspberry Pi, case plasticoso, alimentatore microUSB e scheda SDHC.
Appena arriva comincio a smanettare anch'io.

Vorrei farlo andare con la mia scheda audio Terratec DMX 6 fire USB.
I driver ALSA ci sono:
http://www.alsa-project.org/main/index.php/Matrix:Module-usb-6fire

Avete esperienza di installazione dei driver ALSA? Può funzionare?

Switters ha scritto:

sontero ha scritto:
se l'emulatore usa il Player MPD , riesce a saltare i problemi dei driver USB e funziona come server allora ci siamo o no...

Quali problemi dei driver USB?
L'emulatore (qemu) lo userei solo per provare a vedere se si riesce a compilare un kernel.
Gira in ambiente Linux o Windows, non su Raspberry.

Beh Switters premesso che ti ritengo ben competente pero' sei tu che hai scritto emulatore ARM che se permetti e' diverso da emulatore in Windows per compilare kernel...qui c'e' gente alle prime armi e sarebbe meglio esprimersi per farsi capire bene cosi si impara . Senno' si fanno discorsi oscuri per addetti ai lavori . Io ambirei a imparare qualcosa e sicuramente anche da te .
Sui problemi dei driver USB non mi pare che me lo invento io . Mi pare di ricordare che ci siano state diverse lamentele in giro ...ma magari ho preso un abbaglio .

Per ora non ho riscontrato problemi di sorta con i due DAC esterni (usb 1) che ho provato.
Sia il Trends UD 10.1 che il Beresford 7520 hanno gradito il raspi.

A me hanno parlato di problemi con periferiche usb 2.0, qualcuno ha dei riscontri?
Cercando nei canali ufficiali sembrano problemi risolvibili via software, anche se attualmente il discorso è in sospeso.

Riferimenti:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12097&p=145278#p145479

sontero ha scritto:Beh Switters premesso che ti ritengo ben competente pero' sei tu che hai scritto emulatore ARM che se permetti e' diverso da emulatore in Windows per compilare kernel...qui c'e' gente alle prime armi e sarebbe meglio esprimersi per farsi capire bene cosi si impara . Senno' si fanno discorsi oscuri per addetti ai lavori . Io ambirei a imparare qualcosa e sicuramente anche da te .
Sui problemi dei driver USB non mi pare che me lo invento io . Mi pare di ricordare che ci siano state diverse lamentele in giro ...ma magari ho preso un abbaglio .

Qemu è un "emulatore ARM" nel senso che "emula" l'architettura ARM sul Linux e Windows, eseguendo software compilato per questa piattaforma (ARM). Se vuoi si può semplificare dicendo che si comporta un po' come un "traduttore", prende le istruzioni comprensibili ad un processore ARM e le traduce in istruzioni comprensibili ad un processore X86 (Intel, AMD, ecc).
Insomma, si riesce a fare girare sistemi operativi compilati per Raspberry PI anche su un PC, cosa a me utile perché io un Raspberry non ce l'ho

Sì, problemi USB sembra ce ne siano (con alcuni device USB, tastiere e chiavette WiFi ad esempio) a leggere il forum di Raspberry, però secondo me è più facile che dipendano dall'hardware (o molto probabilmente dal suo firmware) che non dai driver USB di Linux. Poi magari si potrebbe anche cercare un workaround modificando i driver USB di Linux, però servirebbe la collaborazione del produttore dell'hardware, ma a quanto pare non è molto disposto a fornire aiuto in questo senso. E sembra che non abbia nemmeno preso molto a cuore il problema per risolverlo lui.

Tra l'altro non è possibile aggiornarsi seguendo il thread ( http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12097&sid=3617c6c1c5144f5d129fafad03696f39&start=800 ) perché dal 22 novembre è stato chiuso.

EDIT: per completezza di informazione, nel thread in questione (link segnalato da romvise) si parla di alta latenza (1 ms) del kernel linux nel servire gli interrupt, e mi sembra si imputi a questo la causa del problema.

Sì, problemi USB sembra ce ne siano (con alcuni device USB, tastiere e chiavette WiFi ad esempio) a leggere il forum di Raspberry, però secondo me è più facile che dipendano dall'hardware (o molto probabilmente dal suo firmware) che non dai driver USB di Linux. Poi magari si potrebbe anche cercare un workaround modificando i driver USB di Linux, però servirebbe la collaborazione del produttore dell'hardware, ma a quanto pare non è molto disposto a fornire aiuto in questo senso. E sembra che non abbia nemmeno preso molto a cuore il problema per risolverlo lui.

Tra l'altro non è possibile aggiornarsi seguendo il thread ( http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12097&sid=3617c6c1c5144f5d129fafad03696f39&start=800 ) perché dal 22 novembre è stato chiuso.

EDIT: per completezza di informazione, nel thread in questione (link segnalato da romvise) si parla di alta latenza (1 ms) del kernel linux nel servire gli interrupt, e mi sembra si imputi a questo la causa del problema.

Bene (avevo letto le stesse cose) ...anzi male . Problemi ce ne sono e speriamo che non diano fastidio nell'uso che qui ci prefiggiamo .
Io sto terminando di sistemare la mia WaveIO (alimentatore ,mobiletto ) da collegare al mio DAC (assimilabile al DAC ISIS della defunta SOTIS AUDIO di M. Ferretti ) via SPDF e spero di trarne soddisfazione quando daro' fuoco alle polveri e mi conforta leggere che altri si stanno trovando bene con altri DAC piu' recenti. Purtroppo devo andare a rilento perche' il mio lavoro chiama ....accidenti se chiama (poi famiglia ,figli etc. etc...) .
Mi sarei aspettato magari piu' resoconti di altri user ... ma verosimilmente ci saranno
Intanto il Raspino e' pronto e scalpita

Switters ha scritto:

vadopertentativi ha scritto:Allocando tutta la scheda per il SO e creando una swap da 256 mb si potrebbero avere dei miglioramenti o è inutile?

Dipende un po' da che utilizzo fai del sistema. Se non usi X windows e non imposti un buffer enorme in mpd (e in generale la memoria utilizzata non supera quella disponibile) potresti anche farlo andare senza swap area. In caso contrario (memoria utilizzata superiore a quella disponibile) avresti comunque un problema, anche con la swap area, perché il fatto di trasferire zone di memoria dalla ram alla swap area su disco (e viceversa) introduce inevitabilmente dei sensibili rallentamenti.
Prova a vedere quanta memoria è in uso con il comando free quando il sistema riproduce musica, guarda la seconda riga che fornisce le indicazioni al netto dei buffer e della cache (che in caso di necessità il kernel dovrebbe ridurre al minimo per recuperare memoria disponibile).

Mi quoto perché quanto scrivo è in relazione con la questione swap.

Precisazione: leggendo qua e là sto scoprendo un po' di cose su Raspberry, tra cui il fatto che i 512 MB di ram sono in realtà suddivisi tra CPU e GPU, quindi non sono tutti disponibili per il sistema operativo e i programmi in esecuzione. Le prove che sto facendo con Qemu mi danno 256 MB di ram sotto linux, quindi sembra che di default la memoria venga allocata metà alla CPU e metà alla GPU, è possibile però cambiare e assegnare più memoria alla CPU (quindi Linux, quindi MPD), ci sono diversi modi (da provare) per farlo.

Switters ha scritto:

sontero ha scritto:Beh Switters premesso che ti ritengo ben competente pero' sei tu che hai scritto emulatore ARM che se permetti e' diverso da emulatore in Windows per compilare kernel...qui c'e' gente alle prime armi e sarebbe meglio esprimersi per farsi capire bene cosi si impara . Senno' si fanno discorsi oscuri per addetti ai lavori . Io ambirei a imparare qualcosa e sicuramente anche da te .
Sui problemi dei driver USB non mi pare che me lo invento io . Mi pare di ricordare che ci siano state diverse lamentele in giro ...ma magari ho preso un abbaglio .

Qemu è un "emulatore ARM" nel senso che "emula" l'architettura ARM sul Linux e Windows, eseguendo software compilato per questa piattaforma (ARM). Se vuoi si può semplificare dicendo che si comporta un po' come un "traduttore", prende le istruzioni comprensibili ad un processore ARM e le traduce in istruzioni comprensibili ad un processore X86 (Intel, AMD, ecc).
Insomma, si riesce a fare girare sistemi operativi compilati per Raspberry PI anche su un PC, cosa a me utile perché io un Raspberry non ce l'ho

Sì, problemi USB sembra ce ne siano (con alcuni device USB, tastiere e chiavette WiFi ad esempio) a leggere il forum di Raspberry, però secondo me è più facile che dipendano dall'hardware (o molto probabilmente dal suo firmware) che non dai driver USB di Linux. Poi magari si potrebbe anche cercare un workaround modificando i driver USB di Linux, però servirebbe la collaborazione del produttore dell'hardware, ma a quanto pare non è molto disposto a fornire aiuto in questo senso. E sembra che non abbia nemmeno preso molto a cuore il problema per risolverlo lui.

Tra l'altro non è possibile aggiornarsi seguendo il thread ( http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12097&sid=3617c6c1c5144f5d129fafad03696f39&start=800 ) perché dal 22 novembre è stato chiuso.

EDIT: per completezza di informazione, nel thread in questione (link segnalato da romvise) si parla di alta latenza (1 ms) del kernel linux nel servire gli interrupt, e mi sembra si imputi a questo la causa del problema.

Se non capisco male (avevo letto qualcosa un po' di tempo fa), il problema dei driver è che non sono gestiti via interrupt hardware ma facendo un polling della porta

Per i non addetti: vuol dire che il processore non va a leggere i dati da un dispositivo quando questo gli dice "c'è qualcosa" ma controlla ogni millesimo di secondo se c'è qualcosa.
Conseguenza di ciò è che quando c'è qualcosa può arrivare anche un po' in ritardo ma soprattutto quando non c'è nulla il processore perde tempo

Io utilizzo con enorme soddisfazione il PI per altri scopi; è acceso da 45 giorni ininterrottamente e nessun problema
Però non nego che vorrei provare a realizzare un dispositivo collegabile in rete e ad un dac, una sorta di squeezebox basata su Linux e con un buon trasporto.

Scusate se debordo un po', ma c'è una piattaforma alternativa al raspberry, sempre piccola e economica, diciamo sotto i 100€, che valga la pena approfondire per un progetto simile?

Menestrello ha scritto:Io utilizzo con enorme soddisfazione il PI per altri scopi; è acceso da 45 giorni ininterrottamente e nessun problema
Però non nego che vorrei provare a realizzare un dispositivo collegabile in rete e ad un dac, una sorta di squeezebox basata su Linux e con un buon trasporto.

Scusate se debordo un po', ma c'è una piattaforma alternativa al raspberry, sempre piccola e economica, diciamo sotto i 100€, che valga la pena approfondire per un progetto simile?

Prova a dare un'occhiata qui: https://www.tforumhifi.com/t32698-minipc-a-15
Intorno ai 100-140$ si trovano degli ARM quadcore
Se si può, per cosa lo usi il Raspberry? Cosa c'è collegato?

Switters ha scritto:

Menestrello ha scritto:Io utilizzo con enorme soddisfazione il PI per altri scopi; è acceso da 45 giorni ininterrottamente e nessun problema
Però non nego che vorrei provare a realizzare un dispositivo collegabile in rete e ad un dac, una sorta di squeezebox basata su Linux e con un buon trasporto.

Scusate se debordo un po', ma c'è una piattaforma alternativa al raspberry, sempre piccola e economica, diciamo sotto i 100€, che valga la pena approfondire per un progetto simile?

Prova a dare un'occhiata qui: https://www.tforumhifi.com/t32698-minipc-a-15
Intorno ai 100-140$ si trovano degli ARM quadcore
Se si può, per cosa lo usi il Raspberry? Cosa c'è collegato?

ehm...
lo uso per scrivere qui visto che dall'ufficio non si può
E per fare il download di file, legali ovviamente.

Secondo te un arm può essere una piattaforma valida per realizzare un micro dedicato alla sola riproduzione della musica?
Qualcuno mi aveva detto che usare piattaforme arm non era il massimo

Menestrello ha scritto:lo uso per scrivere qui visto che dall'ufficio non si può
E per fare il download di file, legali ovviamente.

Secondo te un arm può essere una piattaforma valida per realizzare un micro dedicato alla sola riproduzione della musica?
Qualcuno mi aveva detto che usare piattaforme arm non era il massimo

Ti ci colleghi in VPN?

Non so se ARM sia una piattaforma valida per la musica, però visto che praticamente tutti gli smartphone la usano e che alcuni sembra che riproducano musica decentemente...
Personalmente ho giochicchiato con un aggeggio ARM (questo) qualche anno fa ma non l'ho mai provato come player, ai tempi non sapevo neanche cosa fosse un DAC (in ambito HiFi).
Se mi arriva l'U-host ordinato su dealxtreme qualche prova la faccio

Switters ha scritto:

Switters ha scritto:

Dipende un po' da che utilizzo fai del sistema. Se non usi X windows e non imposti un buffer enorme in mpd (e in generale la memoria utilizzata non supera quella disponibile) potresti anche farlo andare senza swap area. In caso contrario (memoria utilizzata superiore a quella disponibile) avresti comunque un problema, anche con la swap area, perché il fatto di trasferire zone di memoria dalla ram alla swap area su disco (e viceversa) introduce inevitabilmente dei sensibili rallentamenti.
Prova a vedere quanta memoria è in uso con il comando free quando il sistema riproduce musica, guarda la seconda riga che fornisce le indicazioni al netto dei buffer e della cache (che in caso di necessità il kernel dovrebbe ridurre al minimo per recuperare memoria disponibile).

Mi quoto perché quanto scrivo è in relazione con la questione swap.

Precisazione: leggendo qua e là sto scoprendo un po' di cose su Raspberry, tra cui il fatto che i 512 MB di ram sono in realtà suddivisi tra CPU e GPU, quindi non sono tutti disponibili per il sistema operativo e i programmi in esecuzione. Le prove che sto facendo con Qemu mi danno 256 MB di ram sotto linux, quindi sembra che di default la memoria venga allocata metà alla CPU e metà alla GPU, è possibile però cambiare e assegnare più memoria alla CPU (quindi Linux, quindi MPD), ci sono diversi modi (da provare) per farlo.

Ciao a tutti, scusate l'assenza. Per il discorso RAM si può decidere l'allocazione della memoria video tramite il comando raspi-config. Per RaspyFi lascerò solo 16 mega al video (il minimo), penso che per l'utilizzo via terminale o ssh sia più che sufficiente.
Per lo swap, ricordiamoci che il so è installato su scheda SD, e che quindi meno scritture ci facciamo e meglio è, per questo è disabilitato (il che rende la distribuzione anche più leggera, in termini di spazio).
Per l'usb credo che sia un problema hardware, infatti il raspberry ha anche l'ethernet condivisa sul bus usb, e i transfer rates non sono per nulla eccezzionali.
Ps: provate a commentare il resample automatico a 44 khrtz, e ditemi se avete problemi di stuttering... Credo che questo problema sia legato proprio all'usb...

Menestrello ha scritto:

Switters ha scritto:

Qemu è un "emulatore ARM" nel senso che "emula" l'architettura ARM sul Linux e Windows, eseguendo software compilato per questa piattaforma (ARM). Se vuoi si può semplificare dicendo che si comporta un po' come un "traduttore", prende le istruzioni comprensibili ad un processore ARM e le traduce in istruzioni comprensibili ad un processore X86 (Intel, AMD, ecc).
Insomma, si riesce a fare girare sistemi operativi compilati per Raspberry PI anche su un PC, cosa a me utile perché io un Raspberry non ce l'ho

Sì, problemi USB sembra ce ne siano (con alcuni device USB, tastiere e chiavette WiFi ad esempio) a leggere il forum di Raspberry, però secondo me è più facile che dipendano dall'hardware (o molto probabilmente dal suo firmware) che non dai driver USB di Linux. Poi magari si potrebbe anche cercare un workaround modificando i driver USB di Linux, però servirebbe la collaborazione del produttore dell'hardware, ma a quanto pare non è molto disposto a fornire aiuto in questo senso. E sembra che non abbia nemmeno preso molto a cuore il problema per risolverlo lui.

Tra l'altro non è possibile aggiornarsi seguendo il thread ( http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12097&sid=3617c6c1c5144f5d129fafad03696f39&start=800 ) perché dal 22 novembre è stato chiuso.

EDIT: per completezza di informazione, nel thread in questione (link segnalato da romvise) si parla di alta latenza (1 ms) del kernel linux nel servire gli interrupt, e mi sembra si imputi a questo la causa del problema.

Se non capisco male (avevo letto qualcosa un po' di tempo fa), il problema dei driver è che non sono gestiti via interrupt hardware ma facendo un polling della porta

Per i non addetti: vuol dire che il processore non va a leggere i dati da un dispositivo quando questo gli dice "c'è qualcosa" ma controlla ogni millesimo di secondo se c'è qualcosa.
Conseguenza di ciò è che quando c'è qualcosa può arrivare anche un po' in ritardo ma soprattutto quando non c'è nulla il processore perde tempo

Io utilizzo con enorme soddisfazione il PI per altri scopi; è acceso da 45 giorni ininterrottamente e nessun problema
Però non nego che vorrei provare a realizzare un dispositivo collegabile in rete e ad un dac, una sorta di squeezebox basata su Linux e con un buon trasporto.

Scusate se debordo un po', ma c'è una piattaforma alternativa al raspberry, sempre piccola e economica, diciamo sotto i 100€, che valga la pena approfondire per un progetto simile?

L'hai preso il mini pc arm a 15 euro? quello potrebbe essere un buon candidato... Cmq prova questa distro, fa esattamente quello che vuoi tu... Senza bisogno di configurarla è già pronta per essere attaccata a un nas e a un dac usb

mikelangeloz ha scritto:Ciao a tutti, scusate l'assenza. Per il discorso RAM si può decidere l'allocazione della memoria video tramite il comando raspi-config. Per RaspyFi lascerò solo 16 mega al video (il minimo), penso che per l'utilizzo via terminale o ssh sia più che sufficiente.
Per lo swap, ricordiamoci che il so è installato su scheda SD, e che quindi meno scritture ci facciamo e meglio è, per questo è disabilitato (il che rende la distribuzione anche più leggera, in termini di spazio).
Per l'usb credo che sia un problema hardware, infatti il raspberry ha anche l'ethernet condivisa sul bus usb, e i transfer rates non sono per nulla eccezzionali.
Ps: provate a commentare il resample automatico a 44 khrtz, e ditemi se avete problemi di stuttering... Credo che questo problema sia legato proprio all'usb...

Probabimente con 16 MB funziona anche Xfce, bisognerebbe provare. Con 32 non dovrebbero esserci problemi, se non si usa come video player.

PS: sto compilando un kernel (3.6.11) sulla Raspbian in Qemu, mi sa che ci vorrà un po'...

mikelangeloz ha scritto:

L'hai preso il mini pc arm a 15 euro? quello potrebbe essere un buon candidato... Cmq prova questa distro, fa esattamente quello che vuoi tu... Senza bisogno di configurarla è già pronta per essere attaccata a un nas e a un dac usb

No, non l'ho preso. I miei esperimenti con il rasp sono stati deludenti proprio perché ethernet e usb sono condivise e i driver usb funzionano facendo polling
L'audio riprodotto aveva grossi problemi di shuttering.

Secondo te il mini arm a 15€ potrebbe avere performance migliore del PI?

Scusate, che cos'è lo shuttering?
Confermo che finora con file 16/44.1 e senza resamplilg non ho avuto problemi.