domingo, 9 de diciembre de 2018

Cables ethernet "audiófilos": un experimento casero


Sí, esto va de cables ethernet audiófilos, de esos que suelen tener bonitos e imaginativos nombres y pueden costar sin despeinarse cientos o incluso miles de euros. Por ejemplo, el de la parte inferior de la foto anterior, un Audioquest Diamond, que ronda los 800€/ metro.

Así, que mejor empecemos por la...

Exención de responsabilidad

Vistas las susceptibilidades que afloran cuando se toca este delicado asunto, anteponga usted, querido lector, a mis afirmaciones subsiguientes las expresiones "en mi opinión", "resulta razonable suponer", "yo diría", "no encuentro motivos para ignorar", "me da la sensación" y cuantas fórmulas de cortesía y humildad similares considere usted necesarias para limar las posibles asperezas que pudieran derivarse de su lectura. No es mi intención que se produzcan, pero tampoco me voy a poner de perfil en esta ocasión. Bueno, solo un poquito, lo justo y necesario.


Motivación

Mucho estoy leyendo en los últimos meses en Audio Planet (y otros lugares) sobre los milagros que ciertos cables ethernet parecen obrar sobre la transmisión de señales digitales de audio. Cables, que naturalmente, son fabricados y vendidos por las mismas marcas que llevan produciendo otro tipo de cableado, tanto analógico como digital, para el exigente mercado audiófilo durante años... lo que por otra parte se me antoja inevitable ahora que el audio hi-end (y el que no es tan "hi" también) ha dejado de ser estrictamente analógico. No dejes que nuevos vientos en el mar te dejen sin pesca en las redes.

Veamos un ejemplo paradigmático:


Esto lo escribe un tal Jay Luong aquí. Así que sonido coherente, suave, con cuerpo y "eufórico", además de rico, musical, natural y adictivo. Agárrate. Es inevitable que cualquiera que se dedique profesionalmente a desplegar y configurar redes locales o simplemente tenga ciertos conocimientos técnicos al respecto enarque preventivamente una ceja (o las dos simultaneamente) ante afirmaciones tan pizpiretas como estas.

¿De verdad podemos atribuirle a un simple cable de transmisión ethernet estas cualidades de un modo tan inequívoco? ¿Será porque es de categoría 8? Pero, ¡dios mío! ¡Si ni siquiera existía tal certificación en el momento (mayo 2017) de escribir ese colorista análisis! Estos fabricantes no cortan el mar sino vuelan o, como hubiera dicho mi abuela, "van delante del aire". Eso va a tener que ver un poquito con la pesca de la que hablaba un par de párrafos más arriba.

Pero dejando de lado las sinestesias, inevitables por otra parte cuando hay cierto tipo de audiófilo en la sala, testimonios como este no son raros, ni tampoco los hilos en los que aficionados preguntan por las bondades de tal o cual cable ethernet. Sin ir más lejos, aquí al lado, en Audio Planet, hemos visto en este hilo reciente algún que otro encontronazo entre escépticos (con ese, por favor) y ¿creyentes?

La cantinela es la de siempre: aficionados que dicen percibir diferencias allá donde otros afirman que por razones técnicas no puede haber más que la manifestación de la propia subjetividad y variabilidad perceptual. Mosqueo in crescendo de los unos y los otros, comentarios jocosos varios con mayor o menor gracia, susceptibilidades henchidas y honores mancillados hasta que simplemente la cosa alcanza su clímax y nuevamente las aguas vuelven a su cauce tras la salida del hilo de quien corresponda, según toque. Los foros son así, mire usted. Y si no le gustan, tengo otros.

No me avergüenza reconocer que yo mismo caí en la trampa de participar en esta refriega concreta cual forero novato, hasta el punto de que en cierto momento decidí simplemente abandonar. Pero lo cierto es que me quedé con las ganas de hablar del tema con cierto detenimiento. Y como hoy es festivo y tengo mucha musiquita chula que escuchar en mi equipo de 3 chavos, aquí estamos.

Cuando el río suena...

...Agua lleva ¿verdad? Pues no siempre, pero vamos a tratar de valorar todas las posibilidades con la mente abierta, casi tanto como para que se nos caiga el cerebro (Richard Feynman dixit, o al menos algo parecido).

Richard Feynman pensando en sus cosas (seguramente misterios cuánticos).
Antes de entrar en materia, no obstante, recomiendo leer un poquito sobre los distintos cables ethernet, sus características, propiedades, usos y certificaciones. Aquí no hay ningún misterio. Un buen sitio es este. Así me ahorro tener que explicarlo yo aquí, que resulta bastante aburrido.

Pero vamos centrándonos. En lo que sigue voy a tratar de presentar las distintas circunstancias que, tal y como yo lo veo, podrían afectar a la integridad de una señal de audio digital transmitida a través de un cable ethernet. No entraré sin embargo a valorar hasta qué punto esas diferencias medibles pueden o no ser audibles. Eso queda ya en el ámbito de lo subjetivo y simplemente no me apetece traspasar las puertas de Mordor, al menos no sin una legión de Altos Elfos a mi servicio.

Veamos. El aficionado A afirma que su equipo suena mejor con determinado cable ethernet ¿a qué podría deberse? Se me ocurren dos posibles causas.

1. Interferencias radioeléctricas

Los cables no dejan de ser antenas que captan y emiten radiaciones de tipo electromagnético. Un cable ethernet probablemente se encontrará en un ambiente repleto de ellas, tanto más en la medida en que el sistema de reproducción incluya un PC convencional.

Cableado, ventiladores, amplificador, otros componentes... probablemente no sea el entorno más aséptico del mundo.
Estas perturbaciones, a su vez, podrían afectar a los más o menos delicados voltajes digitales de la señal de audio hasta el punto de alterar su integridad, de modo que algunos 1's se transformarían en 0's o viceversa. Y ya la tenemos liada entonces ¿no? Relación causa - efecto justificada y fin del artículo.

¡No tan rápido!

Por otro lado, y aún admitiendo que el fenómeno anterior no afectara en modo alguna a la integridad de la información transmitida, aún podría suceder que dichas perturbaciones se colasen, a través de sus puertos ethernet, en los delicados circuitos electrónicos de los dispositivos de reproducción en los que eventualmente se realiza la conversión de la señal digital al ámbito analógico, perturbaciones que desde ahí podrían asimismo propagarse a los componentes eléctricos de sus etapas de salida y circuitos de reloj. Eso tal vez se manifestara en la forma de variaciones cuantificables en parámetros tales como la distorsión armónica, la relación señal / ruido o incluso el escurridizo jitter, ese elusivo duendecillo al parecer responsable de todas las miserias actuales del audio digital.

Es un hecho conocido que existe una relación entre la actividad de la CPU, GPU y otros componentes de un sistema informático y el patrón de emisiones electromagnéticas que genera cuando está en funcionamiento. Tanto es así que incluso existen sorprendentes técnicas de espionaje capaces de predecir a distancia lo que aparece en la pantalla de un ordenador totalmente desconectado de la red (Kuhn 2003, 2004) o transmitir información desde él, cuando ha sido previamente comprometido, hacia un simple teléfono móvil (Guri et al. 2015). De hecho el trabajo en este campo del tal Mordechai Guri y su alegres hackers es... inquietante. Ya tardáis en buscarlo en Google.

Habiendo reconocido pues el papel que puede jugar toda esta cacofonía de perturbaciones electromagnéticas en un sistema informático, no se requiere de un gran salto de fe para admitir la posibilidad de que un cable ethernet susceptible de captar y propagar ciertas interferencias pudiera comprometer, hasta cierto punto, tampoco nos vengamos arriba, la calidad de sonido en un reproductor digital.

La pregunta, claro,  es cuánto.

Pero en el título de este artículo hablabas de un experimento ¿no? En efecto, pero no uno que sirva para dar respuesta a la anterior cuestión. Desgraciadamente no dispongo del equipamiento necesario para medir el posible efecto de distintos cables ethernet sobre la señal emitida a través de la salida de línea analógica de un reproductor conectado a una red ethernet. No obstante, otros como el archiconocido Archimago sí lo tienen... y además lo utilizan asiduamente. Recomiendo encarecidamente la lectura de los extensos y concienzudos artículos que este conocido aficionado publica en su blog. Resultan de gran ayuda para combatir con contundencia la terrible audiofilia nerviosa digital, una variante relativamente reciente de este conocido mal, especialmente cuando aún se encuentra en sus fases tempranas cuando la cosa aún tiene remedio.

Vamos a por la segunda.

2. Perdiendo bits por el camino (y cómo funciona TCP/IP)

Retomemos ahora la especulación anterior acerca de las interferencias de índole electromagnética y la posible corrupción de datos en tránsito. O admitamos que algunos bits simplemente se pierdan de algún modo en su camino de emisor a receptor. Quién sabe, quizás decidan irse de copas y no sepan volver a su casa tras la juerga de rigor. ¿Podría esto justificar la existencia de estos supercables ethernet cuyas propiedades van más allá de donde certificación alguna ha llegado jamás?

Para profundizar un poco en esta posibilidad tenemos que introducir primeramente ciertos conceptos relacionados con el modo en que se transmite la información. Voy a tratar de explicarlo sin profundizar demasiado en los detalles técnicos ni contar demasiadas mentiras, lo que probablemente no conseguiré.

El problema de interconectar sistemas informáticos heterogéneos (es decir, con tecnologías dispares, o lo que es lo mismo, de su padre y de su madre), alejados miles de kilómetros, utilizando una red extensa, insegura, compuesta por una cantidad indeterminada de nodos intermedios que pueden empeñarse testarudamente en extraviar, duplicar o desordenar la información que circula entre ellos no es ninguna bobada.

De hecho, desarrollar el conjunto de tecnologías y protocolos necesarios para lograrlo con éxito ha supuesto muchas décadas de trabajo para algunas mentes más que brillantes. Es la historia de ARPANET (y de lo que había antes de ARPANET). Es la historia de TCP/IP. Y de héroes conocidos como Jon PostelDouglas Engelbart, Vicent Cerf o, más recientemente, Tim Bernes-Lee. Y también de otros menos conocidos pero cuya contribución resultó también decisiva. Y el caso es que lo que crearon, que seguramente conocerás como Internet, resuelve el problema. Y permite que una empresa de Albacete haga copias de seguridad diarias de sus datos en un servidor de Ohio sin temor a que ni uno solo de sus preciosos bits se pierda por un camino digital de paquetes de datos amarillos que se extiende de extremo a extremo del mundo a través de docenas de redes ajenas.


Vete ahora y explícale a esta gente, o a los pastores que cuidan de la infraestructura que aquellos parieron, que te preocupa que tu cable ethernet de pocos metros pierda datos en una conexión punto a punto doméstica cuando transmite información de audio o vídeo codificada digitalmente de igual modo que los backups de la empresa de Albacete.

Pero sigamos con la mente abierta.

El caso es que el problema descrito, por su complejidad, no resulta fácilmente abordable de modo monolítico. O lo que es lo mismo, es preferible descomponerlo en problemas más sencillos que se irán resolviendo progresivamente. Y así surge la llamada arquitectura por capas de TCP/IP, que a su vez se basa en la propuesta anteriormente por OSI, más estratificada. Si quieres saber más sobre los modelos ISO/OSI y TCP/IP, esta es una buena referencia, bastante completa pero no abrumadora desde un punto de vista técnico.

Prosigamos.

Resumiendo un poco (bueno, bastante), la idea es descomponer el proceso de transmisión en capas (niveles), cada una de las cuales solo se ocupa de determinados problemas puesto que asume que ciertas cosas ya han sido resueltas en las capas inferiores. Y de modo análogo, le facilita por tanto la vida a las superiores tras desarrollar su propia función. Se trata en definitiva de un mecanismo de encapsulación de la complejidad que comprende desde las aplicaciones que desean transmitir información (arriba) hasta las propias señales eléctricas u ópticas que efectivamente se envían (abajo), pasando por toda una caterva de protocolos de distinto pelaje especializados en resolver problemas específicos.

Esquema general del funcionamiento de una arquitectura de red por capas. El número de capas es más que discutible.
Cada capa agrupa los bits de datos en paquetes que en función del nivel al que pertenecen reciben distintos nombres: segmento, datagrama, trama... Además, se añade información de control (cabeceras), necesarias para que surja la "magia" que se practica en cada nivel. Emisor y receptor disponen de todas las capas, de modo que la transmisión de estos paquetes se realiza de arriba a bajo en el emisor, de ahí pasa a la red, y ya en el receptor de abajo arriba. Cada capa, no obstante, tiene la sensación de estar "dialogando" con su equivalente, por lo que desde un punto de vista lógico es como si la comunicación se estableciera horizontalmente entre los niveles (protocolos) homónimos de emisor y receptor. Casi nada.

Dejando de lado el probable galimatías que constituye el último párrafo, que quizás prefieras ignorar sin remordimientos, concretemos el asunto con un gráfico ya adaptado a nuestra peculiar área de interés, los cacharros que reproducen audio.

Una versión maxi single de la arquitectura por capas de TCP/IP en un sistema de reproducción de audio en red.
En la parte superior, tenemos los distintos dispositivos que pueden actuar como reproductores de audio: ordenadores, reproductores comerciales dedicados o basados en hardware abierto (SoCs de tipo Raspberry, ODROID y similares). Y muchos más, claro. Cualquier cosa capaz de reproducir contenidos multimedia a través de la red. De hecho, he excluido del diagrama móviles y tabletas puesto que nos estamos centrando en la conexión ethernet y estos suele carecer de ella, pero conceptualmente tendrían todo el derecho a aparecer ahí arriba. 

Los reproductores lógicamente necesitan de un software que los comande. Estos constituyen el denominado nivel de aplicación:
  • En el caso de ordenadores, se trata de aplicaciones de escritorio como JRiver Media Center, Foobar, Audirvana, las de Spotify o Tidal o simplemente un navegador de Internet mondo y lirondo con el que acceder a servicios genéricos en streaming.
  • Distros basadas en Linux como piCorePlayer, Volumio o LibreElec para los SoCs abiertos.
  • Y, por último, lo que quiera que ejecuten los reproductores comerciales, usualmente algo basado también en Linux y otros desarrollos de código abierto con un mayor o menor grado de personalización por parte del fabricante.
Justo debajo nos encontramos con el nivel de sesión, y reconozco que aquí me he tomado una pequeña licencia para colar ciertos elementos que me convenía poner sobre la mesa. A diferencia de ISO/OSI, la arquitectura TCP/IP no maneja de modo explícito un nivel de sesión, de ahí que escriba su nombre en cursiva en el diagrama anterior. El caso es que me interesa introducir ciertos protocolos de red de alto nivel, que estrictamente hablando tampoco deberían aparecer ahí, necesarios para que las aplicaciones que encuentran en la parte superior de nuestra pila (o torre, si lo prefieres) puedan establecer conexiones con otros dispositivos o servidores con los que intercambiar información. Los más utilizadas son SMB, NFS y, en entornos domésticos AV, UPnP. Todos ellos representan el primer paso en el camino para "salir a la red".

Más abajo, y ahora sí reingresamos en la arquitectura TCP/IP de Internet, nos topamos con la capa de transporte, conformada por dos protocolos, TCP y UDP:
  • TCP proporciona un servicio orientado a conexión que garantiza todo lo que debe ser garantizado en una transmisión segura, creando un "tubo" extremo a extremo de forma que la información pasa a través de él preservando totalmente su orden e integridad. Para ello se incorporan mecanismos de retransmisión de datos cuando se detectan errores. Estos mecanismos tiene un coste, una sobrecarga, que hace que parte de los datos que se transmiten deben ser necesariamente de control para que el tinglado pueda gestionar cualquier eventualidad.
  • UDP no hace nada de lo anterior, de hecho ni siquiera es un servicio orientado a conexión y, por tanto, se utiliza en escenarios en los que a) se presupone que no se van a producir errores o b) es más importante garantizar que un flujo constante de información llegue al receptor que asegurarse de que esto se consiga sin que se produzcan errores en el proceso (por ejemplo en las retransmisiones de audio y vídeo en tiempo real). A cambio, su eficiencia es mayor que la de TCP. 
Los protocolos y aplicaciones situados por encima de la capa de transporte pueden diseñarse para emplear uno u otro. En algunos casos esta elección queda grabada a fuego en la etapa de diseño. En otros puede modificarse a voluntad del usuario o como consecuencia de una decisión inteligente de la aplicación posteriormente, en cada uso.

Por ejemplo, UDP se suele utilizar en aplicaciones de videoconferencia en tiempo real, donde concurren exigencias temporales más restrictivas que las de la simple emisión de flujos de audio o vídeo porque de lo contrario la inteligibilidad de la sesión puede verse seriamente perjudicada al ser la comunicación bidireccional. 

Además, tanto TCP como UDP proporcionan un servicio adicional a los niveles superiores, un mecanismo denominado multiplexación de flujos de datos. Gracias a él, diferentes aplicaciones en un mismo dispositivo son capaces de mantener conexiones simultáneas con otros tantos agentes remotos. La capa de transporte etiqueta mediante unos identificadores numéricos asociados aquellos procesos que se encuentran a cada lado de la conexión. Estos identificadores se denominan puertos.

Si un reproductor utiliza un protocolo de sesión que funciona sobre TCP/IP podemos asumir que, salvo circunstancias cataclísmicas, la conexión es segura. Así de sencillo. En el caso de UDP no, pero... sigamos bajando.

Del nivel de red solo voy a decir que proporciona los mecanismos globales de identificación de dispositivos y encaminamiento de datos necesarios para que los paquetes encuentren su destino en una red extensa multipunto. No hay más que pensar en una hipotética red ferroviaria (si es muy densa mejor), con múltiples rutas entre dos estaciones dadas, para entender de qué va esto.

Principales rutas de datos de las conexiones troncales de Internet (2006). Fuente: Opte Project (Wikipedia).
No es que su papel no sea importante (¡es crucial!), sino que no necesitamos profundizar más en este aspecto para abordar el tema que nos ocupa. Simplemente aceptemos que IP es el auténtico corazón de Internet. Funciona, y punto.

Llegamos al meollo del asunto, el nivel donde opera el estándar ethernet, con sus puertos de red, cableado, dispositivos de conmutación (switches, routers, etc.) que en terminología OSI son realmente dos, a saber: la física y la de enlace datos. Estas capas son las responsables de posibilitar en última instancia la comunicación en el ámbito de nuestra red local. Y es aquí donde nos vamos a detener para realizar un pequeño experimento. Pero antes, algunos comentarios. Paciencia, ya casi estamos.

Las comunicaciones entre dispositivos dentro de una red local no requieren estrictamente hablando de ningún mecanismo de encaminamiento como el que proporciona TCP/IP en una red de área extensa como Internet. Los datos simplemente fluyen por el cable hasta un conmutador, típicamente el propio router en entornos domésticos sencillos, y de ahí hasta el dispositivo destinatario de los mismos. Aunque la topología física es una estrella cuyo centro se encuentra un conmutador, a todos los efectos los elementos conectados se hallan dentro de la misma red física.

Un sencillo router doméstico (D-Link DIR-882) como el empleado para las pruebas que siguen.
Ethernet proporciona mecanismos para, por una parte, sincronizar emisor y receptor (control de flujo) y, por otra, detectar los errores producidos en estas transmisiones, digamos, locales, aunque no para recuperarse de ellos. Esto quiere decir que si un paquete de datos es erróneo simplemente se descarta y se informa a las capas superiores para que alguien haga algo, literalmente, si se considera oportuno.

Y aquí es donde todo empieza a encajar (espero). Cuando una aplicación (y ahora volvemos a la parte superior de nuestra bonita torre TCP/IP) emplea TCP como protocolo de transporte, tenemos todas las garantías para considerar que la transmisión es segura y no se pierde información. Si en cambio se utiliza UDP, este garante desaparece.

Pero...

(A) ¿Sabemos qué reproductores utilizan TCP y cuáles UDP?

(B) ¿Cuántos errores de transmisión se producen realmente?

Si quieres averiguarlo por ti mismo, sigue leyendo. ¡Vamos con las pruebas!

Netstat, TCP y UDP

Netstat es una utilidad de línea de comandos disponible en sistemas Windows, Linux y OS X. Su sintaxis difiere ligeramente en cada caso, pero la información que nos proporciona es prácticamente idéntica.

Pero primero voy a presentarte el cable ethernet utilizado en todo lo que sigue:

El John Doe de los cables ethernet.
Sí, estás viendo bien. Se trata de un miserable SFTP de categoría 5E de unos 2 metros de longitud. Ni 8, ni 7 ni 6. Adecuado para conseguir velocidades de 1000 Mbps en full dúplex, de acuerdo a lo que marca la certificación para esta categoría. Ni más ni menos. No sabría decir qué precio tiene puesto que si no me equivoco venía incluido con algún cacharro, pero diría que no debería costar más de unos pocos euros. ¿Esperabas otra cosa?

Comencemos lanzando el cliente de escritorio de Tidal, a ver si somos capaces de determinar qué protocolo de transporte utiliza. Recordemos, TCP ofrece garantía de transmisión de la información sin errores en tanto que UDP opera bajo algo así como "envía & reza", sin proporcionar ningún mecanismos de recuperación el caso de pérdidas o errores en los datos.

Tidal: gran sonido, pésimas recomendaciones.
Para ello primeramente deberemos averiguar su PID (identificador de proceso) utilizando el administrador de tareas. En Windows lo encontraremos aquí:

Localizando el PID de un proceso a través del administrador de tareas de Windows.
Ahora solo necesitamos hacer (seguimos en Windows):

X:\>netstat -ano | find "5556"

TCP  10.255.0.198:52182  2.18.49.14:443  ESTABLISHED  5556


Vaya, el proceso TIDALPlayer.exe abre una conexión de tipo TCP entre el PC local (10.255.0.198) y uno remoto (2.18.49.14) en cuanto comenzamos a reproducir un tema. Si hacemos ahora..

X:\>ping -a 2.18.49.14

Haciendo ping a a2-18-49-14.deploy.static.akamaitechnologies.com [2.18.49.14]:
Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53
Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53
Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53
Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53


...comprobaremos que se trata de un servidor en Akamai, una conocida organización que dispone de una potente red de distribución global de contenidos utilizada por múltiples proveedores de servicios en Internet. Blanco y en botella.

Como ya hemos visto de qué modo proceder en Windows yo seguiré a partir de ahora, por brevedad, desarrollando mi argumentación exclusivamente en un entorno Linux. Como aquí no tenemos un cliente de escritorio de Tidal (¿para cuándo?), probaremos con el de Spotify.

Los duendecillos de Spotify, en cambio, me conocen como si me hubieran parido.
La sintaxis del comando a emplear en una terminal en este sistema operativo será similar:

pablo@menos:~$ netstat -antup | grep spotify

tcp     0  0 0.0.0.0:39157        0.0.0.0:*           ESCUCHAR     14991/spotify
tcp     0  0 0.0.0.0:57621        0.0.0.0:*           ESCUCHAR     14991/spotify
tcp     0  0 192.168.1.101:56570  72.247.210.56:80    ESTABLECIDO  14991/spotify
tcp     0  0 192.168.1.101:35172  104.199.65.47:4070  ESTABLECIDO  14991/spotify
udp  1536  0 0.0.0.0:57621        0.0.0.0:*                        14991/spotify

El número de conexiones varía ostensiblemente durante el periodo de uso de Spotify, así que si estás probado esto en tu equipo es probable que el resultado sea distinto. En esta ocasión nos encontramos con indicios de uso de UDP. Dado que es este un protocolo sin conexión, netstat es incapaz de mostrarnos quién está "al otro lado de la línea", indicando tan solo que el cliente de Spotify del PC está escuchando en UDP/57621. Podríamos escarbar un poco más con alguna herramienta de captura de paquetes para tratar de obtener información más concluyente, pero probablemente no merecería la pena.

¿Quiere esto decir que Spotify usa UDP para su emisión? En mi opinión no. Hay que recordar que nos encontramos tras un router en el que no se han abierto ni redirigido puertos específicos hacia este PC, de modo que no es alcanzable desde Internet. Yo diría que el puerto 57621 más bien se utiliza para algún tipo de funcionalidad relacionada con la interacción con otros clientes de Spotify que pudiera haber en la red local. No obstante, si te sientes más cómodo pensando lo contrario, puedes hacerlo tranquilamente.

Por cierto que Spotify, al menos en sus inicios, tenía una curiosa manera de funcionar, combinando la descarga directa de datos de audio desde los servidores de esta empresa con el uso de una red P2P entre los propios usuarios del servicio para aligerar la carga sobre sus propias infraestructuras. En este artículo (Kreitz, Niemelä 2010) lo explicaban ellos mismos estupendamente.

Spotify, en 2008. Cuando el P2P te ayuda a crecer sin invertir un montón de pasta. El diagrama es prestado (Spotify).
Veamos a continuación qué pasa con un cliente software Squeezelite en un entorno Squeezebox.

pablo@menos:~$ netstat -antup | grep squeezelite

tcp        0  0  192.168.1.101:35276  192.168.1.100:3483  ESTABLECIDO  27308/squeezelite
tcp  1252585  0  192.168.1.101:47026  192.168.1.100:9000  ESTABLECIDO  27308/squeezelite

Ahora TCP sin ambages.

A continuación probemos con un reproductor minimalista como Audacious (Linux) tirando musiquita localizada en una carpeta de mi NAS doméstico compartida en red mediante SMB.

Audacious, un pequeño gran reproductor heredero espiritual de Winamp.
pablo@menos:~$ sudo netstat -antup | grep audacious

pablo@menos:~$


Ya hemos roto algo. ¿Qué ha pasado? Ahora no es Audacious (el reproductor) quien abre la conexión de red, sino que es el propio sistema operativo quien se encarga de gestionar la transmisión de datos  a través de sus servicios de red mediante SMB. Pero como sabemos que los servidores SMB deben "escuchar" en el puerto 445, veamos qué conexiones salientes ha establecido nuestro PC hacia ese puerto:

pablo@menos:~$ sudo netstat -antup | grep 445

tcp  0  0  192.168.1.101:51832  192.168.1.100:445  ESTABLECIDO  11563/gvfsd-smb

Ahí la tenemos, de tipo TCP hacia 192.168.1.100, que se corresponde con la IP del NAS donde se encuentran los archivos reproducidos.

Con otros reproductores como JRiver Media Center ocurrirá exactamente lo mismo. De hecho, cualquier aplicación que acceda a la red a través de SMB o NFS lo hará de modo seguro puesto que ambos protocolos utilizan siempre TCP. Esto también incluye a los diversos demonios MPD que se encuentran en el corazón de más de un reproductor comercial de hardware cerrado o de Volumio, por ejemplo. Y SMB se usa mucho ahí fuera. Pero mucho. Incluso los dispositivos de la familia Sonos lo hacen.

Configuración de la biblioteca musical de un Sonos One utilizando una carpeta de red SMB.
¿Y qué ocurre con los reproductores que en cambio optan por UPnP/DLNA? En estos casos se admite el uso tanto de TCP como de UDP, siendo creencia extendida que la emisión del audio se realiza siempre sobre UDP. Vamos a ver si es verdad.

Probemos primeramente con Banshee, un sencillo reproductor para Linux que también es capaz de conectarse con servidores UPnP/DLNA, en este caso uno del tipo miniDLNA.

Banshee en acción.
pablo@menos:~$ sudo netstat -antup | grep banshee


tcp       0  0  127.0.0.1:8089       0.0.0.0:*           ESCUCHAR     373/banshee
tcp       0  0  192.168.1.101:40450  192.168.1.100:9000  ESTABLECIDO  373/banshee
tcp  808400  0  192.168.1.101:60384  192.168.1.100:8200  ESTABLECIDO  373/banshee
tcp       0  0  192.168.1.101:60356  192.168.1.174:8008  ESTABLECIDO  373/banshee
tcp       0  0  192.168.1.101:58760  138.201.227.205:80  ESTABLECIDO  373/banshee
tcp       0  0  192.168.1.101:40428  192.168.1.100:9000  ESTABLECIDO  373/banshee
udp   28224  0  0.0.0.0:1900         0.0.0.0:*                        373/banshee
udp   35904  0  0.0.0.0:33238        0.0.0.0:*                        373/banshee     

Conexiones TCP establecidas (3 con el servidor de medios UPnP en 192.168.1.100) y 2 puertos de tipo UDP a la escucha. Ahora servidor y reproductor están dentro de la misma red local. En esta ocasión sí podemos admitir fácilmente la posibilidad de que se esté utilizando un protocolo de transporte no fiable.

En segundo lugar, echémosle un vistazo a JRiver Media Center en su faceta de cliente UPnP/DLNA contra el mismo servidor.

El gran JRMC en Linux.
pablo@menos:~$ netstat -antup | grep mediacenter24

tcp     0  0  0.0.0.0:52100        0.0.0.0:*           ESCUCHAR     2372/mediacenter24
tcp     0  0  0.0.0.0:52102        0.0.0.0:*           ESCUCHAR     2372/mediacenter24
tcp     0  0  0.0.0.0:52103        0.0.0.0:*           ESCUCHAR     2372/mediacenter24
tcp     0  0  0.0.0.0:52199        0.0.0.0:*           ESCUCHAR     2372/mediacenter24
tcp     0  0  192.168.1.101:32928  192.168.1.100:8200  ESTABLECIDO  2372/mediacenter24
udp  3456  0  0.0.0.0:52100        0.0.0.0:*                        2372/mediacenter24

Similares resultados a los obtenidos con Banshee, ¿no te parece? Ahí tenemos también un puerto UDP abierto (52100).

¿Y qué pasará si cambiamos miniDLNA por otro servidor de medios, por ejemplo el integrado en Logitech Media Server?

pablo@menos:~$ netstat -antup | grep mediacenter24

tcp     0  0  0.0.0.0:52101        0.0.0.0:*            ESCUCHAR     2372/mediacenter24
tcp     0  0  0.0.0.0:52102        0.0.0.0:*            ESCUCHAR     2372/mediacenter24
tcp     0  0  0.0.0.0:52199        0.0.0.0:*            ESCUCHAR     2372/mediacenter24
tcp  7872  0  192.168.1.101:41960  192.168.1.100:9000   ESTABLECIDO  2372/mediacenter24

¡Sorpresa! Ni rastro de conexiones UDP. Squeezebox ama TCP.

Siguiendo los procedimientos descritos con el comando netstat puedes probar tú mismo y sacar tus propias conclusiones.

Llevamos un buen rato con numeritos en pantalla y quizás sea un buen momento para hacer una pausa y recapitular.

Por una parte, sabemos que TCP es un protocolo de trasporte seguro, orientado a conexión, que garantiza la integridad de la información transmitida. Los errores que puedan producirse son detectados y corregidos de modo transparente tanto para el usuario como para las propias aplicaciones que lo emplean. La única consecuencia sería un ligero incremente en la actividad de red en tanto que se retransmiten los paquetes dañados. Tendríamos que llegar a una situación de fallo generalizado realmente extremo, con una auténtica tormenta inacabable de errores, lo que por otra parte delataría algún problema realmente grave, para que la reproducción se interrumpiera. Recordemos además que existen espacios de memoria reservados en el reproductor (buffers) en los que se almacenan por adelantado varios segundos (o más) de la pista de audio en reproducción y que es desde donde esta se realiza realmente. Como muy acertadamente apuntaba un participante en el anteriormente mencionado hilo sobre cables ethernet en Audio Planet, basta con desconectar el cable para comprobar que la reproducción prosigue sin inmutarse durante unos segundos.

Hemos verificado también que servicios populares de audio por suscripción como Tidal o Spotify utilizan TCP. Del mismo modo, cualquier aplicación de reproducción que emplee SMB o NFS también se comunicará realmente mediante TCP. Por si fuera poco, este es también el protocolo de transporte escogido en ecosistemas Squeezebox o MPD, lo que tiene un impacto directo en la popularidad global de este protocolo de transporte (TCP) puesto que un gran número de reproductores comerciales recurren a SMB, NFS o a soluciones basadas en MPD o Squeezebox.

Por otro lado tenemos a UPnP, otro conjunto de protocolos indudablemente muy utilizado en sistemas AV. Hemos verificado que, al contrario de lo que a menudo se afirma, no siempre funciona sobre TCP. Las generalizaciones son arriesgadas.

Ahora bien, olvida todo lo anterior.

Supongamos que todos los dispositivos y reproductores de nuestra red local utilizaran un protocolo de transporte no seguro como es UDP. ¿Tendría esto algún impacto en la fiabilidad de las transmisiones? En definitiva...

¿Tendría sentido la sustitución de los cables ethernet habituales por otros de supuestamente mayor calidad y prestaciones por lo que hace exclusivamente a la consecución de una transmisión libre de errores?

Vamos a tratar de dilucidarlo con otro sencillo experimento. Si aún está ahí... llegamos al meollo del asunto.


Netstat y los errores de transmisión

Pero descendamos varios peldaños por la escalera de la arquitectura TCP/IP hasta los niveles más bajos para responder a la segunda pregunta que nos hacíamos unos cuantos párrafos más arriba, donde reconocíamos que ethernet no garantiza la transmisión libre de errores.

La cuestión es ¿realmente son estos errores de transmisión tan numerosos como para representar un peligro para la integridad del audio digital (y nuestra tranquilidad audiófila)? ¿Podemos cuantificarlos?

La respuesta es afirmativa. El comando netstat también es capaz de facilitarnos información acerca de los paquetes ethernet en los que se ha detectado algún tipo de error, con independencia de que un mecanismo de nivel superior los corrija posteriomente (TCP) o no (UDP). Es decir, lo que obtendremos será algo así como la tasa de error en bruto, lo que indudablemente representa una métrica relevante de la fiabilidad del conjunto de dispositivos ethernet involucrados. 

Por tanto, he registrado las estadísticas del adaptador de red que proporciona el sistema operativo en mi PC de pruebas en un momento determinado y me he sometido a una dura e intensa sesión de escucha continua de más de 5 horas. Durante ese tiempo he seguido trabajando con el ordenador, escribiendo este artículo en Blogger, diseñando los diagramas que lo acompañan, navegando en Internet.... lo normal. Además, dado que este pequeño experimento se ha desarrollado a lo largo de la tarde de un día festivo, la red local doméstica ha estado echado humo durante todo el tiempo: Netflix, videojuegos en red, vídeos de Youtube... red que, para acabar de situarnos, cuenta además con varios dispositivos PLC conectados en diversas habitaciones; sí de esos que al parecer inducen tantas y tan perversas perturbaciones.

Una entretenida tarde festiva de diciembre...
...con el equipo activo mientras suena buena música de fondo.
Por si fuera poco, he tenido que zarandear e incluso retorcer el cable ethernet del PC para poder tomar las fotos del apartado anterior. Sin contemplaciones.

El menú musical ha estado compuesto por:

Air, de esta estupenda banda española, gran descubrimiento reciente para mi, llamada Morgan. 41 minutos de gloria bendita reproducidos desde Tidal con Chrome (cómo me recuerdan en más de un momento a Morcheeba). Cálidos e intensos como ellos solos.

https://tidal.com/album/84653811
El Live in Concert de Natalie Merchant (54:28), una pasada de directo con temas increíbles como una inesperada versión del Space Oddity de David Bowie o auténticos torpedos emocionales como son Beloved Wife o Seven Years. Versiones FLAC que residen en una carpeta compartida vía SMB de un NAS doméstico cuyo cable de red no es en absoluto mejor que el mostrado más arriba, reproducidas por JRiver Media Center.

https://tidal.com/album/1826938
Y finalmente, la BSO completa de NieR Automata, un maravilloso videojuego con una ambientación musical más que notable. Casi 4 horas de nada. También archivos en formato FLAC almacenados en el mismo NAS, retransmitidos en esta ocasión por una instancia de Logitech Media Server corriendo en el mismo dispositivo, hacia un cliente Squeezelite en el PC desde el que escribo ahora mismo.

Este no lo tienen en Tidal ni Spotify.
Veamos las estadísticas del adaptador de red en el estado inicial (sigo en Linux):

pablo@menos:~$ netstat -i

Tabla de la interfaz del núcleo
Iface      MTU    RX-OK  RX-ERR  RX-DRP  RX-OVR    TX-OK  TX-ERR  TX-DRP  TX-OVR  Flg
enp30s0   1500  8644154       0       0       0  1464408       0       0       0  BMRU
lo       65536    49406       0       0       0    49406       0       0       0  LRU


En Windows conseguiríamos algo parecido con:

X:\>netstat -e

Y ahora echémosle un vistazo a las correspondientes al estado final, tras más de 5 horas de reproducción.

pablo@menos:~$ netstat -i

Tabla de la interfaz del núcleo
Iface      MTU     RX-OK  RX-ERR  RX-DRP  RX-OVR    TX-OK  TX-ERR  TX-DRP  TX-OVR  Flg
enp30s0   1500  11308260       0       0       0  2006796       0       0       0  BMRU
lo       65536     57204       0       0       0    57204       0       0       0  LRU

La diferencia (errores en T2 menos errores en T1) detectados en la transmisión (TX) y recepción (RX) de los más de 3 millones de tramas ethernet que han ido y venido por la red durante casi 6 horas ha sido...

CERO

Complicados cálculos ;-) por tanto arrojan una tasa de error del 0%.

Hasta aquí el experimento y los resultados, absolutamente objetivos. Ahora, mi opinión.

Balance y conclusiones

A lo largo de este artículo he pretendido analizar con la mayor objetividad posible las razones por las que un cable ethernet podría tener algún tipo de impacto sobre la calidad percibida en reproducción en un sistema de audio.

A continuación, me he centrado en tratar de valorar los problemas que pudieran derivarse de la pérdida o corrupción de la información en transito dentro de la red. Eso me ha llevado a describir, brevemente, con muchas simplificaciones y alguna que otra inexactitud, el funcionamiento de la pila de protocolos de Internet y su relación con los dispositivos de reproducción de sonido en red.

Finalmente, he mostrado los resultados de un sencillo experimento fácilmente reproducible por cualquier aficionado en su propia instalación doméstica para tratar de cuantificar la tasa de errores, que en mis pruebas ha sido del 0% durante un periodo de tiempo de casi 6 horas. Esto implica que ninguno de los 3,2 millones de paquetes que en ese tiempo han circulado por mi red local ha tenido que ser retransmitidos.

En este contexto, mi opinión es que ningún cable ethernet, por audiófilo que sea, va a suponer mejora alguna sobre los que utilizo habitualmente por lo que hace estrictamente a la integridad de la información transmitida, ni tampoco va a mejorar el ancho de banda neto de mi red puesto que ahora mismo ya alcanza prácticamente el 90% del teórico (1 Gbps), según mis propias mediciones, y no se están produciendo retransmisiones que un hipotético cableado de mayor ¿calidad? pudiera evitar.

Evidentemente esto es solo una prueba realizada en una única instalación. Bueno, realmente en dos dado que he reproducido el experimento en la red de mi centro de trabajo, con idénticos resultados. Por tanto, aunque es obvio que no se puede concluir, estrictamente hablando, generalización alguna de estas pruebas, no alcanzo a ver absolutamente ninguna evidencia que apunte a otras conclusiones distintas a las indicadas en el párrafo anterior cuando se utilizan cables ethernet convencionales, en buen estado, que cumplan las especificaciones para las que han sido diseñados.

No obstante, dejo la puerta abierta a la influencia de las posibles interferencias electromagnéticas que pudieran introducirse en el sistema a través del propio cableado ethernet y quizás otros elementos asociados a él, factor que no tengo forma de analizar. Pero solo reconozco su posible impacto en la medida en que podrían inducir perturbaciones sobre los circuitos electrónicos de los dispositivos de reproducción, especialmente en relojes y en los más cercanos a las etapas de salida. No creo que en un sistema cuya operación se mantenga dentro de unos parámetros más o menos normales de funcionamiento puedan en ningún caso afectar a la integridad del flujo de datos digital transmitido.

Mi opinión personal es que el efecto de dichas perturbaciones, si es que existe, debería ser insignificante en un sistema bien diseñado, y absolutamente improbable en el caso de cableado asociado a dispositivos tales como sistemas de almacenamiento en red, que no actúan como reproductores directos. Pero esto es eso, opinión.

¿Quiere esto decir por tanto que un cable ethernet de los denominados "audiófilos" es puro placebo? No puedo afirmarlo con total seguridad, pero mi estado mental actual me dice que sí a un 95%. Es decir, que no pondría siempre la mano en el fuego. Pero un dedo sí. Bueno, dos o tres también.

Como ves he cumplido mi palabra y no me he puesto de perfil en este asunto.

A partir de aquí, cada cual puede escuchar lo que le venga en gana y convertir su afición a la música y los cacharros que la reproducen en su cielo o infierno particular. Pero por favor, seamos todos un poco más rigurosos a la hora de utilizar argumentos para justificar opiniones y creencias en foros de aquí y de allá.  En ocasiones esto se hace con una ligereza sonrojante. Todos, y me incluyo sin falsa modestia, deberíamos ser más conscientes de nuestras limitaciones. Y también de los contextos, propios y ajenos.

Para terminar, solo decir que si algún lector, tienda, distribuidor o lo que sea quiere enviarme (con billete de vuelta ineludible) uno de esos fantásticos cables ethernet con superpoderes estaré encantado de repetir estas pruebas y contar aquí los resultados, aunque contradigan ferozmente mis conclusiones y convicciones actuales.

¡Salud y buena música para todos!

miércoles, 8 de agosto de 2018

nVida Shield TV: impresiones de uso

Ya casi no recordaba la sensación de hacer clic en el botón de Entrada nueva en este espacio. El tiempo que dedico a escribir sobre cosas #EDTECH es cada vez mayor y el que resta se ve proporcional y progresivamente reducido. Pero no sería justo responsabilizar exclusivamente a esta circunstancia de la falta de actividad en este blog. Echando la vista atrás y revisando los contenidos que dieron vida a este espacio allá por el otoño de 2007 y leyendo entradas como esta me doy cuenta de cómo el tiempo y las circunstancias modulan los intereses y, en definitiva, a personas y replicantes por igual.

La historia de este blog es, en gran medida, mi historia en Audio Planet, una comunidad de locos por la música y por los equipos que la reproducen, historia que comenzó en junio de 2010 cuando descubrí maravillado lo que allí se contaba. Y esa historia alcanzó un punto de inflexión (interior) en mayo de 2017, precisamente con aquel artículo en el que trataba de comparar de manera minuciosa Volumio con piCorePlayer, publicado tanto aquí como allí. Por el camino se han quedado miles de mensajes en Audio Planet y docenas de pruebas y publicaciones elaboradas robándole horas al sueño, a la familia y a mi vida, en general. Y siempre con un denominador común: la pasión por experimentar en un campo que me fascinaba. Y que probablemente aún me fascina, querría pensar.

Junio de 2010, ocho años de mi vida...

Desde entonces mi interés por las tecnologías digitales para la reproducción audiovisual ha menguado sensiblemente. Estoy ciertamente apático. Ya no me entusiasman determinadas cosas como solían hacerlo y, tengo que decirlo, esta desafección reciente se origina en el simple y llano aburrimiento, en la falta de emoción, en la ausencia de productos o tecnologías realmente novedosas.

Los resultados que actualmente se pueden conseguir utilizando reproductores basados en sistemas-en-un chip (Raspberry Pi, Odroid y similares) dotados de placas de conversión D/A montadas sobre sus buses I2S o asociados a sencillos DACs USB y pilotados por desarrollos gratuitos como Volumio o piCorePlayer son simplemente espectaculares. Añade a la ecuación un par de monitores activos y ahí tienes un sistema de reproducción musical de una calidad y funcionalidades que hubieran sido ciencia ficción hace cuántos ¿10 años? Y a un coste ridículo. ¿Realmente tiene sentido complicarse más la vida? Para mi yo actual, definitivamente no.

El audio digital de  alta calidad, democratizado, en cuatro instantáneas ligeramente audiopornográficas.

Por ahí dicen que el que afirma estar de vuelta de todo realmente no ha ido a ninguna parte. Posiblemente sea este mi caso, pero desde que el esoterismo audiófilo conquistó lo digital, al menos en ciertos ámbitos, trasladando, actualizando y perpetuando, cuando no inventando, prácticas, creencias y metodologías que no comparto en absoluto, tengo la sensación de que no hay nada nuevo bajo el sol. Y seguramente esté equivocado, pero esta es mi convicción actual, con la que no tengo más remedio que tratar de ser consecuente.

Pero como dice la canción, en ocasiones surgen cosas que te rescatan del naufragio y reavivan la necesidad de escribir sobre tal o cual dispositivo. Hace un par de semanas me he encontrado con una de ellas. Algo que ha (casi) enviado al banquillo de un plumazo a tres de mis artilugios de reproducción de pelis, series y música: Squeezebox Touch, Odroid C2 (con LibreELEC) y Amazon Fire TV Stick Basic. Ahí es nada.

De izquierda a derecha. Odroid C2, Squeezebox Touch y Amazon Fire TV Basic.

Hablemos pues de nVidia Shield TV.

¿Qué es nVidia Shield TV?

Shield TV es un streamer basado en Android TV. No se trata de ninguna novedad, de hecho lleva en el mercado desde el 2015 y el año pasado (2017) su hardware recibió un lavado de cara, aunque manteniendo intactas sus características técnicas definitorias. Y a pesar de sus años sigue siendo una de los cacharros más económicos (en torno a 200€), potentes y polivalentes que podemos adquirir como centro de ocio digital.

En estas cajas tan molonas llega Shield TV.

Pero no es mi intención hacer una descripción detallada del dispositivo. Si quieres conocer en detalle sus características te remito a estos dos excelentes análisis, el de la versión inicial (en Kodimania) y el correspondiente a la posterior revisión del hardware (esta vez en Salón Digital). Ambos son muy exhaustivos y tienen cierto contenido técnico. Si prefieres algo más sencillito puedes leer el que publicaron en Xataka referido a la versión más reciente.

nVidia Shield TV: mi experiencia de uso

Y  este es el objetivo del artículo. Resumir y comentar mi experiencia de uso con Shield TV en las apenas 2 semanas que lo tengo en casa. Y comenzaré por el final, diciendo que, en una palabra, es magnífica.

Las primeras impresiones del hardware del aparato son excelentes, al menos en la versión de la que dispongo, la que se lanzó en 2015 en su variante de 16 GB de almacenamiento. Sorprende su tamaño (que alcanza lo ridículo en el caso del hw 2017), aunque el peso delata que dentro hay un buen montón de tecnología en un formato extremadamente compacto. El potente SoC Tegra X1, muy similar al de la Nintendo Switch, junto a los 3 GB de RAM hace que la interfaz de usuario vuele (literalmente) y se despliegue en pantalla con absoluta suavidad (60 Hz), ofreciendo una respuesta inmediata. Acostumbrado a otros dispositivos de similar pelaje como el Amazon Fire TV Stick, también basado en Android pero con el habitual "barniz" casposillo que Amazon aplica a sus productos, la diferencia es evidente de modo inmediato.

Interfaz de control de Shield TV. Sí, admite control y búsquedas por voz mediante Google Assistant.

Además, el dispositivo demuestra una ejemplar trayectoria de actualizaciones continuadas desde su fecha de lanzamiento. De hecho, recientemente ha recibido la versión de Oreo para dispositivos Android TV. Es patente el interés por parte de su fabricante, nVidia, por corregir problemas detectados y añadir nuevas funcionalidades a través de estas actualizaciones, que se han ido produciendo de modo regular a lo largo del ciclo de vida del producto. No resulta infrecuente encontrarse con cacharros que montan unas tripas estelares comandados por un software de mala calidad que conduce a una experiencia de uso deficiente o directamente nefasta. En estos tiempos digitales el software manda tanto o más que el hardware.

Pero vamos por partes. Mi meta con Shield TV era unificar en un único reproductor, sencillo de manejar y apto para un salón familiar, varias prestaciones y funciones. Hablemos de ellas.

Objetivo 1: Servicios de retransmisión de audio y vídeo

Tidal, Spotify, Deezer, Radio Paradise, Amazon Music, Amazon Prime Video, YouTube.... Todos ellos, y muchos otros, están disponibles mediante apps nativas, adaptadas de un modo excelente al contexto de un salón (tele / mando a distancia). Además, pueden descargarse con facilidad de la tienda de aplicaciones de Google directamente en el dispositivo o encargar su instalación cómodamente desde un navegador de escritorio.

Instalando una app en Shield TV desde el navegador de un PC.

Si Amazon nos castiga con una espantosa tienda de apps en sus propios dispositivos, inexplicablemente desprovista de algo tan elemental como un buscador y con una organización de contenidos que en ocasiones es aparentemente incomprensible, aquí disfrutaremos de una experiencia similar a la de cualquier artilugio Android mondo y lirondo. Adicionalmente, Shield TV trae de serie los Google Services instalados, lo que facilita la carga de aplicaciones externas a la tienda por medio de su APK correspondiente y un sencillo explorador de archivos. Shield TV cuenta también con puertos USB a los que conectar dispositivos de almacenamiento (y otros periféricos, por supuesto) y también ranura para tarjetas SD (modelo de 2015 únicamente). Todo facilito.

Tienda de aplicaciones de Google para Android TV.

A diferencia de otros reproductores basados en Android, Shield TV es un dispositivo certificado por Netflix y por tanto admite la reproducción de vídeo a 1080p y 4K en HDR y audio en Dolby Digital Plus (similar a AC3 pero con una tasa de bits superior y soporte para más canales). nVidia ha pasado por caja cuando ha sido necesario para asegurarse de que esto sea así. La calidad en reproducción es excelente, siendo habitual que se alcancen tasas de más de 6 Mbps, cercanas al límite del servicio a 1080p.

Detalle de la tasa de bits de una emisión 1080p de Netflix (capítulo final de Sense8)...

...y audio en Dolby Digital Plus emitido en crudo hacia el receptor a través de HDMI.

Nota para nostálgicos:
Resulta sorprendente comprobar cómo han evolucionado los codecs de vídeo en unos pocos años, ahora cobijamos en un flujo digital de 3-6 Mbps una señal 1080p con audio multicanal que se ve infinitamente mejor que el vídeo a 5-10 Mbps codificado mediante MPEG2 en los vetustos DVD. Cualquier tiempo pasado no siempre fue mejor.

El manejo del dispositivo puede lograrse utilizando tanto los mandos suministrados, de control o de juegos, como el de la televisión, puesto que Shield TV soporta el estándar de interoperabilidad HDMI CEC. Con mi equipo el comportamiento es ejemplar, las secuencias de encendido / apagado / cambio de fuente / control de volumen de televisor y receptor multicanal funcionan correctamente, aunque esto es casi casi una lotería que depende mucho de lo bien que se entiendan entre sí los cacharros interconectados. Por ejemplo, mi Amazon Fire TV Stick, conectado a un puerto HDMI del receptor multicanal (Pioneer SC-LX81), se queda "dormido" y no puede ser activado ni "despertar" al resto de dispositivos a través de CEC pasado un tiempo sin ser usado, rompiendo en la práctica la magia de un control unificado con un solo mando.

Mando de control estándar (versión 2015). De aluminio, recargable, con superficie táctil de control y micrófono incorporado.

Por cierto, el mando de control de Shield TV (de aluminio en su versión 2015, muy premium y con poco que envidiar al de un AppleTV) incorpora en su mitad inferior una discreta superficie táctil de control, que fácilmente puede pasar inadvertida, para modificar el volumen e iniciar / pausar la reproducción. El ajuste puede configurarse para que este control actúe sobre el volumen interno (en software) o sobre el del dispositivo externo conectado (receptor en mi caso).

Ah, y aplicaciones más borderline, como Stremio, también funcionan perfectamente. Una gozada.

Ojeando gustosamente series en Stremio.

Por si todo lo dicho no fuera suficiente, resulta que Shield TV es también un dispositivo Chromecast. Pero no una de esas variantes descafeinadas basadas en Miracast y similares. Se trata de un Chromecast Ultra (4K) de tomo y lomo que se anuncia y aparece como tal ante otros dispositivos (ordenadores, móviles, tabletas) en la red local.

nVida Shield TV en su faceta de Chromecast: enviando audio desde Tidal en Chrome.

nVida Shield TV visto desde la app Google Home.

Es posible emitir hacia él audio y vídeo directamente desde determinadas aplicaciones compatibles o el navegador (Chrome) o simplemente clonar totalmente la pantalla del dispositivo emisor.

También podemos no obstante instalar aplicaciones freemium como AirScreen, que en su versión gratuíta constituye un eficaz receptor AirPlay a pantalla completa para i-cosas.


Lástima que, como en todos los dispositivos móviles, la app de Tidal no emita en calidad Master. Aunque bien pensado, a estas alturas casi que me da igual.

Amazon Fire TV Stick sustituido. Vamos a por lo siguiente.

Objetivo 2: Reproductor de medios locales: VÍDEO

Shield TV es un dispositivo diseñado para consumir audio y vídeo en servicios bajo demanda, lo que se lleva ahora. Y hacerlo con mucha clase. Pero eso no es ni la mitad de la ecuación. Sin tener que hacer piruetas podemos instalar VLC y Kodi. Y, por si fuera poco, Shield TV trae preinstalado tanto un cliente como un servidor Plex, con potencia de sobra para transcodificar audio y vídeo al vuelo sin problemas.

Kodi corriendo sobre Shield TV en todo su esplendor (la piel utilizada es Eminence).

Con ellos podemos reproducir prácticamente cualquier archivo de vídeo que habite en nuestra red local, por ejemplo en una carpeta compartida en un NAS. De hecho, en el panel de ajustes de Shield TV existe una sección destinada a explorar y montar sobre el sistema de archivos local, de modo permanente, recursos en nuestra red doméstica. No es necesario ni con Kodi ni con VLC, que son capaces por sí mismos de explorar la red, pero da una idea de la orientación del dispositivo, que abre el acceso a los recursos en red local a cualquier app instalada localmente. Muy bien.

Explorando y montando dispositivos de almacenamiento en la red local.

Sin quitarle el mérito a VLC ni a Plex, para mi el paradigma de reproductor de medios local no es otro que Kodi. De hecho, ha venido siendo mi reproductor de vídeo de cabecera en el equipo del salón desde mayo de 2013 a lo largo de varias generaciones de Raspberries (inicialmente usando Raspbmc y posteriormente su sucesor espiritual, OSMC) y, hará cosa de un año, con LibreELEC corriendo en una fantástica Odroid C2.

Kodi en Shield TV funciona mejor que bien. ¿Decodificación hardware de HEVC de 10 bits (H.265), VP9 y 4K con HDR via HDMI 2.0b? Sí. ¿Cambio automático de frecuencia de refresco con soporte de 23,976 y 24 Hz? Por supuesto. ¿Passthrough de AC3, DTS, TrueHD y DTS-HD hacia el receptor multicanal? También. ¿Complementos instalables? Sin dudarlo. ¿PCM multicanal hasta 192/24? Concedido. ¿Capacidad para ejecutar pieles pesadas? Potencia de sobra. Y toda la compatibilidad de formatos que Kodi proporciona, incluyendo contenedores ISO, DFF/DSF (incluso con remuestreo en alta calidad), etc. etc. nVidia se ha asegurado de que este reproductor corra en su creación a las mil maravillas. Otro minipunto.

Emisión de audio en crudo a tutiplén en Kodi.

De Plex no diré nada dado que no lo he utilizado de un modo extensivo, pero por lo que he leído su  funcionamiento es bueno. Con respecto a VLC,  más de lo mismo, se trata en este caso de una alternativa ideal si no queremos líos configurando bibliotecas y tal y, en mi experiencia, funciona correctamente.

Y ya tenemos también sustituto para LibreELEC en la Odroid C2.

Objetivo 3: Reproductor de medios locales: AUDIO

¿Y qué tal como reproductor de audio? Bueno, Kodi cataloga y gestiona extensas bibliotecas de archivos de audio sin mayor problema, para muchos eso será más que suficiente.

Personalmente llevo utilizando en casa un ecosistema Squeezebox desde hace un montón de años y me siento muy cómodo con él. Es extremadamente flexible y potente, admite la integración de casi cualquier servicio y dispositivo de reproducción y dispone de una de las mejores apps de control (iPeng). ¿Puede dar cobijo también a Shield TV este entorno? Pues resulta que sí, y casi de modo inmediato, gracias a su papel Chromecast. Solo tenemos que instalar en el servidor de medios de Logitech (LMS), el complemento Chromecast bridge. Shield TV aparecerá como un Squeezebox más, con capacidad de reproducir audio de modo nativo a 96/24. Los archivos codificados a resoluciones superiores serán remuestreados automáticamente por el servidor LMS, como es habitual en este sistema.

Panel de configuración de Chromecast bridge para LMS.

Un reproductor Squeezebox más en la familia, aquí tirando audio a 192/24 (remuestreado a 96 Khz).

iPeng en acción controlando a nuestro Shield TV disfrazado de Squeezebox.

En este caso, no obstante, y como consecuencia de este doble salto mortal hacia atrás para conseguir que Shield TV se lleve bien con LMS, surge alguna que otra limitación. La reproducción continua (sin pausas entre temas) no funciona por el momento. Ni tampoco las pistas en AC3 o DTS. Como hemos visto, Shield TV no tiene mayor problema en hacer passthrough de estas cosas, pero en su faceta Chromecast solo lo admite cuando se usan apps como la de Netflix. Nos topamos por tanto con una de esas malditas limitaciones impuestas por el software.

Bueno, siempre podemos recurrir a Kodi como reproductor universal, que no está nada mal, y en el que los contratiempos descritos más arriba desaparecen, o quizás explorar la posibilidad de instalar en  Shield TV alguno de los desarrollos basados en Squeezeplay disponibles.

De un modo u otro, en este caso no me atrevo por tanto a afirmar que Shield TV sea una alternativa perfecta a un reproductor de tipo Squeezebox, pero si no se tienen muchas manías está cerca, muy cerca.

Otras funciones

Y podríamos seguir hablando de características apetitosas que nos ofrece Shield TV, por ejemplo la extensiva compatibilidad con dispositivos bluetooth, pero no solo teclados y ratones, sino también auriculares, altavoces o barras de sonido. De hecho existe un ajuste para compensar el posible desfase entre audio y vídeo, caso de que se produzca, en su panel de control.

Ajuste de sincronización audio / vídeo, importante cuando se emplea un dispositivo de audio externo.

Otra característica destacable es la compatibilidad con DACs USB, para los que Shield TV dispone de un modo de emisión de audio de alta calidad, sin remuestreo forzado.

Modos de audio USB.

Por otro lado, el controlador cuenta con un micrófono desde el que enviar órdenes al Asistente de voz de Google para abrir aplicaciones, realizar búsquedas, etc. En los nuevos mandos de juegos (versión 2017), este micrófono está en modo de escucha permanente, por lo que esencialmente tenemos un Google Home... con aspecto un tanto extraño, eso sí.

Y todo eso sin hablar de GeForce Now, la plataforma de videojuegos en streaming de nVidia, que permite jugar del mismo modo que consumimos audio en Spotify o vídeo en Netflix utilizando la potencia de procesamiento de los servidores en la nube de la compañía, algo que funciona sorprendentemente bien y que en mi opinión es el futuro al que nos dirigimos por lo que hace al consumo de videojuegos.

Como puedes ver, Shield TV es una auténtica navaja suiza del streaming. Y ni siquiera hemos hablado de sus capacidades emulando recreativas y consolas antiguas. La perfección no existe, pero en mi opinión su enorme colección de virtudes, su comedido precio y el que hasta el momento ha sido un excelente soporte convierten a este atractivo cachivache en un dispositivo a tener muy en cuenta como centro neurálgico de entretenimiento digital en el salón.

En cuestiones audiófilas no entramos, claro está.