domingo, 27 de enero de 2019

Mini análisis de Strawberry: Tidal en bitperfect en Linux (y más cosas)


Los aficionados que usamos Linux habitualmente andamos un poco dejados de la mano de Dios por lo que hace al abanico de reproductores de audio a nuestra disposición.

Sí, es posible correr Foobar en bitperfect e incluso reproducir con él DSD (vía DoP), tal y como explicaba en este artículo anterior.

También podemos tirar mano de JRiver Media Center (del que soy usuario de licencia maestra desde hace tiempo), aunque personalmente la interfaz me parece que está hecha con los pies y la usabilidad... pues eso, que es más bien tirando a regularcilla.

Por último, cabe recurrir a algún tinglado con Squeezelite, por ejemplo tal y como cuento aquí.

¿No hay más opciones? Pues claro, docenas de ellas, así sin pensarlo mucho se me ocurren reproductores como Audacious, Rhythmbox, Clementine, Lollypop (por cierto, el único con una interfaz elegante, en mi opinión), Amarok, DeaDBeeF, Elisa... y muchos más.

El problema es que unos y otros suelen tener carencias en aspectos que hoy en día consideramos básicos:
  • Funciones de gestión de biblioteca.
  • Compatibilidad con ALSA (para emitir en bitperfect).
  • Edición de etiquetas.
  • Compatibilidad con formatos de audio (por ejemplo, DSD).
  • Descarga de carátulas de Internet.
  • Conexión con servicios en línea.
  • Interfaz de usuario no absolutamente paleolítica Rolling Eyes.
  • ...y ponga usted aquí lo que quiera (que cosas faltan a puñados).
El caso es que trasteando un rato me he encontrado con una alternativa gratuita y de código abierto que, sin ser la caña de España, me parece más que interesante en este contexto Linuxero y por tanto me gustaría compartir con vosotros.


Strawberry es un fork de Clementine, es decir un desarrollo realizado por otro programador a partir de la aplicación original, estando disponible para Windows, MacOS y Linux. Lógicamente me voy a centrar en esta última plataforma. Ventajas del modelo de desarrollo de código abierto.

Para los impacientes, la descarga aquí: https://www.strawbs.org.

Si no os apetece compilarlo a partir de los fuentes, encontraréis paquetes instalables aquí: https://builds.strawbs.net.

Esto no es en modo alguno un tutorial, así que simplemente voy a comentar brevemente ciertos aspectos por los que Strawberry me parece una opción a tener en cuenta.

Comencemos por la interfaz de usuario. Nada espectacular, con la tradicional yuxtaposición de elementos tales como barra de componentes (contexto, luego volveremos a él,  colección, archivos, listas, cola, dispositivos y ¡sí, Tidal!) y paneles correspondientes (izquierda), lista de reproducción (derecha) y visualización espectral de turno con información de la pista en reproducción y botonera de control (abajo).

Strawberry en acción.
Aires viejunos, pero funcionales.

La colección musical (biblioteca) puede explorarse utilizando las típicas vistas (artista, álbum, género y combinaciones de ellas).

Ajustes de agrupamiento de la biblioteca musical.
Además, es posible ajustar algún que otro aspecto de su funcionamiento y aspecto (lejos, no obstante de las barbaridades de Foobar o JRiver Media Center, por supuesto). Veamos algunos de sus paneles de configuración.

Comportamiento general. Algo tan molesto como que el reproductor haga lo que le de la gana, que no suele coincidir con lo que el usuario quiere, cuando se hace doble clic sobre un elemento de la biblioteca puede evitarse fácilmente.

Ajustes generales.
Ajustes de notificaciones.

Configurando las notificaciones de Strawberry.
Podemos utilizar las del sistema o las del propio Strawberry (que son más vistosas) y determinar cuándo y durante cuánto tiempo se mostrarán.

Notificaciones nativas de Strawberry, con carátula y metadatos.
Configuración (ligerita) del aspecto de la interfaz de usuario. Paleta de colores (dos tonos) y posibilidad de utilizar un fondo dinámico a partir de la carátula del disco que está sonando. No está mal.

Para darle un toque personal a la interfaz de usuario...
Pero hay otras características que, en mi opinión, son más destacables.

Strawberry es capaz de monitorizar una colección esparcida por varias carpetas en el sistema de archivos:

Indicando dónde tenemos las carpetas con musiquita.
En mi Ubuntu no es capaz de acceder a recursos de red montados dinámicamente de modo inmediato (no aparecen en el cuadro de diálogo), pero no hay más que buscar los puntos de montaje automáticos en...

/run/user/xxxx/gvfs

...como se ve en la imagen para solucionarlo.

No lo dice por ninguna parte, pero cuando reproducimos un disco sin carátula, Strawberry la busca en Internet y la incorpora a la biblioteca él solito:

Descarga automática de carátulas de álbums de la biblioteca.
De hecho, hay un práctico menú contextual para gestionar las carátulas (clic con el botón derecho de la rata sobre la portada)...

Acciones contextuales sobre el álbum en reproducción.
...que da acceso a un fantástico gestor / buscador de carátulas en servicios en línea (Search for album covers):

Imágenes descargadas de Internet y propuestas por el gestor de carátulas para el álbum seleccionado.
El gestor de carátulas dispone de su propio comando de menú...

El menú de herramientas esconde cositas interesantes...
...e incluso es capaz de identificar todas las que nos faltan y recuperarlas en bloque, además de exportarlas.

Gestor de carátulas de Strawberry en todo su esplendor.
Se dispone de un control magnífico sobre el sistema de reproducción: motor, tipo de salida y dispositivo. OSS, PulseAudio, A2DP (bluetooth), virtual, Jack. Muy completito. Asimismo, se puede escoger el dispositivo HW por nombre o ID. Control total, muy guay. Por tanto, Strawberry es bitperfect.

Completas opciones sobre el dispositivo de audio.
Podemos ajustar el tamaño del buffer y su pre-llenado. También hay controles relativos a los ajustes de ganancia (vía metadatos), así como una función para evitar clipping digital como consecuencia de su aplicación. Del mismo modo, es posible activar un fundido entre pistas con controles muy granulares. Lógicamente los audiófilos deberían mantenerse lejos de estas cosas (ajuste de ganancia y fundidos).

Si usamos ALSA, Strawberry ajustará dinámicamente las propiedades del dispositivo de audio. Aquí lo vemos reproduciendo 88/24 sin el remuestreo característico de Pulse y en modo exclusivo.

Reproduciendo PCM 88/24 sin remuestreo y en modo exclusivo. La consola nunca miente.
Pero sigamos... Resulta que también hay funciones de conversión de formatos, que se utilizan cuando se conecta un dispositivo de audio portátil (¿os acordáis del menú Dispositivos?) o simplemente bajo demanda. No son lo más exhaustivo del mundo, pero pueden venirnos bien en un momento dado. En principio Strawberry puede exportar pistas a dispositivos iPod, iPhone, MTP o simplemente a aquellos que aparecen como almacenamiento USB (no lo he probado personalmente, Spotify sin conexión en el móvil redujo a la irrelevancia esta funcionalidad para mi hace tiempo).

Ajustes de transcodificación (conversión de formatos) de audio.
De listas de reproducción y scrobbling (emitir en plan exhibicionista los metadatos de lo que estamos escuchando) no comento nada porque son funciones que no utilizo demasiado. Pero Strawberry también cumple aquí:

Ajustes relativos a listas de reproducción y scrobbling.
Y sí, tenemos integración (básica) con Tidal.

¡Tidal en Strawberry!
Lamentablemente no se pueden recorrer las listas de reproducción, generales o personalizadas, o los artistas o discos que hemos añadido a nuestra biblioteca personal. Solo realizar búsquedas. Y no, nada de másters (pero sí HiFi). De hecho, Strawberry es una de las maneras más sencillas de disfrutar de Tidal en Linux en bitperfect.

Buscando cosas en el catálogo de Tidal desde la interfaz de Strawberry.
Deezer también está soportado, pero por razones técnicas la cosa es complicada en Linux. Por esa razón, el autor ha optado por eliminar la funcionalidad en esta plataforma.

Con respecto a la compatibilidad con formatos de audio, se admiten los siguientes:

WAV, FLAC, WavPack, DSF, DSDIFF, Ogg Vorbis, Speex, MPC, TrueAudio, AIFF, MP4, MP3, ASF and Monkey's Audio

Para que la reproducción de DSD (DSF, DSDIFF) funcione correctamente, nuestra distribución de Linux deberá utilizar GStreamer y libav en sus versiones 1.15.1 (o superiores, supongo). Podemos averiguar cuáles son las instaladas mediante este comando:

gst-launch-1.0 --gst-version

En mi caso (Ubuntu 18.04 LTS) ando por la 1.14.1, así que algo habrá que hacer al respecto, aunque para mi la compatibilidad con DSD no es en absoluto una función crucial, francamente.

Ni rastro de compatibilidad con ISO de SACD o DVD-A, sin embargo. A extraer pistas toca. Afortunadamente es un tema muy superado.

Más cositas... y viene una buena. Strawberry también permite editar los metadatos (tags) de las pistas a través de un editor incorporado:

Editando los metadatos fácilmente sin salir de Strawberry.
Edición múltiple de pistas, carátulas, integración con el servicio de identificación de MusicBrainz, contadores de reproducción.... muy, muy chulo.

Volviendo a los paneles principales de la interfaz, me gustaría destacar el denominado Context, que nos indica qué y cómo se está reproduciendo y sugiere otros elementos de la biblioteca, aunque de un modo muy rudimentario. No esperéis aquí nada parecido a Spotify o Roon. ¿Quizás esto "apunte maneras" en futuras versiones? Veremos. Y sí, también muestra las letras del tema que está sonando, si así lo queremos.

Panel de información sobre la reproducción en curso.
Y vamos llegando al final de este breve recorrido por Strawberry. Veamos, ¿qué me dejo? Seguro que muchas cosas. ¡Ah, sí!... ¿He mencionado que disponemos de un ecualizador integrado con perfiles?

El sencillo ecualizador gráfico incorporado. Lástima que no sea de tipo paramétrico.
¿Y de reproducción de vetustos cedés, para los más románticos?

¿Alguien sigue usando regularmente cedés ahí fuera?
¿Y de un panel de gestión de listas multipestaña con un completo menú contextual para actuar sobre las pistas? Todo muy bien pensado, la verdad.

Panel multipestaña para las listas de reproducción que vamos creando.
Incluso nos encontramos con una enigmática consola a la que le podemos ¿lanzar comandos? (¿más "maneras apuntadas", quizás para permitir automatizar cositas con scripts en un futuro?).

¿Y esto para qué sirve? ¿Alguna automatización?
Recapitulemos pues. Tenemos un reproductor que:
  • Reproduce una gran variedad de formatos, incluso de alta resolución.
  • Es bitperfect.
  • Gestiona una biblioteca musical.
  • Edita metadatos.
  • Busca carátulas en Internet.
  • Maneja múltiples listas de reproducción.
  • Reproduce CD.
  • Descarga letras.
  • Cuenta con funciones de ecualización.
  • Convierte y exporta entre formatos.
  • Se integra con Tidal.
  • Es razonablemente configurable.
  • Es estable.
  • Se integra bien con el escritorio de Linux.
  • Denota un evidente cuidado en su diseño, funciones y usabilidad.
Y además es multiplataforma (Windows, MacOS, Linux) y de código abierto, con todo lo que eso supone por lo que hace a su evolución y continuidad.

En fin, que Strawberry se ha convertido, sin comerlo ni beberlo, en mi reproductor de cabecera en Linux. Creo que, teniendo en cuenta todo lo anterior, nos encontramos ante un excelente reproductor, bien diseñado, rico en funciones y muy usable.

Con respecto a la calidad del sonido tengo que decir que a mi me suena estupendamente, especialmente a través de ALSA. Pero ya sabéis que no comulgo en absoluto con misterios audiófilos, y si son digitales, aún menos.

Cualquier cosa, comentamos aquí abajo o en el hilo que he abierto en Audio Planet.

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:~$ 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:~$ 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:~$ 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 además 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 asimismo 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ás 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

El número de errores 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 ;-) que 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!