Resumo

  • Uma lista MIDI vazia pode acompanhar informações importantes de recuperação. Durante uma pausa, um novo pacote ajuda a revelar a perda de um comando anterior e a corrigir o instrumento.
  • A recuperação busca eliminar erros que persistem no estado de reprodução, não tocar novamente cada nota perdida. Um ataque atrasado pode ser corretamente descartado.
  • O alcance do histórico, a entrada de novos receptores, os limites de congestionamento e os algoritmos locais impedem que um diário seja confundido com uma gravação completa da apresentação.

O silêncio não esvazia a responsabilidade

O músico para de tocar. Durante alguns segundos, não há novos comandos para enviar. Parece natural que o equipamento também pare de transmitir. Mas e se o último pacote, aquele que deveria encerrar uma nota, não tiver chegado?

O RFC 4696, publicado em novembro de 2006, apresenta justamente esse problema. Em seu exemplo, um NoteOff se perde e a próxima ação do músico só acontece cinco segundos depois. Sem um pacote intermediário, o receptor pode demorar até essa ação para descobrir o salto na sequência. A pausa de um lado pode virar uma nota indevidamente prolongada do outro.

O documento discute pacotes de guarda com listas MIDI vazias. Eles não inventam gestos para o intérprete. Transportam uma nova observação da sequência e podem levar o diário necessário à correção. A ausência de comandos novos não significa ausência de informação útil.

É uma situação hipotética usada pelo guia de implementação, não o relato de uma apresentação real. Ainda assim, concentra uma questão importante da Internet: uma aplicação pode continuar sofrendo os efeitos de uma perda quando a rede já não tem tráfego suficiente para torná-la visível.

Um comando pequeno pode durar muito

MIDI não transporta, nesse caso, pedaços de uma gravação sonora. Transporta instruções simbólicas que um sintetizador ou programa interpreta: começar uma nota, encerrá-la, mudar um controle. O som depende também do estado acumulado no instrumento receptor.

Por isso, dois pacotes perdidos não precisam produzir danos parecidos. O RFC 4695, de novembro de 2006, separou os artefatos transitórios dos indefinidos. Perder um NoteOn pode deixar uma nota ausente por sua duração prevista. Perder um NoteOff pode permitir que ela continue. Perder uma alteração do volume de canal pode fazer todas as notas seguintes soarem fortes ou fracas demais.

O resultado depende do instrumento, da envoltória sonora, do pedal e de comandos posteriores. Não se deve afirmar que toda perda de NoteOff cria inevitavelmente um som infinito. O problema é não haver, no comando recebido anteriormente, informação suficiente para garantir o término correto.

A recuperação precisava, portanto, distinguir uma lacuna que passa de um erro que fica. Contar bytes recebidos não oferece essa distinção. O efeito de uma ordem sobre o futuro pode ser muito maior que seu tamanho no pacote.

A sequência detecta o buraco, não decide a música

O RTP fornece números de sequência, marcas de tempo e monitoramento de recepção. Mas o RFC 3550, de julho de 2003, deixa claro que o protocolo não garante entrega, pontualidade nem chegada ordenada. Seus campos oferecem meios para lidar com essas condições, não fazem com que deixem de existir.

Além disso, um salto numérico não diz qual estado musical ficou errado. A aplicação precisa saber o significado do que foi perdido. O formato RTP MIDI coloca essa informação em um diário de recuperação associado aos pacotes de um fluxo que usa esse mecanismo.

Quando recebe o pacote que encerra um episódio de perda, o receptor compara o diário com seu próprio conhecimento da sequência de comandos. Pode então emitir instruções locais para corrigir o estado. Não é necessário retransmitir todos os pacotes antigos para que uma nota deixe de ficar presa.

O RFC 6295, que substituiu o texto de 2006 em junho de 2011, preserva a obrigação central: a execução musical produzida a partir de um fluxo enviado por transporte não confiável não deve conter artefatos indefinidos. Isso não promete uma apresentação sem qualquer falha. Promete uma forma de impedir que uma falha continue mandando no instrumento.

Recuperar não é reencenar

Se a ordem ausente era um ataque, tocá-lo depois pode ser pior que deixá-lo faltar. A música depende do momento. Uma informação historicamente correta pode se transformar em uma ação presente inadequada.

O capítulo N do diário trata dos padrões comuns de alternância entre NoteOn e NoteOff para uma mesma nota. Seu registro de NoteOn não contém o instante exato da execução original. Um bit Y recomenda tocar ou pular a nota; não exige a reprodução de todo ataque mencionado no histórico.

O receptor descrito no guia de 2006 usa esse indício e a condição de atraso para decidir. Pode deixar de produzir o som e atualizar seus registros de recuperação como se a ordem tivesse sido considerada. Isso mantém coerência para os comandos seguintes, sem acrescentar um ataque fora de hora.

Há padrões que essa explicação simplificada não cobre. Inícios sobrepostos da mesma nota exigem apoio adicional do capítulo E. Um modelo adequado a teclados e pads não descreve automaticamente todos os controladores de guitarra ou de sopro. Também pode faltar informação sobre a ordem relativa de NoteOff e pedal de sustentação. Quando não consegue deduzi-la de seu próprio histórico, o receptor deve evitar deixar uma sustentação errada, mesmo que a decisão cause uma perturbação breve.

Essa limitação não é um detalhe embaraçoso a esconder. É parte da diferença entre informação suficiente para reparar e informação suficiente para reproduzir tudo exatamente.

Até onde o diário se lembra

Cada diário tem um ponto de controle. Se o pacote atual é I e o ponto é C, o histórico cobre os comandos de C até I−1, excluindo os novos comandos do próprio I. Se os dois números coincidem, esse histórico é vazio.

A possibilidade de recuperar uma quantidade arbitrária de pacotes perdidos vale dentro do intervalo coberto. Não equivale a recuperar qualquer interrupção, por mais longa que seja. O receptor precisa verificar se o diário alcança o início da perda observada.

A política de envio padrão é de ciclo fechado. Os receptores informam seu progresso, normalmente por meio do maior número de sequência estendido registrado em relatórios RTCP. Um mecanismo alternativo acordado também pode fornecer o retorno. Com esses dados, o transmissor reduz a parte do passado que precisa carregar repetidamente.

O RFC 8088, guia de desenho de formatos RTP publicado em maio de 2017, chamou atenção para esse estado resumido e para a redução do diário com ajuda do RTCP. O interesse está em meios simbólicos fortemente dependentes de estado. Não é uma conclusão sobre participação de mercado ou qualidade de apresentações comerciais.

Reduzir o passado exige cuidado com quem chega depois. Um volume de canal configurado no começo pode não estar mais no histórico recente. O novo receptor recebe os próximos pacotes sem conhecer o valor antigo. Quando o transmissor descobre sua presença, deve evitar que a sessão comece com esse tipo de erro persistente. Conectividade atual não substitui inicialização correta.

A pausa precisa caber no orçamento da rede

Os pacotes de guarda ajudam durante períodos sem comandos, mas não são gratuitos. O guia apresenta exemplos com intervalos que se ampliam à medida que a pausa continua. Esses números são sugestões de implementação, não uma frequência universal imposta pelo protocolo.

Na especificação de 2011, guardtime permite indicar a separação máxima entre dois pacotes consecutivos em unidades do relógio RTP. A faixa descrita como típica não é um limite normativo. E o controle de congestionamento tem precedência: se a frequência solicitada entrar em conflito com suas exigências, o transmissor deve dar prioridade a elas.

O RFC 3551 explicita a responsabilidade de compartilhar a capacidade da rede de modo razoável. O desejo de corrigir uma nota rapidamente não dá à aplicação direito a enviar indefinidamente mais tráfego. Uma escolha feita para reduzir um erro local pode ampliar perdas e atrasos se ignorar os outros fluxos.

Tampouco todo fluxo RTP MIDI precisa usar diário. Por padrão, transportes não confiáveis, como UDP, o utilizam; transportes confiáveis, como TCP, não. A descrição da sessão pode alterar certas escolhas, desde que não viole as obrigações de recuperação. O método de uso do diário é fixado no início e não pode simplesmente mudar no meio da sessão. O exemplo de uma rede local conhecida como confiável não autoriza presumir que qualquer rede local terá essa propriedade.

O pacote antigo nem sempre melhora o presente

Uma correção pode ter sido executada antes da chegada de um pacote fora de ordem. Executar então os comandos antigos pode repetir uma ação ou comprometer o estado já corrigido. O receptor NMP descrito no guia ignora esses pacotes.

Mas RFC 4696 é um texto informativo, não uma especificação normativa de um único algoritmo. Seu exemplo usa um subconjunto de comandos e condições de rede particulares. Não possui buffer de reprodução; o próprio documento reconhece que isso não satisfaz inteiramente uma diretriz de interoperabilidade que exige essa capacidade.

A exigência geral é não criar artefatos indefinidos ao tratar a desordem. Um receptor com buffer pode aguardar o instante de reprodução antes de reparar, pois o pacote supostamente perdido talvez só esteja atrasado e ainda possa ser usado. Também deve tratar o primeiro pacote como o fim de uma perda e sair da sessão sem deixar erros que continuem indefinidamente.

O padrão estabelece o resultado mínimo e o significado das informações. O algoritmo continua sendo uma escolha de implementação, sujeita a esses limites. Confundir o exemplo com a regra eliminaria justamente a adaptação que a arquitetura admite.

Um registro comum, uma promessa limitada

O registro audio/rtp-midi da IANA reúne nome, parâmetros e referências para o transporte de MIDI em tempo real. A publicação de 2006 e a atualização de 2011 aparecem ali como história da especificação, não como certificado de desempenho de um instrumento.

A revisão de 2011 corrigiu figuras, sintaxe e exemplos de configuração. As observações dos autores sobre problemas de interoperabilidade conhecidos se limitam às correções tratadas; não provam a perfeição de toda implementação. Os comentários sobre a maturidade de certos usos naquela época também não podem ser apresentados como um retrato do mercado atual.

O pacote sem notas resume bem essa história. Ele pode fazer um trabalho essencial sem acrescentar uma nota à apresentação: ajudar o receptor a encerrar uma decisão que já deveria ter terminado. Recuperação, nesse caso, é impedir que o passado continue errado, não obrigar o presente a tocar tudo o que perdeu.