Llegó el RAPSBERRY PI - ¡Qué cosa más increíble!

MAFREGA escribió:Yo mas bien me inclino por la cubieboard y android, es un poco mas potente, poco mas, pero lo que me hace decidir es la salida spidf, creo que la raspberry no la trae. Estoy mirando precios y proveedor, seguramente no acabe la noche sin encargarla.

Saludos y gracias

La Cubi tiene salida spdif, pero la Raps tiene I2S, aunque por desarrollar o en desarrollo. Hay un hilo en el foro donde hablan de ello.

De todas maneras, la salida spdif de la Cubi supongo que será con nivel TTL. Ello implica que tienes que atenuarla con un divisor de tensión.

Saludos

Más alternativas (como reproductor de audio): Raspyfi.

http://www.raspyfi.com/

Se trata de una distribución Linux extremadamente ligera que tiene como objetivo convertir a la Raspberry en un servidor MPD. La imagen del SO completo cabe en una SD de 2GB y arranca en muy poco tiempo (mucho más rápido que las distros de XBMC).

Una vez arrancada esto es todo lo que aparece en pantalla:




Ahora se trata de conectarse por ssh a la Raspberry para configurar el archivo fstab de modo que MPD se conecte automáticamente a una carpeta compartida que tengamos en red (en rojo la línea que monta la carpeta compartida de música en mi NAS):


A partir de ese momento hay que controlar el servidor / reproductor MPD a distancia utilizando cualquiera de las aplicaciones disponibles, como por ejemplo MPOD / MPAD en iOS (que por cierto está muy chula):



Raspify está pensada para utilizar un DAC USB. No emite sonido por HDMI, aunque creo que es posible conseguirlo tocando un poco los módulos del kernel que carga al arrancar (no lo he intentado Efectivamente, ahora mismo estoy reproduciendo audio de hasta 192/24 por HDMI, aunque remuestreando a 48/16 ). Para probar he utilizado una interfaz USB Edirol UA25. He tenido que configurarla utilizando los interruptores traseros en modo simple a 44/16. A 96Khz el audio petardea o se reproduce a la velocidad incorrecta (más sobre esto más abajo).

Vamos con lo bueno y lo malo:

Lo bueno:
- Arranca muy rápidamente.
- Compatible con muchos DACs USB sin necesidad de drivers.
- Escanea la biblioteca musical a la que se conecta en red en segundos (no descarga info de Internet como XBMC, simplemente cataloga el contenido de las carpetas que se le indica).
- Por defecto cataloga, además, cualquier unidad de almacenamiento conectada a los puertos USB. Muy práctico.
- Soporta reproducción sin pausas.
- El control con apps como MPOD es una gozada.
- Compatible, en principio, con gran cantidad de formatos de audio, incluído DFF.
- En un proyecto efervescente, de hecho la próxima versión, con numerosas mejoras, está al caer.

Lo malo:
- Hay que meterle mano a la línea de comandos para hacer que apunte a nuestra biblioteca.
- En mi caso ha sido tiquismiquis con el DAC: Lo he tenido que configurar a 48Khz o sonaba mal.
- Cualquier cosa por encima de 48Khz no se reproduce correctamente (se entrecorta). No parece problema de CPU. Creo que tiene solución activando el modo de remuestreo (poco deseable), pero no lo he intentado. Efectivamente se soluciona, aunque sigue habiendo un pequeño corte al comienzo de los temas a 176 o 192Khz. De 96Khz hacia abajo se reproducen correctamente.
- Con mi DAC ha sido necesario volver a alimentar a la Raspberry con un adaptador de corriente de 1A. El puerto USB del receptor no suministraba suficiente corriente para alimentar a ambos (no es que sea un problema realmente).

Y ahora lo peor, que no es una deficiencia específica de esta distro sino de la Raspberry en general. Parece ser que existen problemas graves, sin resolver hasta el momento, con el driver que controla el bus USB a nivel de firmware. Se pierden paquetes de datos aleatoriamente. El problema es más acusado en escenarios con una elevada tasa de uso de la CPU y, atención, con frecuencias de muestreo superiores a 48Khz... hasta el punto de hacerlas inutilizables hoy por hoy y hasta donde yo sé .



Además, la red ethernet está implementada sobre el bus USB interno, lo que hace que este problema también afecte a la transmisión de datos (quizás esto tenga algo que ver con el fenómeno de buffering que se manifiesta en XBMC):

http://www.raspyfi.com/anatomy-of-a-pi-usb-audio-quality-and-related-issues-on-pi/

3) The Foundation has discovered that the controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, etc..
...
For the time being though, USB and networking (which is implemented over USB) have a large catalogue of issues and incompatibilities. All boards have this inherent problem but YMMV on whether the issues bite you, as it depends on exactly what devices you have connnected and what you’re doing with the board.

C*jonudo, un problema que afecta a la transmisión de datos de todas las Raspberry y que encima puede aparecer o no y con diferentes intensidades dependiendo de múltiples factores.

No está claro que tenga arreglo, por increíble que parezca. Hay gente tratando de compilar un Linux con núcleo en tiempo real para resolucionarlo, pero de momento...

Hola

De todas maneras, la salida spdif de la Cubi supongo que será con nivel TTL. Ello implica que tienes que atenuarla con un divisor de tensión.

Pero crero que Ignasi si la ha probado directamente desde los pins 40/41 del slot de expansion y no ha tenido problema, Ignasi....? puedes aportar algun dato a esta observacion de hifiliberator....

GRACIAS

Yo había conectado la salida SPDIF directamente con cable coaxial a la entrada del DAC, sin que aparezcan síntomas de saturación, ni ruidos o artefactos.
Como no soy tan experto como HiFi o Pablo, he consultado la cuestión en los foros de Cubieboard, y parece que, efectivamente, la salida SPDIF no es de nivel TTL, sino que está preparada para atacar directamente la entrada coaxial del DAC. De todas formas, la confirmación de este punto no es "oficial" de Cubieboard, es la contribución de un forero.

Hola

Gracias por la info Ingnasi, haber si me llega pronto y empiezo a probar.

Saludos

Yo sigo con mis pruebas...

Esta tarde he instalado las licencias de decodificación en hardware para mpeg2 y vc-1. Las primeras pruebas han sido totalmente decepcionantes:

- No he podido reproducir correctamente ninguna ISO de DVD (he probado 3). Aparece el menú y demás pero o bien la navegación no funciona o bien pantalla en negro al tratar de reproducir la película en sí. Parece un problema de las funciones de navegación en los DVD.

- Los m2ts y estructuras de bluray de cierto tamaño con codificación mpeg2 y AVC (h264) tironean que da gusto a partir de bitrates de unos 30Mbps. El Hobbit, que funcionaba OK, tiene unos 27Mbps. no he probado nada con codificación VC-1. Tampoco he probado a reproducir desde un dispositivo de almacenamiento local.

Lo he dejado estar para cenar y volver al tema hace un rato. Me he encontrado con la sorpresa de que la SD con Xbian ya no arranca . Tiene toda la pinta de que la tarjeta se ha corrompido, probablemente como consecuencia del overclocking.

Esto va a peor .

Voy a probar con otra distribución de XBMC (Raspbmc) e instalando en un pendrive USB, a ver qué tal.

Chicos, tengo novedades...

Llevo un rato dándole vueltas a todo esto, ahora con Raspbmc arrancando desde una SD pero ejecutando XBMC desde un pendrive. Los archivos con los que estoy probando que me tironean o provocan detenciones para rellenar el buffer son estos:




Para que os hagáis una idea, mi HTPC (Pentium Dual Core E5500@3,2Ghz) tiene problemas con el primero en algunas escenas reproduciendo con JRiver Media Center y el motor de vídeo de alta calidad Red October HQ / madVR.

0. Antes de comenzar he desactivado todos los servidores de XBMC, incluyendo el cortafuegos y ssh desde la aplicación de control de Raspbmc.

1. Primero que nada he activado el motor de sonido AudioEngine. Nada, ni positiva ni negativamente. El audio en HD sigue sin llegar al receptor. De paso he podido comprobar que los FLAC a 192/24 también siguen sin funcionar a pesar de que AE debería soportarlos.

2. Después he probado tanto la última nightly build de Raspbmc (del 3 de mayo, si mal no recuerdo) como la muy preliminar versión basada en XBMC 13 (nada recomendable, le faltan incluso numerosas opciones de configuración críticas en el menú). Nada, todo igual (o peor).

3. A continuación he hecho un overclocking manual por encima del perfil Super de Raspbmc, llevando el núcleo ARM a 1Ghz y la GPU a 450Mhz (no me atrevo a ir más allá sin algún elemento adicional de refrigeración). El sistema parece estable, pero seguimos igual.

4. He combinado las 3 anteriores, pero de nuevo sin resultado.

5. Lo siguiente ha sido montar el recurso compartido donde tengo las pelis a nivel del Linux que hay por debajo de XBMC usando nfs. Para ello he activado el acceso por SSH y he modificado el archivo /etc/fstab, añadiendo al final esta línea:

192.168.1.100:/mediateca /media/mediateca nfs _netdev,defaults,user,auto,noatime,intr 0 0

Ahora basta con añadir en el apartado de vídeo la carpeta en red correspondiente, que aparecerá colgada del sistema de archivos local en /media. Se añaden fuentes siguiendo el procedimiento habitual en XBMC y listo.

¡¡¡Bingo!!! Ya no se vacía el buffer... pero de modo aleatorio el vídeo sigue perdiendo fluidez y se reproduce a trompicones.

6. A continuación he desactivado la sincronización con el barrido vertical en:

XBMC > Ajustes > Sistema > Salida de vídeo > Sincronizar con refresco vertical

Manteniendo estos parámetros:

XBMC > Ajustes > Vídeo > Reproducción > Ajustar frecuencia de refresco con la del vídeo > Al empezar / parar
XBMC > Ajustes > Vídeo > Reproducción > Sincronizar reproducción con el monitor > Activado
XBMC > Ajustes > Vídeo > Reproducción > Método de sync AV > Reloj de vídeo (Audio Drop/Dupe)

¿El resultado? Estos archivos se reproducen perfectamente, sin un leve tirón y por supuesto nada de buffering . Me he fijado para ver si percibía algún tipo de tearing como consecuencia de la desactivación del sincronismo vertical, pero nada de nada. La imagen es estable como una roca y la suavidad y la calidad de imagen son impresionantes.

7. Para finalizar he regresado a Raspbmc estable (no estoy seguro de que sea la 12.1 o la 12.2) y he bajado el overclocking al perfil Super. Mantengo activado únicamente el servicio de control remoto, deshabilitando incluso ssh, que ya no es necesario.

He estado reproduciendo los BDRemux más gordos que tengo durante periodos de 5 - 10 minutos, avanzando, retrocediendo en la reproducción, etc. con un resultado 10/10. La prueba del algodón será ver una peli de estas entera, a ver qué tal se comporta en régimen permanente. También me gustaría reducir un poco el nivel de overclocking porque ahora mismo la CPU / GPU anda ya a 76º.

Ya me contaréis qué tal os funcionan estos ajustes en vuestras Raspberrys, si es que queda alguien ahí afuera con una . Por mi parte tengo que reconocer que mi opinión sobre este aparatejo como plataforma de reproducción de vídeo con XBMC ha cambiado considerablemente... si este comportamiento se confirma, claro está. Quedan aspectos por mejorar, pero por lo que cuesta no se puede pedir más.

vaya curro Pablo, , encaminando al Yoda de la pi...

reconozco que el aparato es interesante pero me produce cierta inapetencia... no se que me pasa, antes hubiera saltado sobre uno. Me estaré haciendo viejo o es que no le veo el coste/beneficio justificable como no sea el de trastear por hobby ?

jsc010 escribió:
reconozco que el aparato es interesante pero me produce cierta inapetencia... no se que me pasa, antes hubiera saltado sobre uno. Me estaré haciendo viejo o es que no le veo el coste/beneficio justificable como no sea el de trastear por hobby ?

Gracias, Jaime,

La verdad es que desde el viernes pasado por la noche llevo 2 o 3 buenas sesiones de madrugada con ella . El aparatito me ha quitado (literalmente) el sueño.

Pues sí, si no hay un interés digamos "deportivo" en ella o piensas utilizarla en educación o en algún proyecto de esos tan chulos que están surgiendo cuesta escogerla como reproductor AV a la vista de lo baratas que son propuestas de Xtreamer, WDTV o Asus. El hecho es que si instalas XBMC sobre el aparatito de serie su rendimiento como reproductor solo es bueno con archivos de tamaño moderado, por lo que yo sólo lo recomendaría con ciertas reservas.

Eso sí, es un juguetito que a mi por lo menos me crea cierta adicción y para los que no hayan usado Linux nunca puede ser una muy buena manera de familiarizarse con este SO a nivel de geek e ir aprendiendo cositas.

Es curioso porque cuando los compañeros comentaban sobre ella en los inicios del hilo yo era escéptico con la rpi como reproductor de vídeo pero menos quizás en su faceta de audio. Ahora me pasa justo lo contrario: Aunque XBMC puede ser un buen reproductor de audio, siendo compatible con flac a 96/24, me desanima el hecho de que no soporte reproducción sin pausas. Por otra parte la distro específica que he probado basada en mpd, Raspyfi, solo funciona bien remuestreando a 44/16 o 48/16, tanto con el DAC usb con la que la he probado como, tras modificarla para que emita por hdmi, con mi receptor.

Por cierto, Jaime, aprovecho para hacerte una consulta relacionada con MPD:

Como decía antes modifiqué un poco Raspyfi para hacer que emitiera audio por HDMI. El caso es que tuve que tocar mpd.conf y pude comprobar que existe un ajuste que le dice a MPD a qué formato debe remuestrear el audio. Eliminé esa línea tanto en la subsección correspondiente al dispositivo de audio general como en la que afecta a todos los reproductores:

Código:

audio_output {
    type        "alsa"
    name        "My ALSA Device"
    device        "hw:0,0"    # optional
#  format        "44100:16:2"    # optional
    mixer_device    "default"    # optional
    mixer_control    "PCM"        # optional
    mixer_index    "0"        # optional

# Force all decoded audio to be converted to this format before
# being passed to the audio outputs.
#
#audio_output_format "44100:16:2"
}

Al hacerlo la salida por HDMI se producía a 44Khz para rips de CD y a 48Khz para el resto, tocando un supuesto límite superior del hardware (que ya sabemos que alcanza ahora mismo 96Khz y en teoría debería llegar a 192). Poner algo como format "88200:24:2" tampoco sirvió de nada, el techo seguía en 48Khz. De todos modos el remuestro que hace aquí MPD parece ser uno rápido y no sé hasta qué punto la rpi aguantaría uno de mayor calidad, por lo que la idea era no remuestrear.

También modifique algunos parámetros relacionados con el audio HDMI a nivel de opciones de arranque de la RPi, pero sin éxito.

Quizás con pulse hubiera tenido más suerte, no sé.

¿Existe algún otro "interruptor general" en MPD que he pasado por alto?

te comento como lo tengo en osx.

efectivamente menos es mas en el caso de las opciones que uso en mpd, emho.

elimino los parametros format y los mixer_etc y dejo solo mixer_type = disabled

esto es simplemente que no use el mezclador de mpd y utilice el especificado por type (osx en mi caso, alsa en el tuyo)

lo puedes verificar. desde mpod no deberías poder controlar el volumen de la cancion si estas con mixer_type = disabled , en mi caso manda el coreaudio y la configuracion que esté puesto en el Audio Midi Settings.

Aunque no estoy puesto en linux puro, entiendo que alsa es de mas bajo nivel y pulse se apoya sobre alsa (o el controlador de bajo nivel que corresponda), no se si ganarías algo pero puedes probar.

jsc010 escribió:
elimino los parametros format y los mixer_etc y dejo solo mixer_type = disabled

esto es simplemente que no use el mezclador de mpd y utilice el especificado por type (osx en mi caso, alsa en el tuyo)

lo puedes verificar. desde mpod no deberías poder controlar el volumen de la cancion si estas con mixer_type = disabled , en mi caso manda el coreaudio y la configuracion que esté puesto en el Audio Midi Settings.

Con el DAC USB no podía controlar el volumen, curiosamente por HDMI sí (por cierto que es una pasada definir varios players en el mismo dispositivo y conmutar de uno a otro desde MPOD, por ejemplo uno sin remuestreo y otro con él activado, uno por HDMI y otro por usb, etc. etc.).

Haré algunas pruebas más cuanto haya terminado con XBMC. Si te parece te consulto por privado para no enturbiar el hilo.

Pues sí, si no hay un interés digamos "deportivo" en ella o piensas utilizarla en educación o en algún proyecto de esos tan chulos que están surgiendo cuesta escogerla como reproductor AV a la vista de lo baratas que son propuestas de Xtreamer, WDTV o Asus

Completamente de acuerdo.

Pero la gracia del asunto es que es configurable y manipulable, cosa que no se consigue con los reproductores de marca. Visto el precio que tienen y las horas de entretenimiento que generan, el precio/hora de distracción es imbatible.

pablopi escribió:
Con el DAC USB no podía controlar el volumen, curiosamente por HDMI sí (por cierto que es una pasada definir varios players en el mismo dispositivo y conmutar de uno a otro desde MPOD, por ejemplo uno sin remuestreo y otro con él activado, uno por HDMI y otro por usb, etc. etc.).

Haré algunas pruebas más cuanto haya terminado con XBMC. Si te parece te consulto por privado para no enturbiar el hilo.

Di que sí, y si no preguntale a punkylex, que estuvimos haciendo pruebas con los dac mytek, bryston y fireface 400, todo al mismo tiempo y en tiempo real controlado por mpd. la locura! y una pasada para comparar equipos.

Ignasi L escribió:
Pero la gracia del asunto es que es configurable y manipulable, cosa que no se consigue con los reproductores de marca. Visto el precio que tienen y las horas de entretenimiento que generan, el precio/hora de distracción es imbatible.

Tienes toda la razón, Ignasi.

He resumido en un nuevo hilo los pasos que he seguido para instalar y configurar XBMC en la RPi:

https://www.audioplanet.biz/t41295-xbmc-en-la-raspberry-pi-al-99-en-60-y-2-cafes-guia-de-instalacion

Creo que me espera otro raspbérrico fin de semana:

http://www.raspyfi.com/raspberry-pi-usb-audio-fix/

Now, play and enjoy! Files >44/16 will be played without glitches, and I hope that async dacs will work flawlessly as well! I cannot confirm this by now since I don’t have any async to the test this Raspberry Pi usb audio fix for them… But please let me know via comments below.

Parece que se han solucionado los problemas con el bus usb y ahora ya es posible conseguir audio bitperfect a mayores frecuencias de muestreo. La próxima versión de Raspyfi ya llevará la modificación implementada de serie.

Hola

A raiz de este hilo he decidido probar una cubieboard.

Mientras me llega, estoy haciendo algunas pruebas con un tablet androd y y un smartpohone android, he instalado XBMC en el tablet y tambien en el mac. En el movil estoy probando algunas app para remotear el XBMC tanto del tablet como del mac, yaste - xbmc remote de los propios desarroladores de xbmc y xbmc remote de otro desarrolador, hasta aqui todo bien, desde el movil puedo manejar tanto uno como otro XBMC.

Mi problema viene de antes yo creo, he acabado de digitalizar mi coleccion con Itunes en .aiff todo orenado por autor/disco/cancion y genero, me he pasado un tiempo bastante considerable clasificando y repasando que todo este dentro de un orden con todas las caratulas y demas.
Ahora me encuentro que XBMC, por lo que he indagado, no importa la bilblioteca de itunes, por lo que adios a la clasificacion por autor, genero y demas, solo puedo ver el direcctorio de carpetas y subcarpetas.

Hay alguna solucion razonable a esto?

Quizas algun programa que si importe la biblioteca con los metadatos de itunes y desde este lo pueda exportar para que XBMC lo reconozca?

Saludos

La metadata no depende del reproductor sino del formato. Vamos ... eso creo yo. Si XBMC reconoce AIFF debería reconocer su metadata. Si no reconoce AIFF tendrás que pasarlo a otro formato. Con el dbpoweramp batch converter, si lo tienes todo bien ordenadito, lo puedes hacer de una tacada.

Saludos y suerte

Hasta donde se, AIFF no soporta tags de metadata como Flac y Alac, que si lo llevan inserto dentro de los archivos.

Creo que es el itunes el que mantiene una base de datos con la metadata y es él el que que relaciona con el archivo aiff. Sorry.

Una solucion posible, es usar el mismo Itunes para que convierta todo a Alac. Mirar primero si lo soporta XBMC al Alac, me da que sí.

Estrictamente hablando los metadatos forman parte del propio formato pero existen reproductores que mantienen su propia base de datos de manera que la información es externa a los propios archivos. Ambas estrategias no son excluyentes, por ejemplo Jriver y XBMC hacen ambas cosas.

En el caso de XBMC hay que activar el modo de biblioteca. Para ello se pincha con el botón derecho del ratón (supongo que pulsación larga en Android) sobre la carpeta raíz que contiene toda la música y se selecciona escanear (o algo así, no recuerdo exactamente ahora mismo). XBMC se pondrá a analizar los archivos dentro de esa biblioteca y, además, buscará información extendida en Internet (carátulas, reviews, etc.) utilizando un scraper que, si mal no recuerdo, es allmusic de modo predeterminado. El proceso puede ser largo. A partir de ese momento XBMC vigilará las carpetas, del mismo modo que hace Logitech Media Server, para detectar cambios. Si existen tags en los archivos son extraídos y almacenados en una base de datos que maneja el propio XBMC. Esto hace que aunque el formato empleado no admita tags realmente sí se pueda clasificar correctamente la biblioteca.

http://wiki.xbmc.org/index.php?title=Music_Library

Luego solo queda activar la vista de biblioteca en el panel de opciones lateral. Esto modificará también el menú principal de XBMC para, bajo la sección correspondiente a la música, mostrar accesos por género, autor, un panel con los elementos recientemente añadidos, etc. etc. Muy chulo. Pego algunas capturas del hilo de XBMC en la RPi:





Mi experiencia es que funciona estupendamente bien, aunque en mi biblioteca solo hay mp3, alac y flac. Yo utilizo iTunes para etiquetar, poner carátulas, asignar géneros, etc. y toda esa información llega perfectamente a XBMC. Si el formato empleado no soporta metadatos (que yo sepa AIFF sí soporta tags ID3, aunque es posible que no todas las aplicaciones puedan manipularlos) y la información está almacenada en la propia base de datos de iTunes XBMC no podrá leerla y tendrá que retaguear (fea palabra) utilizando su propio scraper.

Si aiff soporta tags deben ser tan especificos y poco estandarizados que ni foobar o mp3tag son capaces de leerlos.

Convertí un archivo a aiff para probar y no me permite agregar metadatos, ni editar.

jsc010 escribió:Si aiff soporta tags deben ser tan especificos y poco estandarizados que ni foobar o mp3tag son capaces de leerlos.

Convertí un archivo a aiff para probar y no me permite agregar metadatos, ni editar.

Yo acabo de hacer lo mismo con el dbpoweramp y no sólo me conserva la metadata sino que me deja editarla. Así que sigo pensando lo dicho anteriormente, como mejor solución al problema del compañero

DrFunk escribió:

jsc010 escribió:Si aiff soporta tags deben ser tan especificos y poco estandarizados que ni foobar o mp3tag son capaces de leerlos.

Convertí un archivo a aiff para probar y no me permite agregar metadatos, ni editar.

Yo acabo de hacer lo mismo con el dbpoweramp y no sólo me conserva la metadata sino que me deja editarla. Así que sigo pensando lo dicho anteriormente, como mejor solución al problema del compañero

Pues llevas razon, esta version de foobar ya soporta tags de Aiff.

1.2.5
AIFF file format tagging support.

Vuestra devoción por foobar me empieza a preocupar ja ja ja