Audio Digital - Barramento TDM
AUDIO DIGITAL - Publicado na M&T - nº 193
Outubro/2007
Parte 1: TDM
Por Vinicius Brazil
Já a um certo tempo, graças ao sucesso absoluto do sistema Protools nos estúdios, houve-se muito a terminologia “barramento ou bus TDM”. Porém, na prática o que é isto?
Voltemos no tempo em várias dezenas de anos...
Nas grandes indústrias e nos sistemas de segurança, o sistema de controle centralizado (donde provém a sigla CPU, ou Central Processing Unit ou ainda unidade de processamento central) tinha que “varrer” (scan, ou seja, lêr valores sequencialmente), numa taxa fixa, vários processos remotos. Quando a quantidade de processos remotos crescia muito, tornava-se financeiramente inviável a chamada ligação em estrela, ou seja, cabeamentos individuais de comunicação entre a central e os periféricos (assim chamados por inicialmente não estarem contidos na central físicamente, e sim na “periferia”, têrmo que evoluiu para tudo que não seja realizado diretamente por uma CPU) – ver figura 1. Nestes casos, que eram a grande maioria, optou-se pela chamada ligação em série, ou seja, um cabo sai da central e vai ao primeiro equipamento, deste para o segundo, e assim por diante. Neste ponto, vários dos leitores já devem ter lembrado da MIDI.
Outubro/2007
Parte 1: TDM
Por Vinicius Brazil
Já a um certo tempo, graças ao sucesso absoluto do sistema Protools nos estúdios, houve-se muito a terminologia “barramento ou bus TDM”. Porém, na prática o que é isto?
Voltemos no tempo em várias dezenas de anos...
Nas grandes indústrias e nos sistemas de segurança, o sistema de controle centralizado (donde provém a sigla CPU, ou Central Processing Unit ou ainda unidade de processamento central) tinha que “varrer” (scan, ou seja, lêr valores sequencialmente), numa taxa fixa, vários processos remotos. Quando a quantidade de processos remotos crescia muito, tornava-se financeiramente inviável a chamada ligação em estrela, ou seja, cabeamentos individuais de comunicação entre a central e os periféricos (assim chamados por inicialmente não estarem contidos na central físicamente, e sim na “periferia”, têrmo que evoluiu para tudo que não seja realizado diretamente por uma CPU) – ver figura 1. Nestes casos, que eram a grande maioria, optou-se pela chamada ligação em série, ou seja, um cabo sai da central e vai ao primeiro equipamento, deste para o segundo, e assim por diante. Neste ponto, vários dos leitores já devem ter lembrado da MIDI.
Quando do último equipamento existe um ligação à central, chama-se ligação em anel. Ver figura 2.
Porém, se olharmos para o cabo de interligação entre cada nó da rede, nos sistemas de 40 anos atrás, os dados eram paralelos, ou seja, 8 fios para os bits de dados e mais alguns para controle ou comando. O sistema tinha a distribuição serial, mas o bus ou barramento era paralelo. Porque isto? Naquela época os sistemas comerciais não tinham desempenho para uma comunicação realmente serial, ou seja, pelo menos todos os dados no mesmo fio.
Alguns anos se passaram e isto ficou viável financeiramente, e surgiram vários protocolos de comunicação serial, à um, dois, tres e quatro fios. Na década de 80 nasce comercialmente a MIDI, um protocolo serial simplex à um fio. Nesta nomenclatura o retorno ou ground de sistema não é contado, e é chamado simplex pela razão da comunicação transitar em apenas um sentido, logo, quando a comunicação se dá físicamente nos dois sentidos chama-se Duplex. Poderiamos dar como exemplo a linha telefônica como uma “comunicação” Duplex à um fio. Estes conceitos (Simplex/Duplex) tem outras nuances que não nos interessam no presente contexto, que envolvem meio físico e/ou tempo. No presente caso estou considerando apenas meio físico, o fio, desconsiderando simultaneidade temporal (transmissão nos dois sentidos, ao mesmo tempo).
Começamos a nos aproximar do assunto deste artigo: TDM
Vejamos o seguinte exemplo hipotético: Tomemos um processo com 4 fornos. A cada segundo o controle central tem que ler 4 termômetros e, caso haja desvio de alguma temperatura, fazer a devida correção nos sistemas de aquecimento, como mostrado na figura 3. A interligação é serial à um fio e todos os dados, comandos e endereços podem ser gerenciados em 8 bits (um byte). Um protocolo que se prestaria a este trabalho seria o RS-232.
Alguns anos se passaram e isto ficou viável financeiramente, e surgiram vários protocolos de comunicação serial, à um, dois, tres e quatro fios. Na década de 80 nasce comercialmente a MIDI, um protocolo serial simplex à um fio. Nesta nomenclatura o retorno ou ground de sistema não é contado, e é chamado simplex pela razão da comunicação transitar em apenas um sentido, logo, quando a comunicação se dá físicamente nos dois sentidos chama-se Duplex. Poderiamos dar como exemplo a linha telefônica como uma “comunicação” Duplex à um fio. Estes conceitos (Simplex/Duplex) tem outras nuances que não nos interessam no presente contexto, que envolvem meio físico e/ou tempo. No presente caso estou considerando apenas meio físico, o fio, desconsiderando simultaneidade temporal (transmissão nos dois sentidos, ao mesmo tempo).
Começamos a nos aproximar do assunto deste artigo: TDM
Vejamos o seguinte exemplo hipotético: Tomemos um processo com 4 fornos. A cada segundo o controle central tem que ler 4 termômetros e, caso haja desvio de alguma temperatura, fazer a devida correção nos sistemas de aquecimento, como mostrado na figura 3. A interligação é serial à um fio e todos os dados, comandos e endereços podem ser gerenciados em 8 bits (um byte). Um protocolo que se prestaria a este trabalho seria o RS-232.
Como seria o procedimento? À cada segundo, a Central varre os medidores de temperatura e faz as devidas correções de potência nos sistemas de aquecimento. Como a linha de comunicação é comum a todos os periféricos, cada um precisa ter um “endereço” (ID ou identidade) para quando a central enviar um comando o periférico específico saber que foi para ele.
Logo, no nosso exemplo, ficaria assim: a Central envia um comando com o endereço do Medidor de temperatura #0 (MedTemp#0) pedindo o valor medido. O medidor envia, pela mesma linha, o valor. Desta forma, se passa com o MedTemp#1, #2 e #3. A central envia para o Controle de Aquecimento #0 a devida correção. O mesmo faz para ContAq#1, #2 e #3. Repete-se o processo ad infinitum. Como o protocolo RS-232 é assíncrono, necessita, pelo menos de um bit de inicialização (Start Bit) e um de encerramento (Stop Bit), logo, cada palavra de comando ou de dados usa 10 bits na comunicação. O mapa de tempo do processo fica então como na figura 4. Poderiamos usar o mesmo exemplo (com algumas modificações) numa ligação MIDI entre um computador e quatro synth´s...
Como pode ser visto na figura 4 existem 16 blocos de 10 bits cada, sem considerar os espaços entre eles, necessários, para cada periférico identificar o comando e endereço como seus. Se não considerarmos estes espaços (em alguns sistemas de duração “considerável”), transitou pelo canal de comunicação 16 x 10 bits = 160 bits. Como a informação relevante são apenas 8 bytes, 4 de temperatura e 4 de correção, logo 8 x 8 bits = 64 bits, o sistema gastou mais da metade do tempo para endereçar/controlar o processo! Se não fosse isto, a CPU poderia gerenciar, a cada segundo, 10 fornos em vez de 4!
Chamariamos este canal de comunicação de um canal de baixo rendimento...
Uma forma de contornar este problema é usar mais fios para endereçamento e controle, o problema é que quanto mais cresce o numero de periféricos, mais fios são necessários para endereçamento, tornando o custo do cabeamento inviável, ou, pior, se um destes fios se romper, por qualquer razão, mais de um periférico pode ser acionado simultaneamente!
No nosso exemplo, 4 fornos representariam mais 3 fios para Endereçamento/comando e, 10 fornos mais 5 fios!
Logo, no nosso exemplo, ficaria assim: a Central envia um comando com o endereço do Medidor de temperatura #0 (MedTemp#0) pedindo o valor medido. O medidor envia, pela mesma linha, o valor. Desta forma, se passa com o MedTemp#1, #2 e #3. A central envia para o Controle de Aquecimento #0 a devida correção. O mesmo faz para ContAq#1, #2 e #3. Repete-se o processo ad infinitum. Como o protocolo RS-232 é assíncrono, necessita, pelo menos de um bit de inicialização (Start Bit) e um de encerramento (Stop Bit), logo, cada palavra de comando ou de dados usa 10 bits na comunicação. O mapa de tempo do processo fica então como na figura 4. Poderiamos usar o mesmo exemplo (com algumas modificações) numa ligação MIDI entre um computador e quatro synth´s...
Como pode ser visto na figura 4 existem 16 blocos de 10 bits cada, sem considerar os espaços entre eles, necessários, para cada periférico identificar o comando e endereço como seus. Se não considerarmos estes espaços (em alguns sistemas de duração “considerável”), transitou pelo canal de comunicação 16 x 10 bits = 160 bits. Como a informação relevante são apenas 8 bytes, 4 de temperatura e 4 de correção, logo 8 x 8 bits = 64 bits, o sistema gastou mais da metade do tempo para endereçar/controlar o processo! Se não fosse isto, a CPU poderia gerenciar, a cada segundo, 10 fornos em vez de 4!
Chamariamos este canal de comunicação de um canal de baixo rendimento...
Uma forma de contornar este problema é usar mais fios para endereçamento e controle, o problema é que quanto mais cresce o numero de periféricos, mais fios são necessários para endereçamento, tornando o custo do cabeamento inviável, ou, pior, se um destes fios se romper, por qualquer razão, mais de um periférico pode ser acionado simultaneamente!
No nosso exemplo, 4 fornos representariam mais 3 fios para Endereçamento/comando e, 10 fornos mais 5 fios!
Olhando para a figura 4 notamos que os eventos, a cada segundo, ocorrem sempre no mesmo ponto... Ora, então o ciclo de tempo fica divido em 8 subdivisões bem claras. Vamos chamar o conjunto de dados que transita a cada segundo de Pacote (Packet). Ao processo de dividir rigidamente o ciclo de tempo em 8 subdivisões de Multiplexação do tempo (Time Multiplexing) e cada subdivisão de Time Slot.
Bingo! TIME DIVISION MULTIPLEXING = TDM !
Simplificando a figura 4, temos a figura 5:
Bingo! TIME DIVISION MULTIPLEXING = TDM !
Simplificando a figura 4, temos a figura 5:
Neste momento, só nos faltaria resolver o “desperdício” de bits no endereçamento/comando. Como poderiamos fazer isto? De uma forma bem simples, ou seja, acrescentando mais dois fios, um para o Clock do sistema, tornando toda a comunicação síncrona e outro, chamado sinal de Sincronismo, para “informar” quando começa cada Pacote. Nos sistemas de áudio o System Clock é chamado de BITCLOCK, o sinal de SYNC é chamado de WORDCLOCK e o Tcycle de TAXA DE AMOSTRAGEM ou SAMPLE RATE (Fs).
Agora, na figura 6, está esquematizado o nosso sistema TDM.
Agora, na figura 6, está esquematizado o nosso sistema TDM.
No nosso exemplo hipotético no primeiro Slot de tempo o Medidor de Temperatura #0 envia um byte de temperatura para a Central. No Slot1 assim também o faz o MedTemp#1. Slot2 = Medtemp#2 e Slot3=MedTemp#3. No slot4 a Central envia a correção para o Controle de Aquecimento#0 que o lê. Slot5, 6 e 7 o mesmo se passa para ContAq#1, #2 e #3. Sem desperdícios de tempo e/ou bits. Vale a pena comentar que o valor de Tdsync (largura do pulso de sincronismo na figura 6) é irrelevante e que, nos processos de audio normalmente é de 50%, ou seja, metade de Tcycle.
Outra coisa importante nos sistemas TDM seriais (que é uma comunicação síncrona à 3 fios) reside no fato que a única coisa que amarra a quantidade de slots é o tamanho do dado do slot e o Bitclock!
Logo, em um sistema de distribuição digital de audio que quizessemos passar 32 canais de 32bits à 48kHz teriamos:
WORDCLOCK= Fsync = 48kHz
BITCLOCK = WORDCLOCK x Ncanais x Nbits = 48kHz x 32 canais x 32 bits = 49,152 MHz
Vamos agora ao Protools HD.
O barramento TDM possui 512 timeslots e cada dado 24 bits (nos processos de dupla precisão, 48 bits, são utilizados 2 timeslots). Se fizessemos a conta acima daria o asustador bitclock de 589,824 MHz! Como o Protools resolveu este problema? Com uma linha de sinal para cada bit da palavra, ou seja, 24 linhas em paralelo, fazendo jús, efetivamente ao têrmo bus ou barramento. Neste caso, o bitclock é de 48kHz x 512 timeslots = 24,576 MHz e cada clock determina a largura do timeslot.
Vale comentar que todas os exemplos apresentados com Fs=48kHz poderiam ser recalculados, da mesma forma para 44.1kHz, 88.2kHz, 96kHz, 176.4kHz ou 192kHz.
Conclusões:
- O processamento de áudio é um evento síncrono, basicamente amarrado a frequência de amostragem, nos exemplos 48kHz.
- Como evento síncrono as etapas tem ocorrência previsível no tempo.
- Na possibilidade de determinar absolutamente o momento no tempo (timeslot) em que ocorre uma etapa pode-se obter o maior rendimento de um dado canal para uma frequência de comunicação mais baixa.
Isto é TDM.
Outra coisa importante nos sistemas TDM seriais (que é uma comunicação síncrona à 3 fios) reside no fato que a única coisa que amarra a quantidade de slots é o tamanho do dado do slot e o Bitclock!
Logo, em um sistema de distribuição digital de audio que quizessemos passar 32 canais de 32bits à 48kHz teriamos:
WORDCLOCK= Fsync = 48kHz
BITCLOCK = WORDCLOCK x Ncanais x Nbits = 48kHz x 32 canais x 32 bits = 49,152 MHz
Vamos agora ao Protools HD.
O barramento TDM possui 512 timeslots e cada dado 24 bits (nos processos de dupla precisão, 48 bits, são utilizados 2 timeslots). Se fizessemos a conta acima daria o asustador bitclock de 589,824 MHz! Como o Protools resolveu este problema? Com uma linha de sinal para cada bit da palavra, ou seja, 24 linhas em paralelo, fazendo jús, efetivamente ao têrmo bus ou barramento. Neste caso, o bitclock é de 48kHz x 512 timeslots = 24,576 MHz e cada clock determina a largura do timeslot.
Vale comentar que todas os exemplos apresentados com Fs=48kHz poderiam ser recalculados, da mesma forma para 44.1kHz, 88.2kHz, 96kHz, 176.4kHz ou 192kHz.
Conclusões:
- O processamento de áudio é um evento síncrono, basicamente amarrado a frequência de amostragem, nos exemplos 48kHz.
- Como evento síncrono as etapas tem ocorrência previsível no tempo.
- Na possibilidade de determinar absolutamente o momento no tempo (timeslot) em que ocorre uma etapa pode-se obter o maior rendimento de um dado canal para uma frequência de comunicação mais baixa.
Isto é TDM.
