Tecnologia sem fio está mais em pauta do que nunca com a migração para trabalho remoto e popularização dos Earbuds TWS (leia-se airpods e similares). No entanto, a tecnologia não avançou o suficiente na qualidade de áudio em geral mas, principalmente, na qualidade de comunicação.

Parafraseando um cliente que avaliou um fone bluetooth de uma marca famosa na Amazon:

Em vez de "plug and play" recebemos "buy and pray".

TL;DR

Esse é um resumo em tópicos, pule-o se não quiser spoilers e preferir ler minhas divagações por completo.

• Fiquei indignada com Headsets, Bluetooth e áudio horrível nas ligações
• O problema não é seu fone/computador/sistema operacional
• Não existe nenhum headset bluetooth puro sem essa limitação atualmente
• A solução pode estar a caminho com os novos dispositivos BT 5.2 com suporte ao codec LC3
• Headsets com software e hardware proprietário são uma opção, como Jabra
• Headsets que utilizam a tecnologia wireless 2.4ghz com receptor próprio são outra opção, como Corsair ou Razer
• Descobri que gosto de testar headsets

Por que o som dos headsets sem fio bluetooth é tão horrível durante ligações?

Além de dias sombrios, a pandemia trouxe outro problema: com o despreparo das empresas para o trabalho remoto e a comunicação assíncrona, começaram a surgir infinitas reuniões que resultam em horas e horas utilizando fones de ouvido e causando uma dor de cabeça imensa diariamente.

Isso me fez decidir deixar de lado meu velho amigo com fio e buscar alternativas que me dessem mais mobilidade e fossem mais leves para aguentar um dia inteiro de trabalho.

Com tantas pessoas na rua utilizando fones sem fio como acessorios tive a ilusão de que seria super simples.

Não foi.

Então vou tornar pública uma obsessão recente minha: por que, em 2021, ainda não é possível fazer uma chamada de vídeo com um fone sem fio sem parecer o áudio de um rádio dos anos 90?

Jornada

Essa publicação é uma forma de auto-ajuda =D. Comecei a ficar tão obcecada e impressionada com o assunto que, quando percebi, estava compilando uma implementação customizada de Bluetooth para configurar meu ambiente de desenvolvimento. Assim começou essa nota e por isso vou registrar aqui tudo que aprendi após descobrir que fones bluetooth são terríveis para chamadas.

No fim, desisti de resolver o problema definitivamente e decidi aguardar os próximos capítulos, mas descobri um novo hobby: avaliar a qualidade de headsets. Combina exatamente duas coisas que gosto muito - música (a parte teórica e física) e tecnologia. Quem sabe começo a escrever review de uns dispositivos por aí.

Comecei buscando, furiosamente, a origem do problema. Inicialmente achei que poderia ser algo específico com hardware, sistema operacional, versão do Bluetooth, etc. Tudo isso é relevante, mas nenhum deles era o problema real.

Problema

Tecnicamente, qual é o problema?

Quando conectei meus fones e comecei a testar notei que o áudio e os controles funcionavam perfeitamente ouvindo música mas, quando eu mudava para uma ligação, o áudio ficava horrível e o microfone também. Geralmente os controles também pioravam - funcionavam de forma limitada ou não respondiam.

Se você jogar imediatamente esse problema no Google bastante gente menciona que o problema é no Ubuntu/Linux (spoiler: não é).

Quando estamos ouvindo música (ou seja, audio sendo transmitido de forma unidirecional) o perfil Bluetooth utilizado é o A2DP, com qualidade quase HD. Já quando estamos em uma chamada (ou seja, audio sendo recebido e enviado, transmitido de forma bidirecional) o perfil Bluetooth utilizado é o HSP/HFP, com qualidade quase ridícula =D.

Esse é um problema antigo e uma implementação mais antiga ainda, de quando a qualidade de áudio por telefones já era uma coisa mágica, bem distante da realidade atual. Em síntese algumas limitações são responsáveis por esse problema:

• Só é possível utilizar um perfil de bluetooth ao mesmo tempo. Então precisamos escolher entre A2PD (áudio ótimo mas o microfone não funciona) ou HSP (áudio horrível, mas microfone funciona)
• Apesar do Bluetooth ter quase 80 canais de transmissão, apenas dois são dedicados para transmissão de áudio. Isso significa que dois são utilizados inteiramente para a transmissão de áudio de música, mas que eles são divididos entre microfone e fone quando estamos em uma chamada
• Utilizando os codecs padrão, enquanto o A2DP transmite 48 kHz, o HSP transmite 8~16kHz (isso significa que o áudio é, literalmente, três vezes pior)

Afinal, existe uma solução para esse problema? Sinceramente, mais ou menos. Vou explorar melhor no próximo tópico, mas a verdade é que não existe ainda uma solução definitiva, ainda que parece que ela está a caminho.

Solução

A triste verdade é que ainda não existe uma solução definitiva para o problema, mas algumas alternativas são possíveis e parece que a correção está a caminho.

#1 Semi Gambiarra: FastStream Codec e software proprietário

O objetivo do codec FastStream é habilitar comunicação bi-direcional utilizando o perfil A2P2 (ou seja, justamente resolver o problema) e parece que ele sucede relativamente bem nisso.

No entanto a solução é trabalhosa e cara: é necessário encontrar headsets específicos que suportem FastStream e adquirir um adaptador de bluetooth separado para o computador/notebook.

No Brasil existem pouquíssimos ou nenhum à venda, por isso não testei, mas gostaria; a implementação é bem curiosa e interessante.

Além disso existe a opção de software proprietário. Soluções oferecidas pela Jabra, por exemplo, trazem uma implementação própria e panteteada que promete resolver o problema. Fiquei muito inclinada e com muita vontade de experimentar o Jabra Evolve 2 65, mas o orçamento não permite e não existe revenda autorizada para pessoas físicas no Brasil.

#2 Super Gambiarra: Microfone separado

Essa é uma semi solução, mas foi a que acabei utilizando após pesar o custo-benefício. A ideia é adquirir um microfone USB de mesa e aí utilizar um fone sem fio apenas para o áudio (como os podcasters fazem).

Isso garantiu mobilidade mínima para ir beber água ou esticar as pernas sem perder o que está acontecendo, mas gera uma situação engraçada de largar a cafeteira e sair correndo para responder quando alguém chama. Além disso, a qualidade desses microfones não é perfeita para quem divide o escritório: mesmo os do tipo cardioide captam bastante som externo então precisa ficar esperto no push-to-talk ou então deixar as pessoas do outro lado sofrendo com qualquer vibração na mesa e falas de companheiros de casa.

Fora do Brasil também existem opções desse microfone apartado sem fio, que também resolveria o problema e sem atrapalhar a mobilidade. A tecnologia do microfone é excelente, os testes de qualidade de áudio dele são surpreendentes, esse seria um teste interessante e existem reviews bem promissoras, mas não tem no Brasil.

#3 Esperança: Bluetooth 5.2

A especificação da mais recente versão do Bluetooth (5.2) foi lançada recentemente e trás umas novidades muito atrativas e que mudam bastante em relação as versões anteriores.

Vale a pena ler o material completo, mas o que interessa para esse cenário é: MultiStream e o novo codec LC3.

Na teoria essas mudanças vão possibilitar que o a recepção e transmissão de áudio sejam feitas ao mesmo tempo em alta definição, mantendo os benefícios de baixo consumo de energia e com alcance e qualidade ainda maiores e mais estáveis.

Mas bluetooth é a única opção sem fio?

Não!

Existem opções de headsets sem fio que utilizam a tecnologia sem fio 2.4ghz e não sofre com os problemas do Bluetooth. Obviamente que nada é um mar de rosa e ela sofre com vários outros problemas, um deles, sendo o preço bem mais caro e a mobilidade menor já que na maioria das vezes o alcance é menor (30m do Bluetooth contra a média de 12m dos Wireless).

Essa tecnologia é geralmente encontrada em Headsets Gamer, que podem ser uma opção para quem está buscando conforto, bom áudio e bom microfone. Atualmente estou de olho em dois:

• Corsair Virtuoso Wireless SE
• Razer BlackShark V2 (Pro)

Vale ressaltar que se você curte muito ouvir música em alta definição nenhuma tecnologia sem fio ainda chega na mesma definição que fones com fio. A maioria das pessoas não vai notar a diferença, mas algumas pessoas sim.

Referências

• The next generation of Bluetooth® audio
• Audio over Bluetooth: most detailed information about profiles, codecs, and devices
• WIP: Bluetooth HSP and HFP profiles implementation via hsphpfd daemon
• How We Made The World's First Bluetooth Microphone - Hooke Audio
• Outras pessoas perguntando coisas parecidas como aqui
• [pulseaudio-discuss] [PATCH v11 07/11] bluetooth: Add A2DP FastStream codec support

Como simular os recursos da AWS localmente com LocalStack

Uma abordagem para desenvolvimento e testes de aplicações cloud em ambiente local: rápida, sem custo e offline.

Neste artigo vamos estudar uma abordagem para o desenvolvimento de aplicações que utilizem AWS, para desenvolvimento e testes em Integração Contínua. Ao fim, queremos pode executar os principais serviços da AWS (com suas APIs oficiais) utilizando Docker.

Isso nos permite um ciclo de desenvolvimento mais rápido e eficiente, além de conseguir incluir os serviços da AWS em nossa pipeline.

Requisitos

Não precisa de muita coisa para seguir este tutorial além de pouca familiridade com docker e AWS, mas são necessárias algumas instalações com, no mínimo, as seguintes versões:

As dores de cabeça que surgiram com a computação em nuvem

A computação em nuvem trouxe muitas mudanças e benefícios para o ciclo de desenvolvimento - menos preocupação com infraestrutura e mais preocupação com código. Mas esses benefícios chegaram a um custo para os desenvolvedores: agora não é mais possível ter um ambiente de desenvolvimento completo e isolado.

Enquanto cloud-based development não é popularizado, desenvolvedores de aplicações em nuvem trabalham em um ambiente hibrido - utilizando recursos cloud da AWS, por exemplo, é comum alocar uma infraestrutura completa de "desenvolvimento" para experimentar os serviços e permitir que os devs trabalhem.

Essa abordagem tem diversos pontos negativos, mas vou destacar dois principais: custos e limitações.

Por parte do custo, não existe uma versão gratuita dos serviços cloud para desenvolvimento, toda a utilização de recursos é cobrada e isso inclui testes, desenvolvimento, pipeline, experimentação, POCs e etc. Diferente de trabalhar em um cenário on-premise em que tudo é executado de forma local. Isso significa que testes de integração ficam prejudicados e limitados as bibliotecas de testes que tentam simular aquele ambiente.

Já na parte das limitações - além da latência e configurações de rede no caso de VPCs - muita liberdade do time de desenvolvimento é perdida, visto que eles estão atuando em um ambiente real que tem impacto imediato na conta e nos outros desenvolvedores. Em um time diverso, com pessoas com muita ou pouca experiência em cloud o ambiente cloud se torna uma dor de cabeça para quem utiliza e para quem paga a conta.

1. Setup
2. Provisionar/Utilizar recursos de forma transparente com aws-cli
3. Utilização (desenvolvimento e testes de integração em CI)

LocalStack FTW: trazendo a nuvem para o ambiente de desenvolvimento

LocalStack surgiu para resolver justamente este problema: executando de forma local (Docker), podemos ter todos os serviços da AWS disponíveis e fazer a bagunça que quisermos - offline, sem custos, sem limitações e sem atrapalhar os colegas. Por ser eficiente e portátil permite que o desenvolvimento utilize todo o poder da nuvem em um container.

O conceito é simples: ter um ambiente completamente funcional da AWS sendo executado de forma local, respeitando as APIs oficiais e sendo o mais transparente possível. Além disso, LocalStack simula erros reais da AWS e executa os serviços de forma totalmente desacoplada.

Instalando e Executando LocalStack

Dado todo esse contexto, agora veremos como instalar e executar os serviços AWS de fato com LocalStack. E é bem simples, instala o pacote localstack pelo pip e então executa com o comando start:

Se você digitar docker ps vai ver que temos o container executando a partir da imagem localstack/localstack expondo a porta 4566.

E com isso, temos a AWS executando em nossa máquina.

Para utilizar os recursos, podemos utilizar as próprias ferramentas da AWS para interagir, alterando apenas as configurações de perfil. Eu criei um perfil "localstack", mas pode ser o global, ou qualquer outra nomenclatura.

E agora, se você está acostumado com a AWS e digitar algum comando, por exemplo aws lambda list-functions, verá um erro porque não temos credenciais válidas da AWS.

Então, para conseguir executar os serviços, precisamos sobreescrever o endpoint padrão da AWS, utilizando o nosso local:

Exemplo de provisionamento e utilização de uma fila com SQS

Agora podemos utilizar todos os recursos da AWS pelo CLI ou pelas SDKs. Para o nosso caso de exemplo, vamos criar uma fila de pedidos a serem atendidos.

A primeira etapa é criar e provisionar a fila e, assim como ocorre em um ambiente real da AWS, podemos fazer dessa forma:

Agora, vamos simular que dois pedidos diferentes foram feitos e vamos enviar um por um para a fila:

[
    {
        "id": "ORDER#0001",
        "customer": "Myreli",
        "items": ["Fries", "Chocolate Shake"]
    },
        {
        "id": "ORDER#0002",
        "customer": "William",
        "items": ["Cheeseburger Combo Meal"]
    }
]

E por último, vamos consumir essas mensagens da fila, assim como faríamos de uma fila na infraestrutura da AWS:

Isso encerra o exemplo do uso de SQS com LocalStack, utilizando a ferramenta oficial da AWS para tal.

Para expandir o exemplo, o mesmo pode ser feito com uma SDK oficial em Node ou Kotlin, por exemplo. E aí basta configurar quando sobreescrever a URL original - na pipeline de CI e no ambiente de desenvolvimento.

Em Java, por exemplo, a implementação seria bem simples:

// Builder em ambiente Cloud
SqsClient.builder()
    .region(@Region)
    .build();
// Builder em ambiente Local
SqsClient.builder()
    .region(@Region)
    .endpointOverride("http://localhost:4576")
    .build();

Próximos Passos

Isso conclui a introdução ao LocalStack e já permite que seja implantado em projetos reais, mas é só uma ponta da ferramenta. Recomendo explorar o repositório oficial para otimizar o fluxo de trabalho.

Além disso, é um bom exercício para praticar implementar exatamente o mesmo exemplo apresentado aqui com alguma SDK oficial.