Explorando a latência no projeto de um sistema de performance musical em rede para improvisação coletiva percussiva

Músicos ligados por um canal de áudio bidirecional toleram cerca de 75 ms de latência, mas pela Internet o atraso e o jitter crescem com a distância e ficam muito acima disso. A maioria dos sistemas de performance musical em rede (NMP) ou escolhe estilos que não dependem de tempo preciso ou tenta esconder o atraso. Um truque conhecido para música cíclica, que o artigo chama de abordagem do "tempo falso" e que o NINJAM usa, vai no sentido contrário: impõe um andamento, sincroniza os relógios, estima a latência de ponta a ponta no pior caso (WCL) e agenda cada evento para tocar pelo menos WCL depois, arredondado para um ciclo musical inteiro. Todo mundo ouve uma peça coerente, só que deslocada no tempo.

Este artigo do NIME 2025, de Ari Liloia e Roger Dannenberg, da Carnegie Mellon University, constrói uma jam de percussão sobre essa ideia e vai além. A latência não é só compensada, ela vira parte da música e da imagem na tela: a distância entre os músicos numa grade compartilhada, medida em tempos musicais, sai dos seus tempos de ida e volta. O sistema nasceu do Global Drum Circle (2022), dos mesmos autores, e o código está no GitHub (arililoia-cmu/elbs_nime). Para quem quer manter um metrônomo sincronizado entre músicos remotos, a parte útil é o desenho do tempo: um relógio mestre no servidor, uma linha de tempo em batidas compartilhada por todos os clientes e atrasos que são sempre múltiplos inteiros de um tempo musical.

• Três papéis numa grade. Compositores (vermelho), Intérpretes (azul) e Ouvintes (verde) são nós numa grade bidimensional. Apertar uma tecla toca na hora uma amostra de conga localmente e envia uma "batida" ao servidor. Um Compositor desenha conexões até Intérpretes; seus marcadores de batida viajam por elas, e o tempo de viagem em tempos musicais (o tempo de procissão) é igual ao comprimento da conexão em linhas da grade. Os Intérpretes tocam conforme os marcadores chegam, como numa partitura que rola, e suas batidas se espalham como uma frente de onda em forma de losango que alcança cada Ouvinte depois de tantos tempos quanto a distância na grade. Um Ouvinte arrasta seu nó para ouvir outra combinação de tempos de todos os Intérpretes.
• Latência como distância musical. O servidor estima o tempo de ida e volta de cada cliente e posiciona os nós com um layout de molas, de modo que a latência entre usuários vira um atraso medido em tempos musicais, numa "escala de tempo musical nova".
• Um atraso oculto alinhado ao tempo musical. Além do tempo de procissão, cada ação chega aos outros clientes depois de um atraso H de pelo menos WCL que é um número inteiro de tempos, o que mantém coerente a saída sobreposta mesmo quando vários clientes tocam na mesma sala.
• Predição no cliente, emprestada dos jogos. As próprias batidas do usuário são mostradas e ouvidas imediatamente, e as ações que exigem resposta são atrasadas em 2H para quem observa, de modo que a reação de um Intérprete parece instantânea em todos os clientes.
• Registros para compor depois. A perspectiva de cada Ouvinte é salva como um arquivo MIDI, com uma trilha por Intérprete, pensado para ser aberto numa DAW. O primeiro autor compôs uma peça a partir de uma das sessões de teste.

O artigo é um relato de projeto e implementação seguido de um teste informal.

Stack e topologia. O back end é Java com Maven, construído sobre o servidor WebSocket e HTTP Webbit. O front end usa p5.js para desenhar e a Web Audio API para tocar o som. As mensagens trafegam por WebSockets usando O2lite, a versão leve do protocolo O2 de Dannenberg. A topologia é hub-and-spoke: toda mensagem passa por um servidor central, que mantém o relógio mestre, guarda o estado do conjunto, registra a performance e rejeita ações inválidas. Para rodar uma sessão, um usuário compila a aplicação numa máquina virtual com IP público e distribui o link do cliente no navegador.

Relógio e tempos. Um andamento é imposto e mapeia tempo para batidas. Durante a configuração, cada cliente sincroniza seu relógio local e seu "timemap" (o mapeamento de tempo para batidas) com o servidor. O artigo não detalha o algoritmo de sincronização em si; ele se apoia no O2lite. O tempo de ida e volta é estimado de forma "grosseira" com N mensagens O2lite, a primeira espaçada de S ms e cada intervalo crescendo por um fator F. Os valores padrão N = 10, S = 20 e F = 2 levam cerca de 20 segundos.

Latência no pior caso. O WCL é configurável e tem padrão de 3500 ms. Os autores o justificam pelo painel de desempenho do Google Cloud, cujo maior tempo de ida e volta mediano entre uma região da nuvem e um ponto externo era 350 ms, então o padrão fica uma ordem de grandeza acima, por segurança.

Agendando uma batida. Uma batida enviada no tempo b_S toca no receptor no tempo b_S + C, em que C tempos duram pelo menos WCL. O atraso oculto é H = xB, com B a duração de um tempo e x um inteiro (padrão 4). Com H de pelo menos 3,5 s distribuído em 4 tempos, o andamento fica limitado a cerca de 68 BPM. O artigo imprime a fórmula como 60 * x / (H * 1000) e depois calcula 60 * 4 / 3,5 = 68,57; o número está certo quando H está em segundos. A Figura 4 do artigo mostra a linha do tempo: tocada em t_T, recebida em t_R, exibida em t_V com t_V menos t_T de pelo menos WCL, e chegando ao nó de destino em t_E depois do tempo de procissão.

Posicionamento na grade. No servidor, os clientes são massas ligadas por molas cujos comprimentos de repouso são proporcionais à soma dos seus RTTs. Depois de M = 1000 iterações, as posições são quantizadas numa grade G por G com G = 16, de modo que um marcador que atravessa a grade em linha reta leva quatro compassos. G também limita uma sessão a G * G usuários.

Controle da sessão. Os usuários fazem login e escolhem um papel. Quando há pelo menos um cliente validado de cada classe, eles votam para começar; um cliente novo ou que cai reinicia a votação. Todo cliente mostra um indicador de andamento, um indicador de iniciado/parado, um mixer de volume e luzes que piscam com o metrônomo. Só Compositores podem iniciar a execução ou mudar o andamento. Batidas, mudanças de andamento, movimentos de Ouvintes e conexões novas são seguidos por períodos de espera maiores que WCL, para que cada mudança tenha tempo de chegar a todo o conjunto. Uma desconexão cobre a grade com uma janela de interrupção. Depois da sessão, o servidor converte seus logs em CSV e em um arquivo MIDI por Ouvinte, baixado por HTTP POST.

Teste. Uma sessão com três participantes distribuídos que deram consentimento informado: uma chamada de vídeo com apresentação, depois três rodadas (jogo livre, troca de papéis e uma rodada em que algumas pessoas operaram dois clientes em duas abas do navegador).

Estes são os resultados qualitativos relatados pelos autores. Não há medições de latência nem de sincronização.

• Nos testes com usuários distribuídos, "não surgiu nenhum problema sugerindo que um WCL maior fosse necessário", então 3,5 s bastaram na prática.
• A estimativa grosseira de RTT "gerou um conjunto razoável de valores" para posicionar os nós, e todas as configurações realistas de nós e RTTs testadas durante o desenvolvimento convergiram em até 1000 iterações do layout.
• Os arquivos MIDI das três rodadas abriram sem problemas "em várias DAWs". Os logs e os arquivos MIDI estão publicados em extras/logs no repositório.
• O retorno da sessão levou a duas mudanças já incorporadas ao protótipo: o próprio nó de cada cliente ficou mais fácil de identificar na grade, e as instruções de configuração ficaram mais claras.
• A configuração média levou um pouco mais que os cerca de 20 segundos da sondagem de RTT.
• Uma peça completa (extras/composition.wav) foi composta a partir do MIDI da terceira sessão, com timbre de marimba e camadas atmosféricas. Dois Ouvintes a distâncias diferentes do mesmo Intérprete produziram um efeito de "pergunta e resposta", que é a ideia de latência como distância ouvida na prática.

A avaliação é informal, e os próprios autores dizem isso no resumo, na seção de testes e na conclusão. Uma sessão com três pessoas sustenta "funciona e as pessoas conseguiram usar", não afirmações sobre usabilidade, qualidade musical ou precisão de tempo.

• Sem dados de tempo. O artigo nunca mede a diferença entre relógios, o jitter, o atraso real de ponta a ponta nem quantas vezes um evento perdeu o tempo agendado. O WCL de 3,5 s é uma constante generosa, e "nenhum problema" em algumas rodadas não mostra que ele se sustenta em redes piores ou em conexões móveis.
• O mecanismo de sincronização é delegado. O relógio e o timemap do cliente são sincronizados com o servidor pelo O2lite, mas o artigo não dá algoritmo nem precisão. Quem está construindo um metrônomo compartilhado aprende a arquitetura (relógio mestre no servidor, mapa de andamento compartilhado, eventos agendados em tempos futuros, atrasos alinhados ao tempo musical, períodos de espera nas mudanças de estado), mas precisa consultar o O2 para a sincronização de relógio em si.
• O preço do truque é andamento e responsividade. Um atraso grande alinhado aos tempos limita o andamento a cerca de 68 BPM com a configuração padrão, e toda mudança, inclusive de andamento, espera um período maior que 3,5 s. Isso serve para uma jam percussiva lenta e cíclica e exclui pergunta e resposta apertadas em andamentos normais.
• Estimativa de latência grosseira. O RTT é medido uma vez, na configuração, com dez sondas, e os autores chamam o método de "grosseiro e pouco rigoroso". Condições que mudam durante a sessão não movem os nós.
• Servidor central. O hub-and-spoke simplifica o registro, o relógio mestre e o tratamento de conflitos, mas toda mensagem paga a viagem por uma única VM, e o servidor é um ponto único de falha.
• Detalhes menores. A fórmula do andamento máximo é impressa com unidades misturadas, e a terceira rodada de testes diz que "dois usuários" operaram dois clientes cada, mas descreve três pessoas.

Os autores sugerem:

• Estimar com mais precisão a latência entre usuários, talvez com um algoritmo adaptativo ou com mais medições espalhadas por um período mais longo.
• Uma partitura rolante mais legível para os Intérpretes do que a grade, com base no retorno dos usuários.
• Mais recursos de edição depois da sessão, ou recursos de performance modestos, como enviar amostras de tambor próprias, o que também ajudaria a distinguir as partes de cada um, já que hoje todos compartilham os mesmos dois sons de conga.

Do lado de sistemas, os próximos passos naturais seriam medir o erro real de sincronização e o atraso de entrega em diferentes condições de rede, e adaptar WCL e H durante a sessão em vez de fixá-los na configuração.