A.7 Instala¸c˜ ao Django
3.3 O m´ odulo de comuta¸c˜ ao de ´ audio
Problema a ser resolvido
O m´odulo de comuta¸c˜ao de ´audio foi desenvolvido com o objetivo de dar a possibilidade ao m´edico especialista do centro hologr´afico de se comunicar tanto de modo “p´ublico” quanto
“privado”. O modo “p´ublico” refere-se ao cen´ario onde tanto o paciente quanto o m´edico no consult´orio remoto compartilhem a mensagem, portanto a voz do m´edico especialista
´e direcionada ao alto-falante instalado no consult´orio remoto. O modo “privado”, ´e repre- sentado pelo cen´ario no qual apenas o m´edico no consult´orio remoto receba a mensagem,
uma vez equipado com um fone de ouvido bluetooth.
Metodologia para solu¸c˜ao
Uma vez definido o problema, foi realizado um estudo para e encontrar uma solu¸c˜ao
Figura 3.7: Modo p´ublico vs Modo privado
solu¸c˜ao, al´em de realizar essa comuta¸c˜ao de ´audio entre os componentes f´ısicos (hardware) compreendidos pelo sistema, tamb´em deveria ser facilmente integrada ao nosso Web App.
Um primeiro passo, foi entender a metodologia utilizada pelo sistema operacional para reproduzir um arquivo de ´audio em um hardware do sistema. Uma vez que o projeto
de Telessa´ude tem como objetivo ser um projeto de baixo custo, as op¸c˜oes de software aberto/livre s˜ao amplamente incentivadas pelo mesmo e, assim, a solu¸c˜ao foi desenvolvida
em torno do sistema operacional Gnu/Linux. A partir disso, a arquiteura de ´audio desse sistema foi brevemente estudada.
Arquitetura de ´audio Linux
Para come¸car a entender o que ´e necess´ario para que um arquivo de ´audio seja reproduzido pelo sistema operacional, aplicamos o conceito de Framework para este caso. Para que
cada aplica¸c˜ao seja capaz de reproduzir o ´audio em um componente de hardware a partir de um arquivo, s˜ao necess´arias muitas linhas de c´odigo. Assim, para n˜ao haver a necessi-
dade de cada aplica¸c˜ao implementar tal funcionalidade, o sistema operacional possui uma estrutura previamente definida para ser compartilhada entre todos as aplica¸c˜oes. A essa
estrutura ´e dado o nome de Framework de ´audio.
O Framework de ´audio do Linux, n˜ao se apresenta bem estruturado em camadas
como se estivessemos estudando as camadas do modelo OSI em redes de computadores. Na verdade, h´a uma maior semelhan¸ca com um modelo da crosta terrestre, onde camadas
mais inferiores podem emergir para a superficie. Por exemplo, ferramentas de camadas mais baixas, que est˜ao em contato direto com o hardware, podem conter APIs (application
22
Figura 3.8: Ausˆencia de Framework de ´audio
programming interface) para estabelcer comunica¸c˜ao diretamente com aplica¸c˜oes [23].
Com o passar dos anos, muitas aplica¸c˜oes optaram por dar preferˆencia a certas ferramentas, e a arquitetura de ´audio do Linux foi reduzindo em complexidade e se tor-
nando cada vez mais homogˆenea. No estado atual [22], pode-se simplificar tal arquitetura conforme o mostrado na Figura 3.9 a seguir:
Figura 3.9: Arquitetura de ´audio Linux
Al´em do Framework utilizado, para estabelecer a comunica¸c˜ao entre hardware e software ´e necess´ario um n´ıvel intermedi´ario. Bem conhecido da literatura, esse n´ıvel
intermedi´ario ´e chamado de driver.
O ALSA ´e o lugar no Kernel do Linux (n´ucleo do sistema operacional) onde prati- camente todos os drivers de ´audio est˜ao embutidos. Como ilustrado na Figura 3.9, apesar
de estar em contato diretamente com o hardware, o ALSA tamb´em possui software e API (application programming interface) para comunica¸c˜ao com aplica¸c˜oes em n´ıveis superi-
ores.
O PulseAudio ´e o servidor de audio que dar´a suporte a maioria das aplica¸c˜oes1
utilizadas pelo sistema operacional. Portanto, se comunica diretamente com os drivers de ´audio do ALSA e realiza todas as opera¸c˜oes necess´arias ao sistema operacional, como,
por exemplo: Mixar sa´ıdas de ´audio de diferentes aplica¸c˜oes para serem reproduzidas ao mesmo tempo, converter taxas de amostragem, etc.
Algoritmo - Script Shell
Entendendo como a arquitetura de ´audio funciona, foi poss´ıvel implementar em um al- goritmo para resolver o problema de comuta¸c˜ao de ´audio proposto. Uma vez que nossa
solu¸c˜ao se baseia no sistema operacional Gnu/Linux, a linguagem de implementa¸c˜ao es- colhida para o dito algortimo foi o shell script Para descrever o funcionamento desse
algoritmo, ´e necess´ario a defini¸c˜ao de alguns elementos envolvidos no processo:
ALSA sound cards (sinks) – Cada dispositvo f´ısico, respons´avel por reproduzir
o ´audio em um computador, ´e identificado pelo ALSA como uma interface de ´audio (sound card ) distinta. Portanto, podemos entender tais dispisitivos como sa´ıdas de nosso sistema,
ou tamb´em chamados de sinks.
Sink-input – Para o Pulseaudio, nosso servidor de som (sound server ), cada apli-
ca¸c˜ao que est´a reproduzindo algum ´audio ´e identificada como uma entrada, ou tamb´em chamadas de sink-input.
No caso desse projeto, temos como sa´ıdas a interface de ´audio PCI padr˜ao do sistema e a interface de ´audio de um dispositivo Bluetooth. A aplica¸c˜ao Gstreamer, far´a
a fun¸c˜ao da entrada descrita.
De forma geral, nosso algoritmo deve executar as seguintes etapas:
X Identificar a entrada correspondente ao aplicativo alvo que se deseja comutar o canal
1O JACK n˜ao ser´a abordado nesse trabalho. Geralmente, ´e utilizado para aplica¸c˜oes de ´audio profis- sionais que necessitam de baixa latˆencia.
24
de ´audio (Gstreamer);
X Identificar qual a sa´ıda correspondente a interface de ´audio PCI (modo p´ublico); X Identificar qual a sa´ıda correspondente a interface de ´audio Bluetoooth (modo pri-
vado);
X Comutar a entrada alvo entre as sa´ıdas previamente identificadas, de acordo com a requisi¸c˜ao do usu´ario;
A Figura 3.10 abaixo, ilustra a l´ogica de opera¸c˜ao de nosso algoritmo. O mesmo pode ser entendio como um Multiplexador 2x1, o qual ir´a comutar uma entrada de ´audio
entre duas sa´ıdas distintas.
Figura 3.10: Diagrama de funcionamento do algoritmo
Para a explica¸c˜ao acima, com o intuito de maior clareza, abstraimos a linguagem de
programa¸c˜ao e alguns problemas pr´aticos enfrentados, assim, a complexidade do algoritmo foi reduzida. Uma explica¸c˜ao detalhada do funcionamento do c´odigo ´e apresentada no
Apˆendice E.