ES2291676T3 - Procedimiento y dispositivo para la reproduccion sincronizada de flujos de datos. - Google Patents

Abstract

Procedimiento para la reproducción de flujos o paquetes de datos transmitidos a través de al menos una red (4), mediante al menos dos equipos de reproducción (1, 2) conectados al menos indirectamente a la red (4), caracterizado porque para la sincronización de la reproducción con los al menos dos equipos de reproducción (1, 2), uno de los equipos de reproducción que sirve de maestro (1) define su reloj interno como referencia y los otros equipos de reproducción (2) que sirven de esclavos ajustan su reloj interno, a través de la red (4), al del maestro (1), o bien llevan una copia del reloj de maestro, efectuando la reproducción de flujos o paquetes de datos en función de dicho reloj ajustado o de la copia del reloj de maestro.

Description

Procedimiento y dispositivo para la reproducción sincronizada de flujos de datos.

Ámbito técnico

La presente invención se refiere a un procedimiento para la reproducción de flujos o paquetes de datos transmitidos a través de al menos una red, mediante al menos dos equipos de reproducción conectados al menos indirectamente a la red. Asimismo, se refiere a un programa de procesamiento de datos para realizar un procedimiento de este tipo, así como a un dispositivo para realizar un procedimiento de este tipo.

Estado de la técnica

La transmisión de flujos de datos multimedia, almacenados en formato digital, a través de una infraestructura de redes, el almacenamiento de dichos flujos en equipos similares a ordenadores y la reproducción en aplicaciones tanto profesionales como domésticas están ya omnipresentes. Particularmente en el ámbito de audio, al haber logrado reducir fuertemente las velocidades y los volúmenes de datos, necesarios para la transmisión y el almacenamiento, gracias a procedimientos de compresión efectivos (MP3). En el segmento de vídeo, hay mucha gente trabajando febrilmente por conseguir procedimientos de compresión cada vez mejores (MPEG-4) para permitir también aquí la disponibilidad "online" y, por ejemplo, la llamada en tiempo real de largometrajes con la infraestructura usual (DSL, módem alámbrico y PC). En el ámbito doméstico se abriría un gran mercado, si los datos de audio se sincronizaran con mucha precisión, sin pérdida de calidad, es decir de forma digital con corrección de errores, siendo emitidos por diversos medios, pero en particular por radiotransmisión. Los procedimientos conocidos hasta ahora (por ejemplo, la modulación analógica de los datos en soportes de alta frecuencia sin canal de retorno) no son de alta calidad ni son de funcionamiento seguro. Los sistemas fiables, capaces de distribuir de forma fiable, por ejemplo, también un S/PDIF (Sony/Philips Digital Interface, salida de audio digital) u otras señales de audio analógicas, sin pérdida notable de calidad (es decir, con canal de retorno), a través de una infraestructura alámbrica o inalámbrica, no están disponibles hasta la fecha.

El documento EP-A-0542345 describe un procedimiento para la reproducción de datos a través de una red de datos, en la que están dispuestos varios equipos de reproducción. Uno de estos equipos se define como maestro en la red. El maestro se asigna, por ejemplo, en un procedimiento automático. El objetivo de dicho maestro consiste en emitir y coordinar de forma centralizada señales de control. Al parecer, la sincronización de la reproducción de los datos se realiza individualmente.

Ramanathan y col., en el documento "Adaptive feedback techniques for synchronized multmedia retrieval over integrated networks" (IEEE/ACM Transactions on Networking; abril de 1993, páginas 246 - 259), describen un procedimiento para la sincronización de la reproducción de datos con varios equipos de reproducción, sirviendo uno de dichos equipos de reproducción de maestro. Esto se consigue mediante un procedimiento de señalización, un "feedback approach", de los equipos de reproducción a un servidor central. Éste envía cantidades de datos que dependen del estado de sincronización de los respectivos esclavos.

Descripción de la invención

Por lo tanto, la invención tiene el objetivo de proporcionar un procedimiento que permita reproducir sin errores y de forma sincronizada flujos o paquetes de datos transmitidos a través de al menos una red, mediante al menos dos equipos de reproducción conectados al menos indirectamente a la red.

Este objetivo se consigue por el hecho de que para la sincronización de la reproducción con los al menos dos equipos de reproducción, uno de los equipos de reproducción que sirve de maestro define su reloj interno como referencia y los otros equipos de reproducción que sirven de esclavos ajustan su reloj interno, a través de la red, al del maestro, efectuando la reproducción de flujos o paquetes de datos en función de dicho reloj ajustado.

Por lo tanto, la esencia de la invención consiste en garantizar la sincronización de los distintos equipos de reproducción mediante la definición de un reloj de referencia. El término reloj, sin embargo, no ha de entenderse en el sentido exacto, sino más bien en el sentido de un sistema de referencia temporal, dentro del cual todos los miembros del sistema, es decir, el maestro y los esclavos, se ejecutan igual. Dicho con otras palabras, es posible tanto que el citado reloj no corresponda en absoluto a la hora real, como que su velocidad de avance difiera de la velocidad de avance de un reloj. Lo único importante es que los distintos miembros trabajen entre sí en un sistema de tiempo idéntico con el mismo ritmo. Dicho con otras palabras, dado el caso, los esclavos llevan simplemente un reloj o sistema de referencia de avance síncrono con el maestro, para la reproducción de los datos, sin que el reloj o sistema de referencia tenga que ser idéntico al reloj real, existente en el esclavo. Entonces, se realiza ciertamente una copia separada del reloj maestro en los esclavos. Por consiguiente, la sincronización esencial en el marco de esta invención no aspira en primer lugar a poder garantizar condiciones de tiempo real, sino más bien a garantizar la máxima integridad de datos posible, no siendo de máxima importancia el momento de la reproducción, sino únicamente la sincronización relativa. Lo esencial del sistema de sincronización propuesto es que no se trata de que el maestro esté encargado de mantener sincronizados los distintos esclavos, sino de que los distintos esclavos son responsables ellos mismos de su adaptación al maestro, lo cual realizan ellos mismos. Esto ofrece la ventaja de que el maestro no tiene que estar informado obligatoriamente sobre qué otros miembros en la red estén participando en ese momento de forma sincronizada. De esta manera se simplifica considerablemente la administración de un sistema. El maestro únicamente pone a disposición su reloj y el maestro tampoco cambia él mismo este sistema de referencia, aunque difiera mucho de una hora real.

Según una primera forma de realización preferible de la presente invención, en la red se trata de una red en la que se transmiten de forma asíncrona paquetes de datos. La sincronización de flujos de datos tiene relevancia especialmente si la red no es determinante, es decir, si los datos son transmitidos de forma asíncrona. En una red asíncrona no se puede partir de que los datos tarden siempre el mismo tiempo de un punto A a un punto B. Además, los datos no se transmiten a un ritmo constante. Correspondientemente, en una red de esta índole, los datos llegarán de forma inherente, en momentos distintos y por vías distintas (por ejemplo, a través de switches o routers) a los equipos de reproducción, por lo que la sincronización tiene especial importancia.

Según otra forma de realización preferible, el ajuste de la hora en el esclavo se produce no sólo antes de la primera reproducción durante la conexión o conexión adicional del esclavo, sino más bien también periódicamente durante la reproducción de los datos. Esta actualización es importante especialmente en el caso de flujos de datos largos, coherentes, ya que incluso las menores diferencias de la velocidad de avance del reloj interno del maestro y del esclavo pueden provocar una gran diferencia a lo largo de un tiempo prolongado. Típicamente, una sincronización nueva de este tipo se produce cada 30 segundos. Preferentemente, la actualización periódica se usa para realizar en el esclavo una adaptación sistemática de la velocidad de avance del reloj interno del esclavo a la del maestro para compensar diferencias en la característica del tiempo de retardo interno del maestro y el esclavo. Una adaptación sistemática de este tipo que permite cierto "arrastre" entre el esclavo y el maestro, es similar al ajuste de los relojes clásicos en redes (ntp, Network Time Protocol). De este modo, se garantiza una adaptación entre los sistemas de tiempo del maestro y el esclavo y se evita que en caso de un emparejamiento incorrecto simplemente se omitan por ejemplo paquetes de datos en el esclavo o se añadan espacios en blanco para compensar diferencias del tiempo de retardo. No obstante, en caso de grandes diferencias de tiempo (típicamente, por ejemplo, de más de 100 ms en el ámbito de audio) que, sin embargo, típicamente se producen sólo en caso de problemas en la transmisión de datos, puede ser necesario realizar la reproducción en el esclavo mediante este tipo de intervenciones graduadas. Típicamente, la adaptación sistemática consiste en escalar el reloj interno del esclavo o su velocidad de avance con un factor de corrección
constante.

El ajuste del reloj interno en el esclavo puede realizarse de distintas maneras. Lo importante es especialmente que no se consulta simplemente el tiempo en el maestro y después de inicia su transición tal cual en el esclavo, sino que se tiene en cuenta el hecho de que la transmisión del tiempo o su consulta a través de la red también ha tardado cierto tiempo. Precisamente con la precisión de tiempo deseada en el marco de esta invención, en el ámbito de los tiempos de transmisión típicos en redes, debería tenerse en cuenta esto. Preferentemente, se procede de tal forma que el reloj interno del maestro sea consultado por el esclavo, preferentemente varias veces, y que al menos uno, preferentemente una pluralidad de paquetes de datos que pueden ser idénticos a paquetes para consultar el tiempo en el maestro, se transmitan del esclavo al maestro y de vuelta, y el reloj interno en el esclavo se adapte al reloj en el maestro, en función especialmente de un tiempo de retardo medio de paquetes de datos entre el maestro y el esclavo. Dicho con otras palabras, mediante varias consultas se determina un tiempo medio de ejecución de datos, tal como es típico para la red específica, y sólo después de conocer este tiempo típico de ejecución de datos se adapta el tiempo en el esclavo, teniéndolo en cuenta. Para ello, sin embargo, normalmente no sólo es relevante el tiempo de retardo de datos a través de la red, sino también los tiempos de tratamiento en los equipos. Por lo tanto, adicionalmente al tiempo de retardo como valor medio deberían tenerse en cuenta los tiempos de procesamiento en los equipos, habitualmente como aportación aditiva constante, adicional.

Al poner en servicio un sistema de este tipo de equipos de reproducción, es importante definir a tiempo un maestro para que los distintos equipos de reproducción no intenten todos mutuamente compensarse unos respecto a otros. Según una forma de realización preferible de la invención, esto se hace de forma ventajosa de tal manera que el primer equipo de reproducción encargado de la reproducción se defina automáticamente como maestro. Típicamente, esto se realiza de tal forma que un equipo, al ser invitado a reproducir, se entiende inicialmente como maestro potencial, pero no inicia acciones típicos del maestro. En el momento en que reciba una consulta de otro equipo de reproducción, de facilitar el flujo de datos reproducido, el equipo se convierte en maestro. El aparato que realiza la consulta se convierte automáticamente en esclavo. Evidentemente, también es posible definir un aparato como maestro, pero esta solución tiene la desventaja de que, si dicho maestro no debe operar o si falla alguna vez por cualquier razón, el sistema se encuentra en un estado indefinido. De manera correspondiente, además debería especificarse en el protocolo que, en caso del fallo o la desconexión del maestro actual, se defina automáticamente como nuevo maestro en la red el primer equipo que lo realice asumiendo inmediatamente la función de maestro.

El procedimiento propuesto se aplica preferentemente en el ámbito de datos de audio o de vídeo digitales o una combinación de ellos. De forma especialmente preferible, en los datos o flujos de datos se trata de ficheros de audio comprimidos o no comprimidos tales como MP3, WAV, MPEG, Windows Media, etc.. Generalmente, en la reproducción puede tratarse o bien de la reproducción llamada "multi-room", es decir, la reproducción de ficheros de medios, especialmente, ficheros de audio idénticos, de forma sincronizada, o bien, de la reproducción llamada "multicanales" en la que, especialmente en el caso de ficheros de audio en formato estéreo o multicanales como, por ejemplo, Dolby 5.1, DTS etc., los diferentes canales de reproducen en diferentes equipos de reproducción.

Según otra forma de realización preferible de la presente invención, al menos una parte de los flujos o paquetes de datos se almacena de forma intermedia antes de la reproducción en los equipos de reproducción, situándose el almacenamiento intermedio de los ficheros de audio típicamente en un intervalo de aprox. 1 a 5 seg. Preferentemente y con una gran ventaja, por ejemplo, en el caso de aplicaciones lingüísticas en tiempo real, el almacenamiento intermedio es dinámico y se adapta a las circunstancias de la red. Cuanto más pequeños sean los búfer, tanto más corta será el tiempo de latencia que se debe esperar hasta que se pueda reproducir un stream. Por consiguiente, resulta ventajoso usar búfer pequeños. Cuanto mayor sea la calidad de la red empleada, tanto más pequeños podrán ser los búfer, porque en este caso se requieren menos fallos y, por tanto, también menos repeticiones. Una alocación dinámica tiene en cuenta de forma óptima este hecho y puede usarse para optimizar el tiempo de latencia. Este búfer que, preferentemente, tiene lugar en un llamado búfer anular, permite una sincronización exacta en un lado, a saber, igualando simplemente el puntero de salida en el maestro y el esclavo, y por otra parte, así resultan también mucho más fáciles los mecanismos de corrección (los llamados protocolos de reintento), lo que es de gran importancia en relación con la integridad de datos a la que se aspira aquí.

Especialmente en relación con la salida de ficheros de audio resulta ventajoso concebir la sincronización de los distintos equipos de reproducción en el rango de menos de 100 ms. Preferentemente, las diferencias del tiempo de retardo deben ser inferiores a 10 ms o inferiores a 2 ms, especialmente inferiores a 1 ms. De la psicoacústica se conoce que un oído normal es capaz de percibir como eco diferencias mayores del tiempo de retardo, superiores a 30 ms, que es justo lo que pretende evitar la presente invención. Se ha mostrado que también en el modo "multicanales" ya existente basta con una precisión del orden de 1 ms. En una red típica, la sincronización de flujos de datos con esta precisión ya no puede garantizarse sin una sincronización activa de los distintos equipos de reproducción, en especial, sin la sincronización activa no es posible conectar simplemente otros miembros. En la red se trata típicamente de una red alámbrica clásica, pero preferentemente se puede tratar también de una red inalámbrica, especialmente de una red de radiotransmisión (por ejemplo, Wifi, wireless fidelity (fidelidad inalámbrica), también llamado IEEE802.11b, o estándares sucesores con una mayor velocidad de datos como, por ejemplo, IEEE802.11a). Si, como propone otra forma de realización preferible de la presente invención, se ha de conectar otro equipo de reproducción de manera sincronizada, esto se efectúa preferentemente de tal forma que el equipo conectado adicionalmente se ajusta automáticamente al maestro existente iniciando él mismo la reproducción tras el almacenamiento intermedio de una parte de los datos. Asimismo, eventualmente puede resultar muy ventajoso poder ajustar de manera selectiva el retardo de un cliente con respecto al maestro. De este modo, los espacios grandes, tales como iglesias etc. pueden alimentarse mucho mejor de datos acústicos, pudiendo compensarse las propiedades acústicas/los tiempos de retardo en este tipo de edificios. En este caso, sin embargo, se trata de un retardo selectivo, es decir, deseado y sistemático. La diferencia de tiempo correspondiente en la reproducción en diferentes equipos está ajustada de forma constante y sigue sin-
cronizada.

Como fuentes de datos para el maestro pueden entrar en consideración diferentes fuentes de datos. Los paquetes o flujos de datos o bien, pueden recogerse de un servidor de datos separado, o pueden ser enviados por éste, o pueden recogerse en uno de los equipos de reproducción o ser enviados por éste, o pueden estar disponibles ya en los equipos de reproducción, o pueden ponerse a disposición al sistema en forma digital tras alimentarse en forma analógica, mediante un convertidor analógico/digital.

Otra forma de realización preferible se caracteriza porque los paquetes o flujos de datos son leídos desde una fuente de datos a un búfer cíclico en el maestro, estando provisto cada byte leído de una dirección unívoca (para mayor facilitad, simplemente un contador de 32 bits, comenzando por 0), y porque el maestro, en un proceso independiente de la lectura del flujo de datos al búfer cíclico, envía los datos del búfer cíclico a la red por bloques, en particular inmediatamente después de su lectura, por difusión amplia, especialmente por difusión amplia UDP y, además, especialmente por multidifusión, habiendo sido complementados con un encabezado de protocolo que contiene, entre otras cosas, la dirección del primer byte transmitido, la hora exacta del maestro, la dirección del siguiente byte que será transmitido por el maestro al codificador/descodificador del maestro. Generalmente, los datos pueden ser transmitidos de distintas maneras por el maestro a los esclavos. La manera más sencilla es la llamada unidifusión, es decir, el maestro envía los datos, por separado, a cada esclavo. Sin embargo, en caso de existir varios, esto conduce a una carga innecesaria de la red. Por consiguiente, preferentemente, la distribución debería realizase de forma optimizada, de modo que el maestro transmita los datos, por multidifusión, a todos los demás equipos de reproducción. De esta manera, el ancho de banda necesario permanece constante independientemente del número de esclavos (para el ajuste de tiempo se añaden sólo posibles paquetes de sincronización adicionales, que prácticamente no ocupan nada del ancho de banda). El puntero de salida o su posición en el maestro se transmite a los esclavos como dirección del siguiente byte que será transmitido por el maestro al codificador/descodificador del maestro. Se parte de que el maestro y el esclavo disponen de arquitecturas similares, en las que el intervalo de tiempo entre la excitación del codificador/descodificador y la salida efectiva por la salida de audio (altavoz) son prácticamente idénticos. Si no es el caso han de considerarse correcciones correspondientes (necesarias, por ejemplo, en el caso de retrasos de amplificación importantes en uno de los equipos de salida etc.). Como ya se ha mencionado, la posición del puntero de salida en el maestro puede transmitirse simplemente como encabezado con los paquetes de datos en sí. Alternativamente o adicionalmente, sin embargo, también es posible transmitir la dirección del siguiente byte que será transmitido por el maestro al codificador/descodificador del maestro, al menos en parte en bloques de control independientes, que pueden ser idénticos a los bloques de control para la verificación del reloj en el maestro. Para ello, también es necesario especialmente implicar el tiempo de retardo del paquete con la ayuda del tiempo de retardo medio o del tiempo de retardo transmitido por el servidor, y dado el caso, corregir el contador correspondientemente.

Como ya se ha mencionado anteriormente, la integridad de los datos es de gran importancia en relación con la presente invención. Está claro que si se aspira a una transmisión a ser posible exenta de pérdida, los procedimientos unidireccionales (como, por ejemplo, la transmisión analógica o digital sin canal de retorno/acuse de recibo como la mencionada multidifusión/difusión amplia) no son suficientes, teniendo que elegir un procedimiento de comunicación bidireccional con almacenamiento intermedio de datos, para que en caso de una pérdida temporal de datos pueda solicitarse una repetición y realizarse una nueva transmisión, antes de que se vacíen los búfer locales con los datos ya transmitidos. De manera correspondiente, preferentemente se prevé un mecanismo de corrección o "protocolo de reintento", a través del cual puedan corregirse paquetes de datos perdidos o dañados en los esclavos. Correspondientemente, para asegurar la integridad de datos en caso de una pérdida de una parte de los datos en la red, detectada por un esclavo, dicha parte de datos es reenviada por el maestro tras el requerimiento del esclavo. Esto no se efectúa inmediatamente después de la consulta, sino que el maestro realiza este reenvío sólo después de un retraso. Típicamente, este retraso es de unos ms. La razón de ello es que, habitualmente, en una red, una transmisión defectuosa afecta al mismo tiempo a varios esclavos a la vez. Correspondientemente, serán varios los esclavos que dirigirán un requerimiento al maestro. Ahora, los esclavos se programan de tal forma que emitan los requerimientos de manera escalonada (pudiendo corresponder a un esquema de tiempo programado o a diferencias de tiempo aleatorias entre las consultas). Si ahora el maestro espera con la transmisión de los datos corregidos hasta que todos los esclavos en los que se detectó una entrada defectuosa hayan emitido su requerimiento, se puede evitar el envío múltiple de requerimientos idénticos por la red.

Además, preferentemente, se procede de tal manera que un esclavo sólo emite un requerimiento de reintento, mientras no haya observado un número determinado (al menos uno) de requerimientos iguales procedentes de otros equipos de reproducción o esclavos en la red. Esto corresponde a una repetición (realizada simplemente por varios equipos) y garantiza una mayor seguridad de datos. Además, preferentemente, el esclavo sólo emitirá requerimientos de reintento de este tipo, si o mientras esté seguro de que el paquete de datos solicitado pueda ser transmitido a tiempo por el maestro y ser reproducido, a continuación, por el esclavo. Cuando esta condición ya no se cumple, el esclavo tiene que volver a conectarse de nuevo al flujo de datos, ya que su búfer se vacía antes de que los datos necesarios puedan ser facilitados por el maestro. Si sin tener en cuenta esta condición se siguen emitiendo cada vez más requerimientos de reintento, resulta una carga innecesaria en la red.

Alternativamente y especialmente en el caso de faltar cortos sectores de datos, en una situación de este tipo, es decir, si el esclavo detecta que su reserva de datos es insuficiente para una reproducción continua, es posible no interrumpir y volver a conectar a la corriente de datos, sino suprimir la reproducción brevemente en aquel intervalo de tiempo en el que no estén disponibles los datos (laguna en el búfer).

Una vez transcurrido el tiempo de espera, el maestro vuelve a enviar el paquete de datos corregido, por difusión amplia o multidifusión, y todos los esclavos que necesiten dicho paquete podrán incorporarlo a su tampón cíclico. Además, los esclavos deberían escuchar en la red si los requerimientos de corrección iguales a los que están a punto de emitir ya han sido recibidos por el maestro. Si es el caso, el esclavo se abstiene de realizar la consulta, ya que el paquete de corrección correspondiente es facilitado de todas formas por el maestro en multidifusión.

Otra mejora de la coordinación y, en particular, del control entre el maestro y los equipos de reproducción o esclavos se puede conseguir de tal forma que en los flujos o paquetes de datos se transmita a los equipos de reproducción al menos un comando junto con un momento de ejecución correspondiente.

Por ejemplo, se pueden pasar comandos tales como pausa, reproducir, stop, etc. Preferentemente, el momento de ejecución ha de elegirse de tal forma que entre el paso del comando a la red y el momento de ejecución pueda transcurrir al menos el tiempo de retraso de red más largo detectado en la red, entre el maestro y el equipo de reproducción. De este modo, puede garantizarse que al llegar el comando al equipo de reproducción correspondiente, el momento de ejecución aún no haya pasado.

Este tiempo máximo de retraso de red puede ser determinado, por ejemplo, de vez en cuando por el maestro y, a continuación, ser depositado. Típicamente, a dicho tiempo máximo de retraso de red puede añadirse también un importe adicional, por ejemplo, del orden de 1 - 20 ms. Esta contribución máxima sirve para cubrir la tolerancia de transferencia de red (margen de seguridad) y el tiempo de procesamiento en el emisor y el receptor. Este tiempo máximo de retraso de red debería adaptarse dinámicamente, porque este tiempo máximo de retraso de red puede cambiar fuertemente a causa de cambios en la red. Por ejemplo, este tiempo característico cambia al incrementarse la carga en la red (típicamente, incremento del tiempo máximo de retraso de red), o cuando se conectan o desconectan equipos de reproducción adicionales u otros equipos.

Para evitar la determinación de la velocidad binaria a la que el maestro facilita los flujos o paquetes de datos en la red y que necesita el equipo de reproducción para calcular los retrasos producidos en la red, esta velocidad binaria puede transmitirse directamente en los flujos o paquetes de datos del maestro.

Preferentemente, cuando un nuevo equipo de reproducción ha de conectarse a un stream que ya está siendo ejecutado (por ejemplo, al conectar un nuevo equipo o cuando una pérdida de datos ha provocado un vaciado irreparable del búfer, a pesar de un requerimiento de reintento), se procede de tal forma que un equipo de reproducción conectado remite los flujos o paquetes de datos, recibidos desde la red, inmediatamente, es decir desde el primer byte recibido, a su codificador/descodificador. El codificador/descodificador del equipo de reproducción, en un primer momento, desecha los datos entrados, suprimiéndolos hasta que se detecte una primera trama válida. A continuación, el codificador/descodificador se detiene anotando el byte actual (que no tiene que ser necesariamente el primer byte de la trama en cuestión). De forma instantánea, al reproducirse este byte actual en el maestro, se vuelve a conectar el codificador/descodificador en el equipo de reproducción, y procesa el flujo de datos o los paquetes de datos reproduciéndolos. Cuando se para el stream hacia el codificador/descodificador tras alcanzar la primera trama válida y, a continuación, al mismo tiempo debe iniciarse la reproducción al mismo tiempo con el maestro (streaming), se debe tener en cuenta que el búfer en el codificador/descodificador del equipo de reproducción (esclavo) no está lleno en ese momento, es decir, por ejemplo semivacío. Esto significa que, al principio, los archivos se envían mucho más rápidamente al codificador/descodificador, porque éste quiere también que su búfer esté siempre lo más lleno posible. Por consiguiente, la reproducción (streaming) tiene que comenzar algo más tarde, porque entonces el esclavo vuelve a alcanzar el maestro por el llenado más rápido.

Al esperar la primera trama válida en el codificador/descodificador se puede evitar que el procesador generalmente más lento en el equipo de reproducción tenga que realizar un parsing del stream, es decir del flujo de datos o de los paquetes de datos, es decir, analizarlo y descomponerlo, y el codificador/descodificador se usa par la conexión al stream. Cuando el maestro comienza un nuevo stream, un procedimiento de este tipo normalmente no es nece-
sario.

El procedimiento propuesto permite también el funcionamiento de estructuras de árbol. Una sincronización en cascada de este tipo puede lograrse de tal forma que al menos uno de los equipos de reproducción se emplee a su vez como maestro para una subred (por ejemplo, LAN). Entonces, preferentemente se transmiten repeticiones correspondientes al maestro superior (maestro root). Así es posible sincronizar cualquier número de equipos de reproducción, y cada uno de los equipos de reproducción puede usarse, a su vez, como repetidor (equipo de reproducción activo a la vez como esclavo y como maestro). De esta manera, generalmente también es posible hacer que un esclavo de este tipo, activo como maestro, emita a otra red. Para el maestro root resultan a continuación evidentemente unos tiempos máximos de retraso distintos, que tendrán que tenerse en cuenta. De este modo, se puede realizar una replicación muy eficiente y, dado el caso, amplia del flujo de datos.

Al menos uno de los equipos de reproducción puede disponer, de manera ventajosa, de una memoria que proporcione datos de audio. En dicha memoria puede tratarse, por ejemplo, de una unidad (CD, DVD o similar) en la que se proporcione un medio grabado correspondientemente. Alternativamente, la memoria puede ser una memoria interna grabable o una memoria de sólo lectura. Dicha memoria se usa como fuente de datos de audio. El contenido de estos datos de audio puede ser adquirido eventualmente por el maestro o por otra fuente de datos (es posible también un sintonizador para la recepción de entradas de radio).

Otras formas de realización preferibles del procedimiento según la invención se describen en las reivindicaciones subordinadas.

Asimismo, la presente invención se refiere a un programa de procesamiento de datos para realizar un procedimiento tal como se ha descrito anteriormente, así como a un equipo de reproducción para realizar un procedimiento de este tipo. El aparato reproductor dispone preferentemente de una interfaz de red (o más generalmente, una interfaz de comunicación), de una unidad de cálculo central con memoria, así como de medios para la salida al menos indirecta de datos analógicos o digitales, en especial en forma de un altavoz. En la memoria de un equipo de reproducción de este tipo está programado fijamente un programa de procesamiento de datos para realizar dicho procedimiento, y este programa se activa automáticamente después de conectarse la alimentación, disponiendo el equipo de reproducción de forma especialmente preferible de medios para la integración automática del equipo en la red.

Otras formas de realización preferibles se describen en las reivindicaciones subordinadas.

Breve descripción de las figuras

A continuación, la invención se describirá detalladamente con la ayuda de ejemplos de realización en relación con los dibujos. Muestran:

La figura 1 una representación esquemática de un sistema con equipos de reproducción sincronizados; y

la figura 2 a) una representación esquemática del búfer cíclico en un esclavo y b) una representación esquemática del búfer cíclico en un maestro.

Maneras de realizar la invención

Como ejemplo de realización relativo a la presente invención se va a describir un sistema en el que un flujo de datos continuo suministrado por una fuente de datos de audio (digitales o analógicos) es distribuido de forma inalámbrica por una "unidad emisora" a varios equipos de reproducción distribuidos (típicamente, altavoces activos), los cuales descodifican y emiten diferentes canales del mismo flujo de datos. Para ello, la unidad emisora dispone de una CPU, es decir, de un procesador, una memoria intermedia, así como al menos una interfaz de comunicación bidireccional, en el ejemplo descrito una interfaz de red de radiotransmisión 802.11b, así como de una entrada de audio para datos de audio analógicas o digitales, así como de una salida de audio propia (por lo que es también un equipo de reproducción). Los otros equipos de reproducción usan la misma arquitectura, pero en lugar de una entrada de audio poseen una salida de audio digital y/o analógica y, eventualmente, un amplificador de potencia y convertidor de sonido/altavoz.

En la siguiente descripción se usan términos que se definen a continuación:

\bullet

El servidor es una fuente de datos para datos de audio y puede ser cualquier equipo para proporcionar los datos. Se trata, por ejemplo, de un servidor de un proveedor de contenido, o bien, de un simple servidor de músico o de vídeo. En especial, también se considerará como "servidor" un simple circuito de entrada digital (por ejemplo, S/PDIF), una conversión analógico/digital y/o un codificador/descodificador que comprime/codifica un flujo de datos (típicamente, un procesador de señales).

\bullet

Equipo de reproducción: Un equipo para reproducir el flujo de datos, que soporte los protocolos descritos aquí.

\bullet

Maestro: Un equipo de reproducción que ha recibido de otro equipo un requerimiento de transmitir el flujo de datos que se está reproduciendo.

\bullet

Sistema: Un número de al menos dos equipos de reproducción instalados en una misma estructura de comunicación común.

\bullet

Esclavo: Un miembro que por interfaz de usuario, por comando o por un ajuste o parámetro fijo ha sido invitado a reproducir de forma síncrona a otro equipo de reproducción ("maestro").

\bullet

Varios esclavos pueden reproducir de forma síncrona el mismo flujo de datos. Por lo tanto, para su señalización, los esclavos son provistos de números.

Funcionamiento sin sincronización

Todos los equipos de reproducción trabajan de forma autónoma. Los equipos de reproducción pueden emitir todos, independientemente entre sí, datos multimedia de una fuente de datos común o de fuentes de datos diferentes. Los fuentes de datos pueden estar dispuestos en la red, o bien, se puede tratar de datos almacenados ya en los equipos de reproducción.

Detección y búsqueda automáticas de miembros

Cada equipo de reproducción contiene un "discovery server" que al llegar un determinado bloque de la red (datagrama UDP en un número de puerto específico, UDP es un protocolo 'host-to-host' estándar, low-overhead, sin conexión, que permite el intercambio de paquetes de datos a través de redes informáticas conectadas. Permite a un programa en un ordenador enviar un datagrama a un programa en otro ordenador) reacciona con un bloque de respuesta. Alternativamente, pueden utilizarse otros protocolos discovery, por ejemplo, SSDP (Simple Service Discovery Protocol, un subprotocolo de UPNP, universal plug and play es un estándar que se usa para permitir una conexión directa y automática de equipos periféricos en una red local sin configuración).

Con la ayuda del protocolo de búsqueda, cada equipo de reproducción adquiere una lista de otros aparatos reproductores, sus nombres configurados, si están disponibles, y sus direcciones de red (dirección IP). Esta búsqueda se repite una y otra vez, de modo que la lista se completa automáticamente con nuevos equipos que se añaden. Los equipos que ya no existan se eliminan de la lista al cabo de cierto tiempo.

Un software organizado, por ejemplo, en forma de una homepage, permite a continuación visualizar todos los equipos de reproducción existentes en una red, mediante una consulta a un equipo de reproducción específico dentro de una red. Para ello no es preciso ningún tipo de instalación, ya que el software visualiza automáticamente todos los miembros ofreciendo la posibilidad de conectar distintos miembros a otros de una manera sincronizada (por ejemplo, mediante una activación vía comando cgi). Así se garantiza un manejo sencillo.

Requerimiento de sincronización

Un miembro puede ser estimulado, por diversas influencias, a sincronizarse con otro aparato y reproducir el flujo multimedia de éste:

1.

Mediante una configuración fija ("setup"). Un miembro de este tipo intenta sincronizarse constantemente con el maestro configurado.

2.

Mediante el comando procedente de una aplicación (por ejemplo, por comando cgi, véase arriba)

3.

Mediante la recepción de un comando por UDP - también es posible el caso sincronizar "TODOS" al miembro xxxx

4.

Mediante la acción del usuario y la activación vía interfaz del usuario.

Al ser estimulado un miembro a sincronizarse a otro, pasa lo siguiente:

Sincronización de hora

Los equipos esclavo tienen que estar sincronizados muy exactamente con el maestro. Para este fin, se requiere una sincronización exacta de una base de tiempo común. No es necesario que esta "hora del sistema de maestro y esclavo" tenga referencia alguna a otros sistemas como, por ejemplo, la hora global, y tampoco tiene mayor importancia la exactitud (velocidad de avance) de dicha hora - mientras los dos equipos estén lo más sincronizados posible.

La sincronización de hora de los equipos de reproducción tiene que repetirse periódicamente para corregir diferencias producidas con el paso del tiempo. La ejecución de una sincronización de hora se realiza de forma similar a un protocolo conocido por el ámbito de la adaptación de hora, a saber ntp (network time protocol). Se trata de un protocolo para la sincronización de los relojes en los ordenadores de una red.

En el presente caso, se procede de la siguiente manera:

La fórmula empleada es la consulta del tiempo al servidor teniendo en cuenta el tiempo de retardo medio de los datos. El equipo mismo toma su hora actual y mide la duración hasta la respuesta del servidor. Dicha respuesta contiene la hora actual del servidor en el momento de la llegada de la consulta. Realizando este proceso repetidamente, pueden compensarse ligeras variaciones en los tiempos de ejecución de datos:

a)

El esclavo manda un datagrama UDP al miembro al que desea sincronizarse y consulta la hora actual de éste. En el telegrama se acompaña la hora "propia" (hora de emisión)

b)

El telegrama es provisto por el receptor con la hora local (del maestro), manteniéndose la hora de emisión del "esclavo", y se reenvía al esclavo.

c)

El esclavo recibe el telegrama reenviado por el maestro y lo registra en una tabla anotando la hora de recepción.

d)

Los pasos a-c se repiten varias veces (durante la primera sincronización, por ejemplo, al menos 8 veces, durante la resincronización, 3 veces), con el objetivo de obtener, mediante la formación de promedios omitiendo valores extremos, un resultado lo más exacto posible.

e)

Cuando existan suficientes datos representativos en la tabla, se evalúan. Para ello, se forma la diferencia (la hora actual del esclavo menos la hora de emisión del esclavo) de cada telegrama y se comprueba si la transmisión del telegrama tardaba mucho (gran diferencia). Únicamente los telegramas con la menor diferencia se aceptan y, en el caso normal, se puede suponer que en equipos iguales, la hora de transmisión corresponde aproximadamente de forma simétrica a los dos enlaces de transmisión. De esta manera, es posible sincronizar al maestro con gran exactitud una "hora de maestro" en el esclavo, independiente de la hora normal del esclavo.

En la Ethernet normal e incluso en redes inalámbricas 802.11, los tiempos de transmisión en estado sin carga son típicamente inferiores a 1 ms, pero en cualquier caso inferiores a 5 ms, y suponiendo el retraso "simétrico", con el procedimiento descrito se puede garantizar una sincronización de hora de los miembros a claramente menos
de 1 ms.

Por consiguiente, se determina un tiempo de retardo medio de los datos dentro del intervalo de tiempo más corto posible. Deduciendo una constante estimada o empírica de 0,01 - 1 ms para los diferentes tiempos de procesamiento durante la emisión y la recepción de los datos dentro de los equipos, se obtiene un tiempo de retardo momentáneo para un paquete de datos. Dicho tiempo de retardo se tiene en consideración al determinar la hora actual del sistema.

La sincronización de hora se repite entonces en intervalos periódicos, típicamente cada 30 segundos, siendo suficiente para la vigilancia, generalmente, un sello de hora en el protocolo de transmisión, por lo que la resincronización se activa sólo en caso de discrepancias notables.

Sincronización de datos

Generalidades: Para realizar la sincronización de "n" esclavos a un maestro sin "n" veces el volumen de datos en la red, en el sentido de la necesidad del menor ancho de banda posible en la red resulta ventajoso distribuir los datos de streaming del maestro por multidifusión/difusión amplia. La difusión amplia/multidifusión no es "segura", es decir que los datos pueden perderse. Por tanto, se requiere un mecanismo de repetición. El requerimiento de repeticiones puede realizarse de forma unidireccional - con direccionamiento directo.

Para establecer de manera sencilla y automática varios grupos de sincronización (canales) independientes, para la distribución de datos por cada canal debería usarse un número de puerto distinto. De esta manera, se asegura con una alta probabilidad que en la implementación descrita, cada miembro deduzca un número de puerto individual de su dirección IP y de una constante. Se suman los últimos 12 bits de la dirección IP más una constante (por ejemplo, 40.000). Un número de puerto de este tipo es garantizadamente unívoca en una red típica con un direccionamiento de clase C.

El número de puerto individual de cada miembro se transmite en el caso del protocolo "Discovery", por lo que cada miembro reconoce el "número de canal" de cada maestro potencial.

Solicitud: Una vez establecida la sincronización de hora (véase anteriormente), el esclavo invita al equipo de reproducción, cuyo flujo de datos desea reproducir de forma sincronizada, a adoptar el papel de "maestro". Esto se hace enviando un comando (SYNC-REQ) al puerto/canal UDP específico (del maestro). Un acuse de recibo del maestro confirma la recepción del comando; si no hay confirmación, el esclavo repite el comando, si es preciso, repetidas veces.

Streaming: El maestro recibe los datos de streaming, por ejemplo, de un servidor, típicamente por enlace tcp, eventualmente por http, o bien, de una interfaz local digital o analógica, de un codificador/descodificador o similar. El funcionamiento del sistema es completamente independiente de la fuente de datos empleada. Todos los datos entrantes se graban en un búfer cíclico. Durante cada "inicio" de un stream se repone un contador de bytes (32 bits) Cada byte entrante es contado por el servidor y, por tanto, tiene una "dirección" unívoca.

En un proceso independiente de la recepción del flujo tcp, el maestro envía los datos del búfer cíclico por bloques, inmediatamente tras su llegada, por difusión amplia UDP, a la red, complementados con un encabezado de protocolo que contiene, entre otras, la "dirección" del primer byte transmitido, la hora exacta del maestro, la dirección del siguiente byte que ha de ser transmitido por el maestro al codificador/descodificador. Esto está representado en la figura 2b). El búfer cíclico 5 está constantemente lleno de datos. El puntero de salida 6 se encuentra en un lugar determinado donde envía los datos leídos allí al codificador/descodificador/convertidor local, para su reproducción. El puntero de salida 6 se desplaza conforme al reloj interno del maestro hacia delante (véase la dirección de la flecha). El puntero de entrada de datos 8 indica aquella posición en la que los datos recibidos por un servidor están siendo leídos al búfer cíclico 5. Sustancialmente directamente "detrás" en el sentido de lectura, se encuentra el puntero de transmisión de datos 10 que indica la posición en la que los datos existentes en el búfer cíclico 5 son transmitidos por el maestro a los esclavos por multidifusión/difusión amplia. Por la referencia 12 está designado un paquete típico de datos. En el búfer cíclico 5 se encuentra una "reserva de datos" 9, cuya parte esencial está disponible para "protocolos de reintento" que puedan ser necesarios (véase más adelante). Típicamente, esta reserva de datos comprende aprox. 1 a 4 segundos de datos. Ya no está disponible para protocolos de corrección la zona de seguridad situada inmediatamente antes del puntero de salida 6, porque ésta ya no puede transmitirse de forma adecuada.

El esclavo recibe estos datagramas y registra a su vez los datos recibidos en un búfer intermedio 5. El encabezado del protocolo es evaluado directamente, a saber, se verifica la exactitud de la hora del maestro y la información "hora de maestro/byte actual" (corresponde al momento de reproducción actual) se almacena de forma intermedia o se usa para desplazar el puntero de salida 6 al lugar adecuado o adaptar su característica de ejecución. El búfer cíclico 5 del esclavo está representado en la figura 2a). El puntero de entrada de datos 7 se encuentra en la posición del puntero de transmisión de datos 10 del maestro (evidentemente considerando el tiempo de retardo a través de la red) y, en el caso ideal, el puntero de salida de datos 6 se encuentra en un lugar idéntico en el maestro.

Típicamente, para evitar pérdidas de datos o para permitir un "arrastre" en caso de necesidad, el búfer cíclico en los esclavos debería ser mayor que los del maestro. De paso, cabe mencionar que la posición del byte actual que está siendo enviado por el maestro al codificador/descodificador, también puede ser determinada indirectamente a través del estado del búfer cíclico. Si los búfer cíclicos del maestro y del esclavo están igual de llenos, la sincronización está bien. Si el búfer cíclico de un esclavo está menos lleno que él del maestro, esto indica un desplazamiento correspondiente de la salida.

Protocolo de reintento (mecanismo de corrección)

El esclavo puede detectar fácilmente, si se ha perdido un paquete de datos. Este es el caso precisamente cuando se recibe un nuevo paquete de datos, cuyo primer byte no tenga ninguna dirección consecutiva (laguna de datos).

Al perderse un paquete de datos, esto ocurre típicamente en la red y, generalmente, para varios o todos los esclavos en el "canal". Para evitar una carga innecesaria de la red, se emplea un procedimiento inteligente de reintento. Todos los esclavos reciben el "nuevo" paquete de datos aproximadamente en el mismo momento y, por tanto, pueden detectar aproximadamente al mismo tiempo que se han perdido datos. Ahora, cada cliente se retrasa en un tiempo individual (aleatorio o derivado por algoritmo de la dirección IP o MAC), por ejemplo en un intervalo de 1 a 30 ms, antes de emitir un "requerimiento de reintento". Dicho requerimiento de reintento se envía entonces por difusión amplia al puerto UDP específico para el "canal", pudiendo ser recibido de esta manera por todos los miembros conectados al canal - no sólo por el maestro. Mientras los clientes que deseen desencadenar un reintento esperan el tiempo individual, continúa la recepción de datagramas UDP. Un reintento desencadenado por otro cliente finaliza la espera y evita la emisión del reintento propio, si se trata del mismo requerimiento (la misma dirección de byte inexistente) o de un requerimiento de más datos - de este modo, se evitan eficazmente repetidos requerimientos idénticos de reintento, minimizando la carga en la red.

\newpage

Cuando un esclavo detecta que la pérdida de datos de todas formas ya no puede ser compensada por el maestro con una nueva emisión en el marco del tiempo disponible, finaliza sus requerimientos de reintento. Así, se puede evitar que se sigan emitiendo requerimientos de reintento innecesario que lo único que hacen es cargar la red sin traer ninguna ventaja al esclavo. A continuación, un esclavo o bien puede reproducir hasta el último byte disponible y volver a conectar al flujo de datos, o bien, y esto puede resultar conveniente especialmente en caso de cortos sectores con pérdida de datos, interrumpe la reproducción dentro de la ventana, cuyos datos no estén disponibles.

Por parte del maestro, cuando entra un reintento, se espera un tiempo determinado (por ejemplo, 30 ms, igual al retraso máximo del caliente más el tiempo de procesamiento interno máximo para bloques de datos entrantes), antes de comenzar la repetición del envío. Con este retraso se puede evitar que se inicie un reintento a partir de un punto determinado y que a continuación entre un requerimiento de reintento a partir de un punto anterior.

Básicamente, todos los datos se repiten a partir del punto requerido hasta el final del búfer de streaming del maes-
tro.

Los esclavos ignoran todos los datos entrantes que ya "conozcan", pero no de forma específica según bloques, sino de forma específica según bytes - un bloque de reintento puede contener en parte datos antiguos y en parte datos nuevos.

Reconexión

Puede ocurrir que por una perturbación masiva de recepción un esclavo no haya recibido datos durante un tiempo prolongado y, por tanto, produzca un "underrun", es decir que se vacía el búfer de streaming. En este caso, ya no se requieren reintentos, sino que el esclavo vuelve a sincronizarse completamente de nuevo según el procedimiento descrito. En este caso, la salida del flujo multimedia en el esclavo tiene que interrumpirse durante un corto
período.

Conexión a un flujo de datos en curso

Los esclavos pueden conectarse en cualquier momento a un flujo de datos en curso, no siendo necesario un inicio síncrono. Esto se realiza mediante el siguiente método:

1)

El esclavo llena el búfer de streaming con los datos transmitidos al canal

2)

El esclavo sigue las direcciones de los bytes emitidos actualmente, transmitidas por el maestro adicionalmente en las difusiones amplias

3)

Adicionalmente, mediante consultas específicas, el esclavo puede saber exactamente de parte del maestro, qué byte (dirección) acaba de emitir éste al codificador/descodificador.

4)

La dirección del primer byte inscrito en el búfer de streaming se compara con la dirección de salida actual, transmitida por el maestro. Si son iguales o si el maestro ha emitido ya más datos, se inicia inmediatamente la reproducción.

Ajuste fino

Mediante la consulta periódica al maestro (de forma análoga a la sincronización de hora, implementada en los mismos bloques de datos que la sincronización de hora), puede detectarse si el cliente está "atrasado" o "avanzado" con respecto al maestro, a saber, simplemente mediante la formación de la diferencia de las direcciones de byte emitidas actualmente al codificador/descodificador. Evidentemente, se tiene que sacar un promedio de estos datos a lo largo del tiempo.

Si el cliente en el búfer de streaming ya está más avanzado que el maestro, el codificador/descodificador puede frenarse algo mediante una ligera ralentización de la frecuencia de reloj hasta que se alcance la sincronización exacta. De manera análoga, la frecuencia de reloj del codificador/descodificador se incrementa ligeramente, cuando el cliente está atrasado en promedio frente al maestro.

Finalización del modo de maestro

El maestro puede comprobar la necesidad de la emisión de datos - es decir, el papel de maestro - por la existencia de la actividad de esclavos, al menos para la sincronización de la hora. Si durante un período prolongado (al menos 3 x intervalo de consulta sincronización de hora) ya no registra ninguna actividad de cliente, el maestro puede volver al modo de miembro normal y finalizar la emisión de las difusiones amplias.

\newpage

Lista de referencias

1

Equipo de reproducción (maestro)

2

Equipo de reproducción (esclavo)

3

Servidor de datos

4

Red

5

Búfer cíclico para datos

6

Puntero de salida de datos (esclavo/maestro)

7

Puntero de entrada de datos (esclavo)

8

Puntero de entrada de datos (maestro

9

Reserva de datos

10

Puntero de transmisión de datos (maestro)

11

Zona de seguridad

12

Paquete de datos para esclavos.

Claims (25)

1. Procedimiento para la reproducción de flujos o paquetes de datos transmitidos a través de al menos una red (4), mediante al menos dos equipos de reproducción (1, 2) conectados al menos indirectamente a la red (4), caracterizado porque para la sincronización de la reproducción con los al menos dos equipos de reproducción (1, 2), uno de los equipos de reproducción que sirve de maestro (1) define su reloj interno como referencia y los otros equipos de reproducción (2) que sirven de esclavos ajustan su reloj interno, a través de la red (4), al del maestro (1), o bien llevan una copia del reloj de maestro, efectuando la reproducción de flujos o paquetes de datos en función de dicho reloj ajustado o de la copia del reloj de maestro.

2. Procedimiento según la reivindicación 1, caracterizado porque en la red (4) se trata de una red (4) en la que se transmiten de forma asíncrona o síncrona paquetes de datos.

3. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque el ajuste del reloj en el esclavo (2) se produce antes de la primera reproducción, y de forma especialmente preferible, periódicamente durante la reproducción.

4. Procedimiento según la reivindicación 3, caracterizado porque la actualización periódica se usa para realizar en el esclavo (2) una adaptación sistemática de la velocidad de avance del reloj interno del esclavo (2) al del maestro (1) para compensar diferencias en la característica del tiempo de retardo interno del maestro (1) y el esclavo (2).

5. Procedimiento según la reivindicación 4, caracterizado porque la adaptación sistemática consiste en escalar el reloj interno del esclavo (2) con un factor de corrección constante.

6. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque el ajuste del reloj interno se realiza de tal forma que el reloj interno del maestro (1) es consultado por el esclavo (2), preferentemente varias veces, y al menos uno, preferentemente una pluralidad de paquetes de datos que pueden ser idénticos a paquetes para consultar el tiempo en el maestro (1), se transmiten del esclavo (2) al maestro (1) y de vuelta, y el reloj interno en el esclavo (2) se adapta al reloj en el maestro (1), en función especialmente de un tiempo de retardo medio de paquetes de datos entre el maestro (1) y el esclavo (2).

7. Procedimiento según la reivindicación 6, caracterizado porque el tiempo de retardo se calcula como valor medio teniendo en cuenta los tiempos de procesamiento en los equipos (2).

8. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque el primer equipo de reproducción (1, 2) encargado de la reproducción se define automáticamente como maestro (1).

9. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque en los flujos de datos o paquetes de datos se trata de datos de audio o de vídeo digitales o de una combinación de ellos, especialmente de ficheros de audio comprimidos o no comprimidos tales como MP3, WAV, MPEG, Windows Media, etc.

10. Procedimiento según la reivindicación 9, caracterizado porque en los equipos de reproducción (1, 2) o bien se reproducen los mismos datos, o bien, diferentes canales de los datos, especialmente en el caso de ficheros de audio en formato estéreo o multicanales, se reproducen en diferentes equipos de reproducción (1, 2).

11. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque al menos una parte de los flujos o paquetes de datos se almacena de forma intermedia (5) antes de la reproducción en los equipos de reproducción (1, 2), situándose el almacenamiento intermedio de los ficheros de audio típicamente en un intervalo de aprox. 1 a 5 seg., y el almacenamiento intermedio, de forma especialmente preferible, es dinámico y se adapta a las circunstancias de la red.

12. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque la sincronización de los distintos equipos de reproducción (1, 2) se realiza en un orden inferior a 100 ms, preferentemente, inferior a 10 ms o inferior a 2 ms, de forma especialmente preferible, inferior a 1 ms.

13. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque en la red (4) se trata de una red inalámbrica, especialmente de una red de radiotransmisión.

14. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque durante la reproducción de al menos un equipo de reproducción (1, 2) se conecta de manera sincronizada al menos un equipo de reproducción adicional, de tal forma que el equipo (2) conectado adicionalmente se ajusta automáticamente al maestro (1) existente iniciando él mismo la reproducción tras el almacenamiento intermedio de una parte de los datos.

15. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque los paquetes o flujos de datos o bien se recogen de un servidor de datos (3) separado, o bien, se recogen en uno de los equipos de reproducción (1), o bien, ya están disponibles en los equipos de reproducción (1, 2), o bien, se facilitan al sistema en forma digital a través de un convertidor analógico-digital y/o, dado el caso, una unidad de compresión/codificación, tras su alimentación en forma analógica o digital.

16. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque los paquetes o flujos de datos son leídos desde una fuente de datos a un búfer cíclico (5) en el maestro (1), estando provisto cada byte leído de una dirección unívoca, y porque el maestro (1), en un proceso independiente de la lectura del flujo de datos al búfer cíclico (5), envía los datos del búfer cíclico (5) a la red, por bloques, en particular inmediatamente después de su lectura y por difusión amplia, especialmente por difusión UDP y, además, especialmente por multidifusión, habiendo sido complementados con un encabezado de protocolo que contiene, entre otras cosas, la dirección del primer byte transmitido, la hora exacta del maestro, la dirección del siguiente byte que será transmitido por el maestro (1) al codificador/descodificador del maestro (1).

17. Procedimiento según la reivindicación 16, caracterizado porque la dirección del siguiente byte que será transmitido por el maestro al codificador/descodificador del maestro (1) se transmite al menos en parte en bloques de control independientes, que pueden ser idénticos a los bloques de control para la verificación del reloj en el maestro.

18. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque para asegurar la integridad de datos en caso de una pérdida de una parte de datos en la red (4), detectada por un esclavo (2), dicha parte de datos es reenviada por el maestro (1) tras el requerimiento del esclavo (2), no realizando el maestro (1) dicho reenvío hasta después de un retraso, especialmente del orden de unos ms, y realizando los esclavos (2) los requerimientos de forma escalonada, de manera que los requerimientos idénticos sean enviados sólo una vez por la red.

19. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque en los flujos o paquetes de datos se transmite a los equipos de reproducción (1, 2) al menos un comando, por ejemplo uno del grupo pausa, reproducir, stop, junto con un momento de ejecución correspondiente, eligiéndose el momento de ejecución preferentemente de tal forma que entre el paso del comando a la red (4) y el momento de ejecución pueda transcurrir al menos el tiempo de retraso de red más largo detectado en la red (4) entre el maestro (1) y el equipo de reproducción (1, 2).

20. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque en los flujos de datos o paquetes de datos se transmite la velocidad binaria del maestro (1), a la que el maestro (1) facilita los flujos de datos o paquetes de datos en la red (4), utilizando el equipo de reproducción (1, 2) dicha velocidad binaria preferentemente para determinar los retrasos producidos en la red.

21. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque un equipo de reproducción (1, 2) conectado remite los flujos o paquetes de datos, recibidos desde la red, inmediatamente al codificador/descodificador, que desecha los datos emitidos, silenciándolos, hasta que el codificador/descodificador detecte una primera trama válida, a continuación de lo cual el codificador/descodificador se detiene anotando el byte actual, y entonces el codificador/descodificador en el equipo de reproducción vuelve a procesar el flujo de datos o los paquetes de datos, siendo conmutado a reproducción, cuando en el maestro (1) se esté reproduciendo este byte actual.

22. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque al menos uno de los equipos de reproducción (1, 2) se emplea a su vez como maestro para una subred, transmitiéndose, preferentemente, repeticiones correspondientes al maestro superior.

23. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque al menos uno de los equipos de reproducción (1, 2) dispone de una memoria que se usa como fuente de datos de audio, obteniéndose el contenido de dichos datos de audio eventualmente de parte del maestro (1) o de otra fuente de datos.

24. Programa de procesamiento de datos para realizar un procedimiento según una de las reivindicaciones 1 a 23.

25. Equipo de reproducción para realizar un procedimiento según una de las reivindicaciones 1 a 23, caracterizado porque dispone de una interfaz de red, de una unidad de cálculo central con memoria, así como de medios para la salida al menos indirecta de datos, en especial en forma de un altavoz, caracterizado porque en la memoria está programado fijamente un programa de procesamiento de datos según la reivindicación 24, y porque este programa se activa automáticamente después de conectarse la alimentación, disponiendo el equipo de reproducción de forma especialmente preferible de medios para la integración automática del equipo en la red.