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

romvise ha scritto:Confermo che finora con file 16/44.1 e senza resamplilg non ho avuto problemi.

Che periferiche hai collegate al Raspberry?

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

Il singhiozzo

Attualmente un dongle wifi e il Beresford 7520
Ho provato anche con ethernet e Trends Ud 10.1
La musica è su cartella condivisa su un altro pc.

Menestrello ha scritto:Il singhiozzo

Ora è chiarissimo

In teoria nella nuova versione ci dovrebbero essere i driver usb migliorati di cui si vociferava... Quella attuale è basata su una Raspbian di settembre...

mikelangeloz ha scritto:In teoria nella nuova versione ci dovrebbero essere i driver usb migliorati di cui si vociferava... Quella attuale è basata su una Raspbian di settembre...

I driver Linux o il firmware della Broadcom?
Se veramente i problemi USB sono dati dalla latenza di Linux nel servire gli interrupt, con il kernel real time si dovrebbero risolvere, mi sembra strano però che nessuno ci abbia pensato e provato...

Switters ha scritto:

mikelangeloz ha scritto:In teoria nella nuova versione ci dovrebbero essere i driver usb migliorati di cui si vociferava... Quella attuale è basata su una Raspbian di settembre...

I driver Linux o il firmware della Broadcom?
Se veramente i problemi USB sono dati dalla latenza di Linux nel servire gli interrupt, con il kernel real time si dovrebbero risolvere, mi sembra strano però che nessuno ci abbia pensato e provato...

In effetti se questo risolvesse il problema... Magari però ha altre controindicazioni per un uso più generico... Ma quindi stai compilando un kernel RT per il raspberry?
In ogni caso grazie switters, mi stai lanciando delle belle dritte!

Tra parentesi, sul forum di raspberrypi sto ricevendo dei buoni feedback, un tizio con un impianto della madonna dice che è rimasto molto contento della qualità del piccoletto!
E poi ce n'è uno che è riuscito a comandarlo con una cornice digitale, che può essere usata anche come schermo esterno! Figata!
Trovate tutto qui!
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=35&t=28764&sid=63842250c96a9b4df965539921675d1c

Questa della cornice digitale è molto succosa come new entry, giusto oggi mi chiedevo se ci fosse la possibilità di un minischermo a bassissimo consumo, peccato non scenda in dettagli, o non li ho visti io?

Switters ha scritto:
...
cut
...
I driver Linux o il firmware della Broadcom?
Se veramente i problemi USB sono dati dalla latenza di Linux nel servire gli interrupt, con il kernel real time si dovrebbero risolvere, mi sembra strano però che nessuno ci abbia pensato e provato...

Andrea, prendila come suggestione "volante", ma mi pare di avere capito che con baudline si possa misurare anche il jitter, potrebbe essere utile nel caso si vogliano testare due versioni diverse (kernel Rt e non, altro etc).
Poi bisogna vedere se si riesce ad utilizzare attraverso Qemu, trattandosi di flussi digitali non dovrebbero esserci problemi, stante anche la flessibilità di Baudline, spero di poter approfondire questo aspetto per cavarci qualcosa.

Fra l'altro anche lo sviluppatore di Baud. menzionava tempo fa via twitter qualche problema o baco inerente il driver USB linux, se riesco a ripescare l'argomento lo posto, sperando possa essere utile.

Anche io sono rimasto sorpreso, sopratutto il basso è interessante, però non ritengo che al momento superi un confronto diretto con un eeepc + voyage_mpd (che però costa il doppio).

Ho scoperto giusto ieri sera che al mio raspi non piacciono i file 16/48, avete riscontrato lo stesso problema?

Oggi ho installato la distro minimale consigliata da Miclaud nei primi post di questo thread, ma non mi sembra di aver percepito miglioramenti particolari, aspetto con curiosità una versione raspyfi per schede da 2gb e kernel RT

mikelangeloz ha scritto:Ma quindi stai compilando un kernel RT per il raspberry?

Interessante la cornice. Tempo fa avevo letto di qualcuno che da una cornice ci aveva tirato fuori un tablet, forse aggiungendo una "pellicola" touchscreen

Ho compilato il kernel 3.6.11, visto che la compilazione è finita senza errori ho applicato la patch per il real time e ho ricompilato, ci sono volute quasi due ore e venti minuti in Qemu. Ho provato a usare il kernel rt compilato per fare il boot da Qemu e non funziona.
Ma l'ho fatto molto velocemente, è la prima volta che gioco con Qemu e la raspbian come distribuzione non mi fa impazzire, domani provo a ricompilare togliendo l'ottimizzazione per ridurre al massimo le dimensioni e vedo se così fa il boot. Se non funziona provo a compilare con l'opzione "basic realtime" invece che "full realtime", male che vada, a mali estremi, estremi rimedi, ci provo da una Slackware ARM
Poi, una volta che ho un kernel che fa il boot da Qemu vi faccio sapere, non trattenete il fiato però, potrebbe volerci qualche giorno.

fritznet ha scritto:Andrea, prendila come suggestione "volante", ma mi pare di avere capito che con baudline si possa misurare anche il jitter, potrebbe essere utile nel caso si vogliano testare due versioni diverse (kernel Rt e non, altro etc).
Poi bisogna vedere se si riesce ad utilizzare attraverso Qemu, trattandosi di flussi digitali non dovrebbero esserci problemi, stante anche la flessibilità di Baudline, spero di poter approfondire questo aspetto per cavarci qualcosa.

Fra l'altro anche lo sviluppatore di Baud. menzionava tempo fa via twitter qualche problema o baco inerente il driver USB linux, se riesco a ripescare l'argomento lo posto, sperando possa essere utile.

Se trovi il riferimento al baco leggo volentieri.
Misurare il jitter su Qemu temo non sia significativo, nel senso che poi su Raspberry i risultati potrebbero essere diversi (anche perché Qemu gira a sua volta su un sistema operativo non real time). Però se fosse possibile misurare il jitter con baudline sarebbe molto interessante.

C'è un'opzione di avvio per Baudline ( -debugjitter ) che stampa i valori di Jitter... direttamente su terminale

A quanto pare non c'è modo di ridirigere questi dati in Baudline, forse si può ricavare qualcosa tramite gnuplot, che non conosco.

Non vorrei toppare anche questa , ma forse RMAA Rightmark audio analyzer consente di misurare il jitter, ovviamente non via emulazione, e ovviamente non installandolo su un un raspify, quindi fisicamente solo via DAC, a quel punto non so se abbia senso.


Quella del bug nel driver USB è un pò una sua sparata (su twitter:I just proved that the Linux USB audio driver is broken), nel senso che la mette in relazione ad una misura sballata di una scheda che sotto MaCOS non dà lo stesso problema, si ripromette di approfondire, ma il primo e l'ultimo post sull'argomento è del giugno2011

ti linko comunque la pagina:

http://baudline.com/solutions/full_duplex/edirol_ua25/index.html#MacOSX

E' nel paragrafo frequency domain.

scusate se continuo a rompere in un thread sul raspberry con domande su altri dispositivi

Che ne dite dell'hackberry? Costa il giusto e sembra più potente. Soprattutto spero non sia limitato come il PI nella condivisione dell'USB con l'ethernet
Ci si potrà mettere qualche distro linux per un audio su USB di qualità?

fritznet ha scritto:C'è un'opzione di avvio per Baudline ( -debugjitter ) che stampa i valori di Jitter... direttamente su terminale

A quanto pare non c'è modo di ridirigere questi dati in Baudline, forse si può ricavare qualcosa tramite gnuplot, che non conosco.

Se li stampa a console si possono ridirigere su file aggiungendo alla riga comando " > baudline.log 2>&1 "
(ridirige i "flussi" standard stdout e stderr, cioé tutto quello che normalmente compare a console, sul file baudline.log).
Per usare baudline su Raspberry però bisogna compilarselo (se possibile) a partire dai sorgenti disponibili, cioé quelli della vecchia versione 0.99, i sorgenti dell'ultima versione non sono disponibili.

Quella del bug nel driver USB è un pò una sua sparata (su twitter:I just proved that the Linux USB audio driver is broken), nel senso che la mette in relazione ad una misura sballata di una scheda che sotto MaCOS non dà lo stesso problema, si ripromette di approfondire, ma il primo e l'ultimo post sull'argomento è del giugno2011

ti linko comunque la pagina:

http://baudline.com/solutions/full_duplex/edirol_ua25/index.html#MacOSX

E' nel paragrafo frequency domain.

Interessante, grazie. Chissà se poi ha verificato se il problema è stato risolto.

Menestrello ha scritto:scusate se continuo a rompere in un thread sul raspberry con domande su altri dispositivi

Che ne dite dell'hackberry? Costa il giusto e sembra più potente. Soprattutto spero non sia limitato come il PI nella condivisione dell'USB con l'ethernet
Ci si potrà mettere qualche distro linux per un audio su USB di qualità?

Sembra interessante e al momento chi l'ha provato, con Linux, non ha riscontrato problemi (https://www.tforumhifi.com/t31881-hackberry), sarebbe interessante fare qualche prova sotto carico leggendo flac da un disco USB collegato mentre si genera un po' di traffico di rete sostenuto.

Intorno a quella cifra si trovano anche dei dual core e dei quad core (se le descrizioni sono veritiere) la cui qualità è tutta da verificare, giusto qualche esempio:

http://dx.com/p/gk802-quad-core-android-4-0-google-tv-player-w-wi-fi-bluetooth-v4-0-1gb-ram-8gb-rom-black-177875
http://dx.com/p/mx1-dual-core-android-4-1-1-google-tv-player-w-bluetooth-1gb-ram-8gb-rom-tf-hdmi-red-173684
http://dx.com/p/mk808-dual-core-android-4-1-1-google-tv-player-w-1gb-ram-8gb-rom-wi-fi-tf-hdmi-160535
http://dx.com/p/mk808-cortex-a9-1-6ghz-dual-core-android-4-1-mini-pc-w-8gb-memory-measy-rc11-air-fly-mouse-174436

Ci sarebbe anche questo...
http://www.ebay.it/itm/MELE-A1000-TV-BOX-Full-HD-Internet-Media-Player-Android-4-0-4GB-Memory-WIFI-HDMI-/300764022495?pt=LH_DefaultDomain_0&hash=item4606eec6df

Ragazzi, ho la seconda release di raspyfi che sta suonando in questo momento... A me sembra ci siano già dei miglioramenti sostanziali, ma potrei essere non troppo obiettivo nel giudizio
Purtroppo ci sono ancora dei problemi con i flac a 96 k senza il resampling... Ancora qualche giorno di test e tweaks vari e poi la butto fuori.... Switters sei un grande!

ps: la distribuzione installata occupa 920 mega, ottimo!
pps: ma come cavolo facciamo a sapere a cosa e dovuto questo stuttering con i flac a 96? Ora proverò a overcloccare il pi e vedere che succede, l'unica cosa che ho capito è che l'uso cpu schizza al 12% invece del 3% di quando suona i file in formato redbook...

Giusto per confermare la mia esperienza, hai provato anche con file 16/48?

romvise ha scritto:Giusto per confermare la mia esperienza, hai provato anche con file 16/48?

Non ne ho, ora ne trovo qualcuno e lo provo...

Vabbè...

ho comprato l'hackberry, tanto se dovesse andar male come player audio lo utilizzerò in qualche altro modo


Vi continuero a seguire anche sul raspberry perché il discorso è comunque molto interessante

Menestrello se capiti in centro a Firenze e vuoi sentire l'accoppiata raspyFi + ODAC sei il benvenuto eh!

mikelangeloz ha scritto:Menestrello se capiti in centro a Firenze e vuoi sentire l'accoppiata raspyFi + ODAC sei il benvenuto eh!

Per lavoro vengo in treno a Rifredi tutti i gi orni

Una volta vengo a sentire il tutto molto volentieri

Non so se può essere utile, non ne capisco una mazza, vedete voi. http://www.my-lab.it/Jackd_Raspberry_Real_Time_Audio

De simone Biagio ha scritto:Non so se può essere utile, non ne capisco una mazza, vedete voi. http://www.my-lab.it/Jackd_Raspberry_Real_Time_Audio

Grandissimo Biagio!!! Stavo proprio cercando jack per il Pi! Grazie!!!

mikelangeloz ha scritto:

De simone Biagio ha scritto:Non so se può essere utile, non ne capisco una mazza, vedete voi. http://www.my-lab.it/Jackd_Raspberry_Real_Time_Audio

Grandissimo Biagio!!! Stavo proprio cercando jack per il Pi! Grazie!!!

e di che? Na botta di cubo allora.

@mikelangeloz

Che versione del kernel c'è nella raspyfi ?
Riesci a postare il risultato di "cat /proc/config.gz" del tuo Raspberry?

Le prove di compilazione procedono ma il fatto di non avere un Raspberry complica un po' le cose, il kernel per Raspberry e Qemu sono bestioline un po' diverse, quindi non è detto che anche qualora riesca a fare il boot in Qemu poi il kernel funzioni su Raspberry