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

Cada vez duermo menos, Ignasi, o eso o solo quedan las responsabilidades.

Tengo que confesar que me parece sorprendente que XBMC pueda correr sobre algo tan pequeñito. El problema es que hay muchos archivos de vídeo que no funcionan lo suficientemente bien y otras cosas están simplemente rotas: la reproducción de ISO de DVD, soporte de DACs USB, FLAC multicanal, etc. etc.

Es mosqueante... me he atrevido a reproducir un remux de El Hobbit de casi 40GB y funcionaba perfecto, sin DTS-MA, pero por lo que hace al vídeo muy bien... hasta cosa de pasados 30 - 60s, cuando la reproducción deja de ser fluida, no me explico por qué.

pablopi escribió:
...
(no tengo remedio, Enrique):

....

Que no hombre que no que es broma ... que si no fuese por gente como los que, en este hilo, os habéis atrevido a probar cosas nuevas no tendriamos de que hablar. Personalmente os estoy agradecido a todos los que ponéis vuestro dinero para intentar cosas nuevas y además nos regaláis con vuestras experiencias

Más pruebas nocturnas y varios problemas resueltos...

Primero que nada anoche descarté que los cortes momentáneos en la reproducción fueran debidos a un problema de insuficiencia de datos de la red. Para ello conecté un portátil y probé a copiar desde el NAS un archivo gordo:




Los cacharros de la sala están conectados por cable a un pequeño switch de 100Mpbs, por lo que una tasa de transferencia de casi 11 Mbytes / segundo es perfectamente razonable y muy superior en todo caso a la requerida para reproducir cualquier cosa.

Sigamos.

Con respecto a la calidad de imagen, con menos luz en la habitación me parecía que se veía excesivamente brillante. No he encontrado documentación ni ajuste que lo pruebe, pero estoy casi seguro de que la salida HDMI de la Raspberry está configurada en un espacio de color RGB en lugar de YCbCr, que es lo usual en reproductores de vídeo. Cuando reproductor y visualizador manejan espacios de color distintos el resultado suele ser el de una imagen quemada en blancos (brillo excesivo) o con un "colapso de negros" (pérdida de detalle en sombras). Jugando con los parámetros de la tele el problema se solucionó (Color HDMI bajo). Al establecerlo de este modo la imagen ha pasado a ser mucho más satisfactoria hasta el punto de que no me atrevo a hablar de una peor calidad de imagen comparando con otros reproductores, al menos en la tele a la que lo he conectado, que es de 37".

El problema que más me molestaba no tenía que ver con los momentos en los que se detenía la reproducción para rellenar el buffer, sino con la pérdida de suavidad continuada de la reproducción en instantes aleatorios (como si de repente se reprodujera a 12 fotogramas en lugar de a 24). Esto ocurría en casi todos los archivos de cierto peso y de un modo no vinculado, aparentemente, con una pausa por vaciado de buffer. La solución hay que buscarla en los ajustes de sincronización de AV de XBMC, de hecho recuerdo que me pasó algo parecido con el HTPC que le configuré a un amiguete hace tiempo con un hardware de PC relativamente sencillo:

XBMC > Ajustes > Vídeo > Reproducción > Método de sync AV



(del wiki de XBMC):

Audio has to stay in sync, this can either be done by resampling, skipping/duplicating packets, or adjusting the clock if it gets out of sync too far. Resampling has the advantage that the speed of the video can be changed considerably, so 24 fps can be sped up to 25 fps to play at PAL speed. The disadvantage of resampling is that it doesn't work with passthrough, and there is a slight loss of audio quality. Skipping/duplicating audiopackets has no loss of audio quality, but the speed of the video can only be changed a little to avoid doing a skip/duplication too often, most of the time it's inaudible, but it can produce a very audible click. Adjusting the clock has the best audio quality, but some extra video jitter can occur, also the speed of the video can't change much, as the audio will sync the clock more often the more the speed of the video is changed.

Hay que ajustarlo al valor Video Clock(Drop/Dupe Audio)

Y por supuesto hay que ajustar adecuadamente:

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 dispositivo de visualización > Activado
XBMC > Ajustes > Sistema > Salida de vídeo > Sincronizar con refresco vertical

Con los ajustes anteriores (y la conexión a la Mediateca utilizando NFS) han desaparecido totalmente los tirones y tan solo me encontré con un leve problema en una secuencia muy movida del BDRemux del Hobbit (40GB, como os decía), reproduciendo con el ajuste de overclocking en alto. Pasando al modo turbo la misma secuencia se reproduce sin problemas y en los primeros 30 minutos no hay ni rastro de tirones ni de vaciados de buffer. Muy bien, que esto se reproduzca con suavidad hace pensar que cualquier cosa lo hará, siempre y cuando se pueda hacer en hardware de la GPU ya que la CPU simplemente es muy, muy limitada.

Hoy compraré la licencia de mpeg2 para ver qué tal funcionan los DVD.

Una última cosa: la versión de la distro (XBian 1.0 Alpha 5) está basado en XBMC 12.0... llevan 2 versiones de retraso ya sobre el desarrollo principal. Esperemos que se pongan al día pronto.

Hola

Alguno de los que ya las teneis y estais probando no tendreis una unidad de cd/dvd por USB para conectar y ver como se comporta, haber si es posible ripear cd con XBMC.

Saludos

MAFREGA escribió:

Alguno de los que ya las teneis y estais probando no tendreis una unidad de cd/dvd por USB para conectar y ver como se comporta, haber si es posible ripear cd con XBMC.

Yo tengo uno, lo pruebo y te digo algo.

Por cierto, ¿alguien ha pensando en incluir un interruptor de encendido / apagado? Creo que se podría alimentar de uno de los USB de la tele o quizás incluso del receptor multicanal, pero me da bastante yuyu ir apagándola a lo burro.

pablopi escribió:

MAFREGA escribió:

Alguno de los que ya las teneis y estais probando no tendreis una unidad de cd/dvd por USB para conectar y ver como se comporta, haber si es posible ripear cd con XBMC.

Yo tengo uno, lo pruebo y te digo algo.

Nada, no hay suerte. No monta ni DVDs ni CDs. Además aparecen errores si entras por ssh a la Raspberry y haces un dmesg para ver los mensajes que da el kernel del Linux que ejecuta. Quizás no le guste mi unidad .

Algunos datos adicionales como reproductor de audio (con XBMC):

- 7 horas para catalogar unos 300GB de archivos de audio (busca info en Internet de cada álbum). Temperatura de CPU y GPU llega a alcanzar los 82º (peligroso) con el overclocking al máximo. Aquí se nota la falta de potencia de la CPU.
- Los FLAC en multicanal suenan en estéreo.
- Los FLAC a 176 y 192 se escuchan mal.
- Los ALAC en 88/24 o superior se reproducen a 44/16.
- Los WAV en DTS no se reproducen (silencio).
- No soporta reproducción sin pausas (gapless ).
- Se controla perfectamente a ciegas con apps como Constellation o Yatse.
- Suena estupendamente.

Por cierto que se alimenta perfectamente de la conexión USB del receptor multicanal.

Vamos a ver qué se puede hacer con Raspify...

Nada, no hay suerte. No monta ni DVDs ni CDs. Además aparecen errores si entras por ssh a la Raspberry y haces un dmesg para ver los mensajes que da el kernel del Linux que ejecuta. Quizás no le guste mi unidad .

Gracias Pablo, una lástima, al final que version/compilacion de SO has montado, con android no lo has probado, no?

De nuevo gracias por tu tiempo

Saludos

MAFREGA escribió:
Gracias Pablo, una lástima, al final que version/compilacion de SO has montado, con android no lo has probado, no?

XBian 1.0 Alpha 5 (la última). El problema es que el kernel no es capaz de montar la unidad óptica, aunque la detecta. He probado a eliminar totalmente el overclocking, pero nada.

Android está muy muy muy verde en la Raspberry. Creo que el meollo del asunto está ahora en distros basadas en Linux.

De todos modos ripear los CD directamente con la Raspberry, viendo lo justita que va de CPU, no sé yo si sería una buena opción.

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

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.