Tecnologia de áudio sem fio Bluetooth: qual é o melhor?

Com o desenvolvimento da tecnologia, os tão conhecidos fones de ouvido analógicos "tube" entram na história - eles são cada vez mais substituídos por parceiros sem fio Bluetooth.

Os smartphones modernos são privados do conector habitual por causa da proteção contra umidade e poeira.

Os desenvolvedores lançam todas as novas versões do protocolo Bluetooth e todas as novas versões de codecs, prometendo "mais rápido, mais alto, mais forte" - menos atrasos na reprodução e melhor qualidade.

Tudo é tão bom? Vamos ver

1. Introdução

Não vou me aprofundar na implementação técnica dos protocolos, bem como nas especificações chatas. Caro ValdikSS , que em grande parte atuou como inspiração e até consultor científico neste artigo, está preparando material abrangente sobre codecs - e tudo será apresentado lá com muito mais detalhes e tecnicamente correto.

Quero contar mais sobre a experiência pessoal. Bem, um pouco de prática divertida (chata?).

Há um ano e meio, fiquei empolgado com a ideia do aptX. Sim, li muitos comentários como esse e acreditei em todas essas reviravoltas técnicas. Nasceu uma criança - e eu realmente queria assistir a shows com fones de ouvido à noite com minha esposa, sem fazer barulho e sem acordar ninguém em casa.

Em que isso resultou?

Qualidade

Vamos começar com números e fatos (Olá, Wikipedia!)

O SBC é um bom codec antigo, em conformidade com o padrão A2DP. O codec é o resultado do trabalho de Frans de Bont (F. de Bont, M. Groenewegen e W. Oomen, “Um sistema de codificação de áudio de alta qualidade a 128 kb / s”, 98ª Convenção AES, 25 a 28 de fevereiro de 1995) e uso os algoritmos descritos na patente EP-0400755B1 . Vale ressaltar que os autores da patente permitem o uso gratuito da SBC apenas no aplicativo Bluetooth, no entanto, a patente expirou em 2 de junho de 2010. Como o padrão A2DP é muito comum, é extremamente difícil encontrar fones de ouvido ou alto-falantes que não tenham suporte à SBC.

O codec fornece uma frequência de amostragem de 16, 32, 44,1, 48 kHz com uma taxa de fluxo de 10-1500 kbit / s. Sim, você ouviu direito. Até 1500 kbps. Simplesmente não há limite de taxa de bits no codec. Mas mais sobre isso mais tarde.

O codec aptX foi desenvolvido em 1988 na Queen's University Belfast . Sim, antes do Bluetooth ainda havia cerca de uma dúzia de anos, então o codec era usado em equipamentos de áudio profissional. Atualmente, a Qualcomm possui os direitos e, portanto, o uso requer licenciamento e royalties. A partir de 2014, o custo é aproximadamente o seguinte: um pagamento único de US $ 6.000 e ≈ $ 1 para cada dispositivo liberado para partes de até 10.000 dispositivos. Por esse motivo, muitos dispositivos com chips Snapdragon 835, 845, 821, 820, 810, 805, 801, 800, 650, 615, 410 são bem possíveis e suportam o aptX, mas não é ativado por lá, porque a licença não foi adquirida. Sobre isso - também abaixo.

Com uma profundidade de 16 bits e uma frequência de amostragem de 48 kHz, o codec pode fornecer uma taxa de bits de 384 kbit / s (canal duplo).

Lista de produtos oficialmente suportados pelo aptX . Você pode encontrar muitos sistemas desconhecidos com suporte ao aptX no Aliexpress, mas esteja preparado para o fato de que realmente haverá o mesmo bom e antigo SBC - e não mais.

aptX HD - o mesmo codec, mas com um perfil de codificação diferente, tem uma velocidade de fluxo de 576 kbit / s, suporte para frequências de amostragem de até 48 kHz e profundidade de bits de até 24 bits. Algumas pessoas chamam isso de codec aptX Lossless - mas isso é um absurdo completo, apenas porque no momento é impossível alcançar o valor de um fluxo que possa transportar dados sem perda. Uma vantagem particular desse codec é um atraso de codificação ajustável, que pode ser reduzido para 1 ms a uma frequência de amostragem de 48 kHz. Além disso, o codec é extremamente vantajoso do ponto de vista do carregamento do processador, o que expressa uma vantagem em comparação ao MP3 e AAS.

Lista de produtos oficialmente suportados pelo aptX HD . Ele é pequeno o suficiente.

O latência baixa do aptX (ou LL) é uma versão especial do codec que permite reduzir o tempo de atraso do som para menos de 40 ms. Lista de produtos oficialmente suportados pelo aptX LL .



Lá está ela. Foi essa foto que certa vez me comprou com crianças. Atrasos! Afinal, quem quer ouvir o som de uma explosão em algum filme de ação, o grito de um monstro em um filme de terror ou o rugido de uma multidão em uma partida de futebol quando tudo acaba?

Mas tudo isso é realmente assim?

Infelizmente, não.

Como em qualquer material de marketing, os números são absurdos. O atraso depende muito do buffer na implementação do sistema e do codec. Portanto, o atraso com a SBC pode muito bem ser inferior a 40 ms, o que, considerando os padrões de transmissão de televisão (+40 ms ... - 60 ms), é perfeitamente aceitável.

Em resumo:

1. Nenhum codec existente pode ser melhor que a tecnologia com fio, já que nenhum codec pode alcançar uma verdadeira compactação sem perdas.
2. O codec mais popular é o SBC. Ele é o mais flexível nas configurações. E apesar do fato de o aptX ter sido lançado anteriormente, ele não conseguiu superar a popularidade da SBC, aparentemente devido ao fato de o último ser gratuito.
3. A qualidade do som depende extremamente da implementação do codec, bem como do desempenho do hardware dos fones de ouvido / alto-falantes em geral - se o alto-falante for fraco, a qualidade não poderá ser melhorada por nenhum codec. Portanto, no futuro, comparando a qualidade, falaremos sobre a reprodução do mesmo conteúdo da mesma fonte nos mesmos alto-falantes / fones de ouvido, mas com codecs diferentes.

Resultados práticos e muito subjetivos

As informações são baseadas na experiência de um ano e meio já mencionada em operação, comparação e atração de ouvintes externos.

A experiência baseia-se em ouvir sem perdas no reprodutor SONY Walkman NWZ-A17, onde o codec pode ser selecionado, bem como assistir a vários programas com saída de áudio através do Avantree Priva III.

Havia três fones de ouvido: Sennheiser PMX 60, Koss Porta Pro e Koss UR-20.

O Jabra BT3030 (SBC) e o Avantree Clipper Pro (aptX) foram utilizados como receptores de sinal sem fio.

Também foram utilizados um alto-falante Voombox Outdoor (SBC) e fones de ouvido para condução óssea Aftershokz Trekz Titanium (aptX).

Todos os equalizadores e aprimoradores foram desativados - e isso é importante.

Total:

1. A qualidade do som reproduzido com uma conexão com fio é sempre melhor. Isto é sem dúvida.
2. A diferença entre SBC e aptX é extremamente difícil de ouvir - e apenas no caso de alguns tipos de música. Por exemplo, o autor do artigo ouviu claramente a diferença no violoncelo nas composições clássicas, enquanto no violino e nos instrumentos de baixa frequência a diferença foi menos perceptível. Nos gêneros modernos - pop, música eletrônica e rock - a diferença não é ouvida. Em alguns casos, parecia subjetivamente que a SBC transmite som melhor que o aptX.
3. O atraso entre o SBC e o aptX pode ser visto apenas se você se conectar à mesma fonte e inserir diferentes receptores em diferentes ouvidos (bem, o canal esquerdo é SBC e o canal direito é o aptX, por exemplo). É quase impossível ver o atraso com a imagem, mas porque a história de que o aptX se destina a cenas e conteúdo dinâmicos é um mito.
4. A surpresa foi causada pela qualidade do som no Voombox Outdoor, bastante barato e "não famoso". Aparentemente, esta é a implementação bem-sucedida do SBC, mencionada acima.
5. A implementação do aptX em fones de ouvido com condução óssea é completamente incompreensível - a tecnologia é muito específica e, portanto, a perda de qualidade é significativa devido à própria tecnologia. Tendo em conta o pequeno alcance do "alcance" da operação do dispositivo, a implementação extremamente pobre do emparelhamento com dois dispositivos, posso dizer que a Aftershokz é uma empresa que investe mais em marketing do que em desenvolvimento.

Não estou argumentando que, se você conectar todos os tipos de analisadores espectrais e assim por diante, poderá e deve ver a diferença. Mas o ouvido humano, e pior ainda - o ouvido humano médio - não é um dispositivo espectral e, portanto, não ouve todas essas nuances.

Prática: consertando o que pode ser consertado

Parte 1. Ative o aptX

Como já mencionado, em alguns dispositivos o uso do aptX é desativado, provavelmente para evitar processos de patentes.

Esse problema pode ser resolvido simplesmente deslizando o dispositivo de biblioteca para implementar o codec e escrevendo a capacidade de trabalhar com esse codec no build.prop.

Na Internet, há um grande número de soluções dessa natureza. Tomei a liberdade de combiná-los em um, enquanto realizava isso como um módulo para Magisk. Sim, eu realmente gosto deste projeto e acho que implementar mudanças no sistema na forma de módulos Magisk é uma solução melhor e mais segura, com a capacidade de salvar o sistema na sua forma original e de uma maneira fácil de reverter.

O módulo pode ser baixado aqui . Sim, eu sei sobre o github. E não, até eu ter tempo de colocá-lo lá.

As entradas no build.prop, incluindo o aptX e, se possível, o aptX HD, serão emuladas automaticamente pelo módulo.

Parte 2. Aumente a taxa de bits da SBC

Conforme relatado anteriormente, o codec SBC basicamente não possui restrições de taxa de bits. No entanto, os fabricantes geralmente estabelecem um limite de 342 kbit / s para mono e 345 kbit / s para estéreo, a fim de garantir uma operação confiável com todos os tipos de dispositivos receptores.

Ao mesmo tempo, a especificação A2DP v1.2, que estava ativa de 2007 a 2015, exige que todos os dispositivos de decodificação funcionem corretamente com taxas de bits de até 320 kbit / s para mono e 512 kbit / s no caso de um sinal estéreo.

Na nova versão da especificação, não há limite de taxa de bits. Supõe-se que os fones de ouvido modernos lançados após 2015 e com suporte ao EDR possam suportar taxas de bits de até 730 kbps.

De fato, esse certamente não é o caso. Em um extenso estudo realizado pelo ValdikSS , constatou-se que quase todos os dispositivos receptores funcionam de maneira confiável com taxas de bits de 454 kbit / s, e um número bastante grande com uma taxa de bits de 507 kbit / s.

Em sua pesquisa, o ValdikSS também mostrou que, ao contrário da crença popular sobre a qualidade do som do codec aptX, ele pode produzir resultados piores em alguns arquivos do que o SBC com uma taxa de bits padrão de 328 kbps, e a mudança para o SBC de alta taxa de bits produzirá som que geralmente excede aptX, em qualquer fone de ouvido.

Com base nesses dados, o ValdikSS enviou comentários aos desenvolvedores do Lineage OS e do Google, mas até agora não houve reação.

Assim, só podemos fazer modificações manualmente na pilha Bluetooth.

Precisamos de um IDA Pro com a capacidade de descompilar o ARM, qualquer editor HEX (usei o WinHEX) e o arquivo bluetooth.default.so do nosso dispositivo. Normalmente, ele está localizado no caminho / system / lib / hw e com menos frequência - também no caminho / system / lib64 / hw (o acesso root é definitivamente necessário).

Portanto, abra o arquivo bluetooth.default.so.As operações e modificações descritas abaixo se aplicam apenas à pilha Android original (bluedroid). Se você vir a linha “Biblioteca necessária 'com.qualcomm.qti.bluetooth_audio@1.0.so'” ou similar no IDA Pro, com alta probabilidade, esta instrução não o ajudará.



Nossa primeira tarefa é substituir o Joint Stereo pelo Dual Channel em uma configuração padrão.

Vamos trabalhar com a função bta_av_build_src_cfg .

Para encontrar esse procedimento no IDA, usaremos a linha de busca por uma mensagem característica no log de depuração "Não é possível analisar src cap ret =% d" :





Como resultado, rapidamente encontramos a própria função na forma de código:



Nossa tarefa é substituir a estrutura original de cheques

if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_JOINT) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_JOINT; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_STEREO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_STEREO; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_MONO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_MONO;</code>  <code> if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_STEREO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_STEREO; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_MONO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_MONO; 

Existem várias maneiras de fazer isso.

A primeira é a substituição das instruções TST.W R0, # 1 por TST.W R0, # 4 e MOVS R0, # 1 por MOVS R0, # 4 na sequência de verificações:



No bytecode, essa é a substituição de x01 para x04. É importante observar a sequência característica de bytes pela qual esse padrão pode ser encontrado. Sem me aprofundar nos detalhes, direi que, em essência, é uma busca por sequência

 10 20 8D F8 04 00 9D F8 0D 00 10 F0 01 0F ?? ?? 10 F0 02 0F ?? ?? 10 F0 04 0F ?? ?? 10 F0 08 0F ?? ?? 08 20 ?? ?? 01 20 ?? ?? 02 20 ?? ?? 04 20 

e sua substituição por

 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 04 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 04 ?? ?? ?? ?? ?? ?? ?? ?? ?? 

No entanto, este método tem desvantagens.

Vários compiladores alteram a sequência de execução de comandos, dependendo da otimização. E, nesse caso, não é possível encontrar o padrão desejado e, às vezes, o mecanismo de verificação na estrutura é geralmente introduzido no código embutido. Portanto, é mais confiável alterar a constante btif_av_sbc_default_config .

Para iniciantes - encontre-a. Ela está no começo de nossa função, porque

 void bta_av_build_src_cfg (UINT8 *p_pref_cfg, UINT8 *p_src_cap) { tA2D_SBC_CIE src_cap; tA2D_SBC_CIE pref_cap; UINT8 status = 0; /* initialize it to default SBC configuration */ A2D_BldSbcInfo(AVDT_MEDIA_AUDIO, (tA2D_SBC_CIE *) &btif_av_sbc_default_config, p_pref_cfg); /* now try to build a preferred one */ /* parse configuration */ if ((status = A2D_ParsSbcInfo(&src_cap, p_src_cap, TRUE)) != 0) { APPL_TRACE_DEBUG(" Cant parse src cap ret = %d", status); 

E aqui está ela:





Pode-se observar que o próprio btif_av_sbc_default_config é uma sequência de bytes 20 01 10 04 01 35 02, enquanto o primeiro byte codifica a frequência de amostragem e pode ser 10 (48 kHz) e 20 (44 kHz) e, portanto, não específico. Assim, nossa tarefa é substituir a sequência
01 10 04 01 35 02
em
04 ?? ?? ?? ?? ??

Isso permitirá que você altere a lógica da estrutura de maneira semelhante, mas, ao mesmo tempo, otimizar o compilador não causará problemas.

Em alguns casos, os próprios fones de ouvido ou alto-falantes iniciam a conexão. Nesse caso, o modo é determinado pela função bta_av_co_audio_init .

A função é caracterizada pela linha "bta_av_co_audio_init:% d" e é facilmente pesquisada no código:


A enumeração dos possíveis modos de conexão é realizada no seguinte comando:

  switch (index) { case BTIF_SV_AV_AA_SBC_INDEX: /* Set up for SBC codec for SRC*/ *p_codec_type = BTA_AV_CODEC_SBC; /* This should not fail because we are using constants for parameters */ A2D_BldSbcInfo(AVDT_MEDIA_AUDIO, (tA2D_SBC_CIE *) &bta_av_co_sbc_caps, p_codec_info); /* Codec is valid */ return TRUE; 

a constante bta_av_co_sbc_caps possui a seguinte estrutura :

 const tA2D_SBC_CIE bta_av_co_sbc_caps = { (A2D_SBC_IE_SAMP_FREQ_44), /* samp_freq */ (A2D_SBC_IE_CH_MD_MONO | A2D_SBC_IE_CH_MD_STEREO | A2D_SBC_IE_CH_MD_JOINT | A2D_SBC_IE_CH_MD_DUAL), /* ch_mode */ (A2D_SBC_IE_BLOCKS_16 | A2D_SBC_IE_BLOCKS_12 | A2D_SBC_IE_BLOCKS_8 | A2D_SBC_IE_BLOCKS_4), /* block_len */ (A2D_SBC_IE_SUBBAND_4 | A2D_SBC_IE_SUBBAND_8), /* num_subbands */ (A2D_SBC_IE_ALLOC_MD_L | A2D_SBC_IE_ALLOC_MD_S), /* alloc_mthd */ BTA_AV_CO_SBC_MAX_BITPOOL, /* max_bitpool */ A2D_SBC_IE_MIN_BITPOOL /* min_bitpool */ }; 

A constante é facilmente encontrada no código, no meu caso é 20 0F F0 0C 03 35 02:



Preste atenção ao byte 0F - ele permite a conexão com qualquer um dos modos válidos, pois

 x0F = A2D_SBC_IE_CH_MD_MONO | A2D_SBC_IE_CH_MD_STEREO | A2D_SBC_IE_CH_MD_JOINT | A2D_SBC_IE_CH_MD_DUAL = x08 | x02 | x01 | x04 

Nossa tarefa é alterar esse valor da seguinte maneira:

 x0F = A2D_SBC_IE_CH_MD_DUAL = x04 

Portanto, é necessário substituir

?? 0F F0 0C 03 35 02
em
?? 04 ?? ?? ?? ?? ??

Portanto, forçamos a pilha a se conectar no modo Dual Channel, tanto no caso de iniciar uma conexão pelo dispositivo, quanto no caso de iniciar uma conexão pelo lado receptor do sinal.

Agora você precisa remover as restrições na taxa de bits ou aumentar seu limite superior.

Precisa lidar com btif_media_task_get_sbc_rate . Da mesma forma, para procurar a linha de característica “coletor a2dp não edr detectado, restringir a taxa para% d”, procuramos a função no código:


O limite da taxa de bits é expresso em uma sequência
Taxa UINT16 = DEFAULT_SBC_BITRATE (que por sua vez é de 328 kbps )

No código, é assim:



Altere esse valor para 454 kbit / s - é mais alto que o padrão e funciona com a grande maioria dos receptores. Para fazer isso, substitua os bytes

B1 4F F4 A4 74 ?? E0
em
?? ?? ?? E3 ?? ?? ??

Você também deve procurar por padrão.

E0 4F F4 A4 74 ?? E0
e substitua-o por
?? ?? ?? E3 ?? ?? ??
- Isso é necessário para vários dispositivos.

O valor de E3 pode ser diferente dependendo da taxa de bits máxima desejada:

• E3 - 454 kbps
• F1 - 482 kbps
• F3 - 486 kbps
• 10 - 576 kbps
• 48 - sem limite

Em geral, isso é determinado pelo bytecode da operação MOV.W R4, XXX.

Na prática, vale a pena experimentar e escolher o valor máximo no qual todos os seus dispositivos receptores recebem uma recepção estável do sinal, sem rachaduras, interrupções ou distorções.

Em todos os receptores do meu experimento (eu os indiquei acima), esse valor foi de 576 kbit / s, o telefone Xiaomi Redmi 4x MIUI10 Android 7.1 foi a fonte do sinal.

Com base nas ações descritas, foi criado um patch genérico que encontra os padrões especificados em Bluetooth.default.so e os substitui? incluindo o modo Dual Channel forçado e definindo o limite de taxa de bits para 454 kbps. Se necessário, o valor limite pode ser facilmente alterado com base na pesquisa e substituição do byte correspondente - um leitor atento fará isso sem dificuldade.

Enfatizo: o patch só funciona no caso da pilha bluedroid e provavelmente não será bem-sucedido no caso da pilha Fluoride e na versão Android 8 e posterior.

O patch pode ser baixado aqui .

É altamente recomendável que você substitua o arquivo original como módulos Magisk, por mim mesmo fiz o seguinte . Observe : esses módulos foram feitos por mim para o telefone Xiaomi Redmi 4x 3/32 GB com o atual firmware MIUI 10. global estável no momento da redação. No seu caso, o arquivo bluetooth.default.so precisará ser substituído pelo seu próprio, corrigido, conforme descrito acima. Também é possível que o arquivo precise ser duplicado no caminho / system / lib64 / hw - depende do modelo e da versão do firmware do seu telefone.

Essa abordagem usando os módulos Magisk facilita a alteração da taxa de bits máxima e geralmente desabilita as alterações se ocorrer que alguns dos dispositivos receptores não suportam o canal duplo.

Conclusão

No momento, na busca de vendas, muitas empresas estão apresentando algumas inovações tecnológicas como justificativa para um preço mais alto.

Na prática, verifica-se que as tecnologias mais baratas existentes não são totalmente desenvolvidas e as inovações tecnológicas não são totalmente implementadas, o que afeta significativamente a qualidade.

Muitas vezes, os usuários experimentam o “efeito placebo”, convencendo-se da perfeição de um produto apenas porque é mais novo ou mais colorido apresentado. De fato, essa qualidade é imaginária.

Apesar da deterioração óbvia na qualidade da transmissão de áudio sem fio em comparação com a versão com fio, parece que os fabricantes modernos de dispositivos visam uma transição completa para as tecnologias sem fio. Ao mesmo tempo, truques de marketing são usados ​​para justificar o aumento de preço: proteção contra imersão do telefone na água (como você pode falar debaixo d'água? Por que deixar o dispositivo na água?), Uso de codecs mais caros etc. Ao mesmo tempo, o potencial do codec SBC popular existente não é totalmente utilizado.

Não foi possível obter esclarecimentos do Google sobre o limite de taxa de bits de 328 kbps, nem eliminar esse limite e adicionar a opção de ativar o Dual Channel no menu Bluetooth dos desenvolvedores do Lineage OS.

Obrigado a todos que leram até o fim!

Alguma continuação causada pela discussão nos comentários e um espaço referente ao codec LDAC está aqui .