# data[].attributes.headline
Videotutorial: control de reproductores DLNA desde JRiver Media Center 

# data[].attributes.subject
Videotutorial: control de reproductores DLNA desde JRiver Media Center 

# data[].attributes.body
Una explicación detallada sobre las estupendas funciones de integración y control DLNA en JRiver Media Center.

# data[].attributes.attachment_link.title
Videotutorial: control de reproductores DLNA desde JRiver Media Center

# data[].attributes.attachment_link.description
Pues eso mismo, os dejo con él sin mayor preámbulo...

# data[].attributes.headline
Tutorial: Configuración del dispositivo de audio en JRiver Media Center 

# data[].attributes.subject
Tutorial: Configuración del dispositivo de audio en JRiver Media Center 

# data[].attributes.body
Siguiendo con el videotutorial anterior sobre la integración de JRiver Media Center en un entorno DLNA, os traigo ahora un pequeño tutorial que pretende clarificar los distintos ajustes que intervienen en la configuración de un dispositivo de audio local en este reproductor.

[...]

# data[].attributes.attachment_link.readable_text
Siguiendo con el videotutorial anterior sobre la integración de JRiver Media Center en un entorno DLNA, os traigo ahora un pequeño tutorial que pretende clarificar los distintos ajustes que intervienen en la configuración de un dispositivo de audio local en este reproductor.

Aunque resulta complicado proponer una configuración general apropiada para todos los casos, máxime cuando nos podemos encontrar con DACs con distintas capacidades y, además, JRMC está disponible para Windows, OS X y Linux (parece que una versión simplificada para Android también está en camino).

No obstante, lo que sí podemos hacer es recorrer los ajustes más relevantes y comentar algunas cosillas. Vamos a ello.

Para comenzar, podemos hacer clic en el menú:

Herramientas :: Opciones :: Audio

o, directamente haremos clic en el botón de ajustes de JRMC y, a continuación:

Audio Device (dispositivo de audio)

Lo primero será seleccionar el dispositivo de audio de salida que empleará JRMC.

En Windows podremos utilizar cada dispositivo instalado en el sistema en hasta 4 modalidades distintas, dependiendo de sus controladores ( drivers):

DirectSound (DS): El audio pasará por el mezclador del sistema, por lo que no vamos a conseguir una reproducción de tipo [i]bitperfect[/i]. Esto quiere decir, entre otras cosas, que con independencia de las características del audio reproducido (nº de bits y frecuencia de muestreo), Windows siempre lo remuestrará a los ajustes establecidos en el panel de control de audio. Además, el flujo de audio emitido por JRMC se mezclará con los procedentes del resto de aplicaciones del sistema. Por tanto, no usaremos esta modalidad salvo que no tengamos otra opción puesto que potencialmente es la que respeta en menor medida la integridad del audio contenido en los archivos reproducidos. También hay que decir que es la más compatible y la que menos problemas suele ocasionar.

WASAPI(Windows Audio Session API): Se trata de un modo de uso del dispositivo de audio caracterizado por que sí es posible conseguir una reproducción bitperfect. Además, JRMC puede tomar control total sobre el disposivo de audio, enmudeciendo en la práctica el resto de sonidos del sistema. Esta es la modalidad que actualmente se suele recomendar en sistemas Windows.

ASIO (Audio Stream Input / Output): Se trata de un protocolo para la transmisión de audio digital creado por Steinberg que se ha convertido casi casi en un estándar adoptado por gran cantidad de fabricantes. Algunos DACs solo funcionan de modo óptimo cuando se emplea ASIO, especialmente por lo que hace a conseguir una baja latencia, que resulta crucial en trabajos de grabación y mezcla de audio. Por lo demás, es funcionalmente idéntico a WASAPI y comparte con él su naturaleza bitperfect.

Kernel Streaming (KS): Se trata de otra modalidad capaz de funcionar en modo [i]bitperfect[/i], aunque su uso tenía sentido cuando ASIO no estaba tan difundido y WASAPI simplemente no existía. Hoy en día se utiliza en aquellas situaciones en las que no es posible recurrir a ASIO o WASAPI, bien porque no están disponibles, bien porque los drivers del dispositivo de audio presentan algún problema que impida su uso.

Aquí podéis ver los dispositivos disponibles en mi sistema, que corre Windows 10. Fijaos en que algunos se muestran en varias posiciones de la lista, apareciendo entre corchetes "[..]" la modalidad de funcionamiento correspondiente.

Aunque WASAPI y ASIO son funcionalmente equivalentes (dejamos de lado KS por considerarlo obsoleto), en ocasiones nos encontraremos con que uno funcionará mejor que el otro (estabilidad, cortes, problemas al reproducir ciertos tipos de audio, etc.). Algunas personas incluso detectan diferencias en el sonido que se obtiene al emplear uno u otro, a pesar de ser ambos [i]bitperfect[/i]. Por ello conviene probar ambos antes de seleccionar uno de modo definitivo.

En OS X, WASAPI y Kernel Streaming no están disponibles por tratarse de tecnologías propias del entorno Windows. Además, a diferencia de Windows (incluido Windows 10), tanto OS X, a través de su arquitectura de audio, denominada Core Audio, como Linux soportan de modo nativo la especificación USB Audio de clase 2. Esto hace que, en principio, no necesiten drivers para entenderse perfectamente con el DAC que usemos, aunque en ocasiones el fabricante del mismo puede suministrarlos para incrementar o mejorar las prestaciones o permitir un ajuste más fino de su funcionamiento.

Por ejemplo, aquí podéis ver el panel de control que los drivers de la Edirol UA25 instalan en OS X. Desde ellos se puede hacer un ajuste de bajo nivel de latencia, buffers, etc.

En OS X, por tanto, seleccionaremos el dispositivo de reproducción en la modalidad de uso [i]Core Audio[/i], a menos que aparezca alguna otra habilitada por los drivers del fabricante de nuestro DAC.

Device settings (ajustes de dispositivo)

Justo debajo del desplegable que permite seleccionar el dispositivo nos encontramos con otra opción que da paso a una venta de ajustes, ajustes que variarán en mayor o menor medida en función del dispositivo seleccionado.

Por ejemplo, aquí tenéis la ventana de configuración de una Asus Xonar STX en modo WASAPI:

Y aquí la de un módulo Edirol UA25 en OS X. Fijaos en que no es exactamente igual que la anterior:

Por último, aquí podéis ver la correspondiente a la Asus Xonar STX, pero esta vez en modo ASIO:

Hay que activar la opción que permite a JRMC tomar control exclusivo del dispositivo, de modo que la reproducción no se vea afectada por los ajustes del mezclador del sistema ni por otros flujos de audio Abrir el dispositivo para acceso exclusivo] / Open device with exclusive access). Cuando se emplea ASIO este ajuste no suele aparecer puesto que, por defecto, el modo de acceso es exclusivo.

Si usamos una versión de OS X y un DAC que lo soporte, es buena idea probar a activar el modo entero (Integer mode). Esto elimina una conversión numérica interna, aunque personalmente dudo mucho que suponga una diferencia sónica significativa.

En la parte inferior de la venta de configuración suele haber algún que otro control para ajustar el tamaño de los buffers de reproducción (Almacenando). Conviene mantenerlos en los valores sugeridos a menos que experimentemos problemas de cortes en la reproducción.

El resto de ajustes (Offset de canal, velocidad de bits, etc.) que pueden aparecer los dejaremos de entrada como están.

Es posible que aparezca alguna mención relativa al audio en DSD (DSD bitstream in DoP format en la última captura, aunque el texto exacto puede variar). De esto nos ocuparemos en el último apartado del artículo.

Cuando se está configurando un dispositivo ASIO suele aparecer otro botoncito para abrir un panel de control de más bajo nivel (en la captura anterior, Open Driver Control Panel). Aquí nos encontraremos con ajustes todavía más... digamos "intimos" de nuestro dispositivo de reproducción. En nuestro caso, Bit-Depth (bits / muestra) y Latency (latencia). De nuevo, inicialmente no deberíamos tocar nada.

Bitstreaming. Bonito palabro ¿verdad?

Existen una serie de formatos de audio que pueden ser decodificados por el propio JRMC, de forma que lo que se enviará al DAC será audio en PCM, o bien transmitidos en crudo (esto es, sin procesar) para que sea el DAC quien se ocupe de su decodificación. JRMC es capaz de gestionar estos:

Con la excepción de DSD, el resto tienen una cosa en común: todos portan audio PCM mondo y lirondo. A diferentes resoluciones y frecuencias, comprimidos con pérdidas o sin ellas, pero en todos los casos se trata de PCM. Esto quiero decir que es irrelevante que la decodificación la realice JRMC o el DAC (o receptor multicanal) de turno. El algoritmo de decodificación obtendrá exactamente el mismo flujo de bits PCM en ambos casos.

DSD es otra historia, de la que hablaremos más adelante, como decía en el apartado anterior. Por el momento nos contentaremos con marcar la casilla DSD si nuestro DAC soporta este formato:

Prebuffering (prelectura de audio)

Con este ajuste podemos indicarle a JRMC que lea por adelantado un fragmento de audio, cuya duración se indica en segundos.

Podríamos pensar que este ajuste está repetido puesto que en los correspondientes al dispositivo de reproducción ya se podía tocar el tamaño del buffer. En realidad se trata de un buffer de prelectura adicional al que opera a bajo nivel.

Si almacenamos los archivos de audio en una ubicación de red y experimentamos cortes, incrementar este buffer puede solucionar el problema, pero de poco servirá si los cortes son debidos a retenciones localizadas en las capas más bajas del sistema operativo.

Reproducción desde memoria

Si activamos esta opción, JRMC intentará cargar totalmente en memoria RAM cada archivo antes de comenzar la reproducción. Aunque es un parámetro potencialmente variable con cada versión, este buffer en RAM tiene una capacidad de 1GB.

Algunas personas afirman que el audio reproducido desde RAM suena mejor que el leído del disco o de una ubicación de red remota, así que ya sabéis, probad a ver.

JRCM puede controlar el volumen de reproducción de varios modos. Los más relevantes son:

Volumen del Sistema: Es equivalente a actuar sobre el volumen global del sistema.

Volumen interno: Utiliza el motor de reproducción de JRMC, que opera con una resolución de 64 bits, para ajustar el volumen. A menos que el dispositivo de reproducción disponga de volumen por hardware, en mi opinión es la mejor opción.

Cuando se reproduce en bitstream, por ejemplo DSD, el control de volumen no funcionará.

Podéis encontrar más información sobre las modalidades de gestión de volumen en el wiki de JRiver.

En Configure input plug-in tenemos un ajuste importante si pensamos reproducir audio DSD pero nuestro DAC no lo soporta y por tanto debe ser convertido previamente a PCM por JRMC:

La codificación en DSD genera cantidades importantes de ruido en bandas ultrasónicas. Ese ruido puede dañar los equipos de audio especialmente sensibles (amplificadores, altavoces) si no están diseñados para soportarlo. Por ello es aconsejable aplicar un filtro paso bajo que elimine este ruido de alta frecuencia.

JRMC sugiere el uso de un filtro paso - bajo de corte a 24 Khz y pendiente de 48dB / octava.

Estudio DSP

Podemos acceder al módulo de procesado digital de JRMC (DSP) bien a través de la opción correspondiente en la ventana de configuración:

...bien utilizando el botón Estudio DSP:

Antes de continuar, me gustaría mencionar que el módulo DSP está también disponible para configurar zonas de audio remotas (dispositivos con perfil renderer DLNA) a partir de la versión de JRMC 20.0.27. Mas sobre las zonas de JRMC y DLNA aquí y aquí.

Lo primero es establecer el formato de salida: codificación, frecuencia y mezcla de canales.

JRMC es capaz de recodificar al vuelo el audio reproducido a Dolby Digital o a DSD (hasta quad DSD de 22,4Mhz).

Podemos utilizar la recodificación a Dolby Digital para disfrutar de las pistas multicanal de un SACD o de un FLAC multicanal en un viejo receptor AV.

Con respecto a DSD, fijaos en la captura, existen 2 posibilidades:

1. DSD en formato DoP (DSD y DSDx2).

2. DSD nativo, en cuyo caso podemos alcanzar DSDx4.

La razón por la querríamos transformar el PCM en DSD la discutiremos en la sección final de este artículo.

Si queremos preservar la naturaleza del audio reproducido seleccionaremos Nada.

También podemos escoger una frecuencia de muestreo de salida para el audio en PCM (o DSD convertido a PCM si nuestro DAC no soporta DSD). En la lista que veréis a continuación aparecen distintas frecuencias, desde menos de 44100 Hz hasta más de 384000 Hz. Iremos haciendo clic en la columna Salida para establecer la conversión correspondiente a cada una de las frecuencias relacionadas. Si hacemos clic con el botón derecho del ratón el cambio será global para todas las frecuencias.

Este ajuste tiene utilidad cuando nuestro DAC no admite determinadas frecuencias de muestreo o, simplemente, cuando deseamos aplicar un remuestreo incondicional, quizás a la máxima frecuencia soportada por el dispositivo de salida, utilizando el motor de reproducción de alta calidad de JRiver.

Por último, estableceremos la mezcla de canales para adecuarla a las capacidades de nuestro dispositivo de audio.

El ajuste funciona hacia abajo y hacia arriba. Podemos escuchar, por ejemplo, un CD en 5.1. JRMC además es capaz de identificar pistas de audio estéreo con audio multicanal codificado matricialmente (Dolby Pro Logic II y similares).

Como veis los ajustes de salida son extraordinariamente flexibles. No obstante la cosa no acaba aquí. Disponemos de varios módulos DSP adicionales para ecualizar, aplicar efectos, corrección de sala (a través de convolución), normalizar el volumen, hacer la escucha con auriculares un poco más abierta, etc. etc.:

Por ejemplo, en mi sistema he tenido que recurrir al módulo de ecualización parámetrica para solucionar un problema que mi Xonar STX manifiesta actualmente con Windows 10. Al funcionar en modo WASAPI y reproducir audio a más de 88 Khz se cuela un ruido de alta frecuencia muy molesto. La solución es tan simple como aplicar un filtro paso bajo para eliminarlo:

Filtro que, además, me sirve para limpiar de ruido ultrasónico la señal DSD convertida a PCM.

A vueltas con el DSD

DSD, el formato de moda. Vamos a hablar ahora de algunas de sus particularidades para tratar de entender las distintas opciones de configuración de JRMC que hemos recorrido hasta el momento.

Como seguramente sepáis, el formato DSD se caracteriza por emplear una codificación basada en muestras de 1 solo bit y una frecuencia de muestreo muy alta, 2,8224 Mhz en el caso de un disco SACD estándar. A esto se le llama también DSDx64 (porque la frecuencia de muestreo es 64 veces la empleada en un CD, 44,1 Khz x 64) o DSDx1.

La codificación DSD presenta una ventaja fundamental con respecto a la PCM. Tanto el proceso de captura de audio (A/D) como el de conversión de digital a analógico (D/A), en el DAC, son mucho más simples, lo que en teoría permite preservar en mayor medida la integridad del fenómeno musical. De hecho, el segundo proceso (D/A) emplea poco más que un filtro paso bajo para reconstruir la señal analógica original. Esto supone una menor distorsión en el proceso de extremo a extremo y permite, en teoría, conservar de mejor modo la naturaleza analógica del audio capturado. El formato ofrece, además, un rango dinámico de unos 120dB (en la banda de 20 Hz a 20 Khz) y una respuesta en frecuencia que se extiende hasta los 100 Khz.

El problema es que la codificación empleada introduce cantidades industriales de ruido, que se empujan, empleando técnicas de conformación, fuera del espectro audible para que no molesten. Como hemos visto anteriormente en la configuración, este ruido ultrasónico debe ser filtrado en algún punto de la reproducción (reproductor o DAC) para evitar daños en los equipos.

En este gráfico, cortesía de Stereophile, podéis comparar el espectro de un tono de prueba codificado en DSD (arriba) y PCM de 24 bits (abajo). El ruido crece mucho a partir de 20Khz:

Sí, lo habéis leído bien: el ancho de banda del formato DSD es elevado, pero más tarde, en el momento de la reproducción, es necesario aplicar un filtro para eliminar el ruido ultrasónico que lo reduce notablemente, filtro que además debe ser lo suficientemente abrupto para hacer su trabajo rápidamente, es decir, en el ancho de banda que separa la señal audible de la banda a partir de la cual comienza el ruido. Y a mayor pendiente, normalmente mayor distorsión de fase que sufre la señal, distorsión que también afecta al área por debajo de los 20 Khz.

Ironías de la vida, o del formato DSD, debería decir.

Para tratar de paliar el problema anterior, recientemente han surgido codificaciones que elevan aún más la frecuencia de muestreo, hasta los 5,6448 Mhz (DSDx128 o DSDx2), 11,2896 Mhz (DSDx256 o DSDx4) y 22,5792 Mhz (DSDx512 o DSDx8). De este modo el ruido producido por la modulación Delta - Sigma empleada para generar la señal de 1 bit se mueve aún más arriba y por tanto los filtros de reconstrucción pueden comenzar a trabajar en una zona más alejada del espectro audible y forzar una pendiente de atenuación más suave.

No existe un estándar de discos físicos SACD de, vamos a denominar, super alta resolución, pero sí hay sellos que ofrecen descargas en DSDx128 y DSDx256.

Además, como hemos visto algunos reproductores como JRMC (o Foobar), son capaces de recodificar al vuelo el audio PCM en DSD, incluso de super alta resolución, para entregarle al DAC un bonito flujo indistinguible de un archivo originalmente en este formato ¿Suena mejor? Pues no sabría decirlo, aunque incluso los escépticos reconocen que el resultado ofrece matices sonoros ligeramente distintos.

Por otro lado, existen 4 modos de reproducir audio en DSD, todos ellos soportados por JRMC. Vamos a comentarlos:

Conversión a PCM: El audio DSD se transforma en PCM de una frecuencia y resolución dadas. JRMC lo hace a PCM 384/32, que luego se remuestrea según lo indicado en los ajustes de salida que establezcamos. Esta es la única opción si nuestro DAC no soporta DSD. Pero aún si lo hace, quizás sea la adecuada puesto que, en la práctica, no es posible aplicar procesado digital sobre una señal DSD. Nada de ecualización, mezcla de canales, ajuste de volumen, corrección de sala o convolución. Quizás lo que perdamos al pasar a PCM se vea compensado por lo que nos aporta una buena corrección de sala a través de la ecualización.

Reproducción DSD nativa: El audio DSD se envía tal cual al DAC para que este se las vea con él. Este modo solo está disponible, hasta donde yo sé, en Windows y únicamente cuando se emplea ASIO como modalidad de uso del dispositivo de salida. Core Audio en OS X no soporta por tanto esta posibilidad, a menos que drivers específicos del correspondiente fabricante lo permitan.

Empaquetado DoP: DoP es el acrónimo de DSD over PCM. Se trata de una codificación, surgida al amparo de la proliferación de DACs conectados por USB, que empaqueta un flujo de datos DSD dentro de un paquete que tiene toda la pinta de ser audio en PCM. Desde un punto de vista operativo, por tanto, esto es igual a ASIO, aunque como veremos hay sutiles diferencias.

Empaquetado DoPE: Análogo a DoP, pero se aplica en escenarios en los que el audio se emite por DLNA hacia un reproductor. Se trata de un estándar relativamente reciente cuyo soporte no está aún muy difundido.

A grandes rasgos, por lo tanto, podemos convertir el audio a PCM o escoger alguno de los modos que nos proporcionan reproducción DSD sin conversión. Pero puesto que aún contando con un DAC DSD no siempre es posible emitir hacia él DSD puro, ya que esto depende en última instancia del sistema operativo empleado y del modo de uso del dispositivo de audio, tenemos que hacernos la siguiente pregunta:

¿Son realmente DoP y DoPE equivalentes al envío de DSD puro?

No exactamente. Veamos por qué.

Decíamos más arriba que cuando se emplea DoP (o DoPE), el audio DSD se empaqueta dentro de un contenedor PCM. Concretamente, el flujo de bits se agrupa en bloques de 16 (2 bytes). A cada uno de estos bloques se le debe agregar una cabecera indentificativa, lo que se conoce como un marcador DoP, para que el DAC sepa que lo que realmente está recibiendo es DSD, lo extraiga descartando el marcador, y lo reproduzca de modo adecuado. Mirad este gráfico tomado de The Well-Tempered Computer:

En rojo se aprecia el marcador, de 8 bits, y en azul la carga DSD de 16 bits de cada paquete. Esto hace que cada bloque transmitido al DAC (o al reproductor DLNA compatible con DoPE) tenga una longitud de 24 bits, 8 de los cuales no portan datos.

Seguro que ya os habéis dado cuenta :D. El problema con DoP / DoPE es que se introduce una sobrecarga de un 33%. Dicho de otro modo, es necesario transmitir más información hacia el DAC de la que sería estrictamente necesaria de ser posible la transmisión de audio DSD nativo.

La frecuencia de 2,8 Mhz del DSDx64 parece muy elevada, pero desde un punto de vista estrictamente numérico es equivalente a PCM a poco más de 117 Khz y 24 bits. Al usar DoP, sin embargo, es necesario transmitir audio PCM a 176 Khz y 24 bits para que nos quepan los marcadores DoP de cada paquete de 16 bits. Parece poca cosa, pero en sistemas que vayan justitos de potencia, sufran de problemas de latencia o de un acceso de baja o inestable velocidad a los archivos a reproducir esto dificulta las cosas y puede llegar a ser el factor diferencial que posibilite una experiencia de audio sin cortes o no. Lógicamente lo dicho cobra mayor importancia cuando estamos hablando de DSDx2 o de frecuencias superiores.

De hecho, si volvéis a la captura en la que se mostraban los ajustes de codificación de JRMC, DoP solo está soportado hasta DSDx2. Si queremos alcanzar DSDx4 ya tiene que ser a través de reproducción nativa (DSDx2 en DoP ya requiere la transmisión de PCM a 352,8 Khz).

Es por ello que, siempre que sea posible, configuraremos preferiblemente JRMC de modo que la transmisión de audio en DSD se produzca de forma nativa.

Para terminar, recordaros que de optar por la conversión del DSD a PCM no os debéis olvidar de activar el filtro correspondiente para eliminar el ruido de alta frecuencia característico de esta codificación en:

Herramientas :: Opciones :: Audio :: Avanzado :: DSD input plug-in

# data[].attributes.attachment_link.title
Tutorial: Configuración del dispositivo de audio en JRiver Media Center

# data[].attributes.attachment_link.description
Siguiendo con el videotutorial anterior sobre la integración de JRiver Media Center en un entorno DLNA, os traigo ahora un pequeño tutorial que pretende clarificar los distintos ajustes que intervienen en la configuración de un dispositivo de audio local en este reproductor.

# data[].attributes.body
JRiver Media Center incluye, entre su interminable lista de características y funciones, una denominada Zonas.

Para JRMC una zona es una abstracción que representa a un dispositivo de reproducción, local al ordenador que ejecuta JRMC o remoto (renderers UPnP detectados automáticamente en la red), más todos sus correspondientes ajustes de configuración de audio, incluyendo los disponibles en la ventana de DSP de JRiver Media Center.
[...]

# data[].attributes.attachment_link.readable_text
Se me había pasado totalmente publicar aquí un pequeño artículo que escribí hace algún tiempo en Audio Planet para explicar qué son y para qué sirven las zonas de ese grandísimo reproductor que es JRiver Media Center y que, tras muchos dimes y diretes, se ha convertido en mi opción irrenunciable cuando pretendo escuchar música en serio en casa.

Si te ha gustado esto quizás te interese este otro artículo en el que se comparan dos de las apps de control para Jriver Media Center:

# data[].attributes.attachment_link.description
Se me había pasado totalmente publicar aquí un pequeño artículo que escribí hace algún tiempo en Audio Planet para explicar qué son y para qué sirven las zonas de ese grandísimo reproductor que es JRiver Media Center y que, tras muchos dimes y diretes, se ha convertido en mi opción irrenunciable cuando pretendo escuchar música en serio en casa.

# data[].attributes.headline
Controlando JRiver Media Center desde un iPad ¿JRemote vs. My River? 

# data[].attributes.subject
Controlando JRiver Media Center desde un iPad ¿JRemote vs. My River? 

# data[].attributes.body
La adquisición reciente de un Apple Mac mini (a precio de saldo, como no podría ser de otro modo), que ha pasado a engrosar la legión de cacharros conectados al equipo del salón, me ha hecho plantearme si algo tan pequeño y apañao puede sustituir el HTPC que monté hace casi 3 años y que es por derecho propio la fuente digital de audio y vídeo que utilizo con mayor frecuencia.
[...]

# data[].attributes.attachment_link.readable_text
La adquisición reciente de un Apple Mac mini (a precio de saldo, como no podría ser de otro modo), que ha pasado a engrosar la legión de cacharros conectados al equipo del salón, me ha hecho plantearme si algo tan pequeño y apañao puede sustituir el HTPC que monté hace casi 3 años y que es por derecho propio la fuente digital de audio y vídeo que utilizo con mayor frecuencia.

Las funciones que debe asumir el Mac mini serán tanto de reproducción de audio como vídeo, aunque en esta ocasión me voy a centrar en el primer aspecto.

Aunque existen otras posibilidades probablemente excelentes, mis preferencias por lo que hace a reproductores de audio son dos: Foobar 2000 y JRiver Media Center. El primero es gratuito y solo está disponible para Windows, en tanto que el segundo es de pago (aunque muy económico) y ofrece versiones para Windows, OS X y Linux (estás últimas de reciente aparición).

Aunque siempre he sido un fan declarado de Foobar y de hecho descarté en su momento JRMC como opción al construir mi HTPC optando por el primero, las pruebas que estoy realizando con el Mac mini han reavivado mi interés por él. A falta de Foobar...

Cuando se pretende configurar un ordenador para que desempeñe funciones de reproductor de audio hay que pensar en cómo va a controlarse. Probablemente estará conectado a algún dispositivo de visualización (típicamente una televisión o monitor) y puesto que se trata de un sistema que normalmente dispondrá de una interfaz de usuario al uso podrá ser controlado de modo convencional por medio, por ejemplo, de un teclado y ratón inalámbricos. De estos últimos existen versiones específicas destinadas a un uso digamos de PC de cine en casa (HTPC), por ejemplo este teclado con Touchpad Logitech:

Pero esto exige ver la interfaz de usuario del sistema operativo instalado, esto es, tener la tele encendida. Lo realmente chulo es controlar el reproductor a ciegas, con la televisión apagada. Para ello, como probablemente ya sepáis, podemos recurrir a las diversas aplicaciones específicas de control remoto disponibles para tabletas y teléfonos inteligentes. Me refiero a apps diseñadas para controlar cómodamente determinados reproductores, no a aplicaciones de escritorio remoto, tipo Teamviewer o Splashtop, que muestran en la comparativamente pequeña pantalla del móvil o tableta la interfaz de usuario convencional que veríamos de conectar el ordenador a un monitor.

En este caso se trata de controlar una instancia de JRMC corriendo en OS X. Hasta donde yo sé las 2 mejores opciones si se utiliza un iPad son JRemote y My River.

Es por ello que he realizado una pequeña comparativa entre ambos. Por no repetirme y siguiendo la línea de las últimas entradas, enlazo con el artículo publicado en Audio Planet.

# data[].attributes.attachment_link.title
Controlando JRiver Media Center desde un iPad ¿JRemote vs. My River?

# data[].attributes.attachment_link.description
La adquisición reciente de un Apple Mac mini (a precio de saldo, como no podría ser de otro modo), que ha pasado a engrosar la legión de cacharros conectados al equipo del salón, me ha hecho plantearme si algo tan pequeño y apañao puede sustituir el HTPC que monté hace casi 3 años y que es por derecho propio la fuente digital de audio y vídeo que utilizo con mayor frecuencia.