Por que apps de música serão melhores do que antes no Android Jelly Bean

Dispositivos Android terão, afinal, o tipo de desempenho sonoro que torna música e áudio em geral satisfatórios para mim. Sofremos por gerações com um sistema e um hardware que eram o oposto disso. Mas mudanças materiais e mensuráveis no software, combinadas com padrões mais rigorosos das fabricantes de hardware podem inverter esse cenário em breve. E usando a gratuita e multiplataforma biblioteca libpd, você já pode se preparar para tirar vantagem do que está por vir.

O lançamento do developer preview do Android Jelly Bean está recheado de refinamentos que o tornam mais rápido e esperto para o usuário médio. De quebra, músicos também têm muito a ganhar. Nossos amigos do Create Digital Music compilaram esta resumo não tão resumido de novos recursos destinado aos apreciadores da boa música. O texto é de Peter Kirn.

Se você está usando um app que envolva som ou música, o desempenho da camada inferior do sistema e o hardware farão uma grande diferença. Isso é ainda mais verdadeiro se você estiver usando um app que simula um instrumento musical, porque será mais fácil notar quão responsivo ele é em tempo real. Se hardware, SO e apps trazem muitos excessos, você pode notar sintomas como cliques e ruídos — ou, para prevenir esses glitches, os desenvolvedores podem criar grandes buffers de áudio que tornam os apps menos responsivos. O desafio na plataforma Android, então, é eliminar os excessos e enviar o som aos seus ouvidos o mais diretamente possível.

Em suma, é isso o que mudará no Android 4.1 “Jelly Bean” e dispositivos que o rodem:

• Capacidade de tocar áudio com baixa latência, através de um novo mixer de software e outras melhorias em API.
• Objetivo de latência abaixo de 10 ms. No momento, a execução com baixa latência (o que acaba impactando a latência de ida/retorno) se refere apenas ao Samsung Galaxy Nexus; outros dispositivos deverão receber melhorias em desempenho similares, mas não se sabe ainda, oficialmente, quais, nem quando.
• Em algum momento futuro, requisitos de latência para fornecedores terceiros mais rígidos.
• Recursos do sistema melhorados também: suporte a dispositivos de áudio USB, áudio multicanal (incluindo via HDMI), recursos de gravação e mais.

Mas falemos um pouco sobre o porquê disso ser importante — em termos que sejam compreensíveis independente de você ser um desenvolvedor ou não.

É difícil não perceber a importância disso se você souber qualquer coisa sobre o que faz uma boa experiência sonora em software. Seres humanos são, em média, dotados dos mesmos poderes de percepção e audição. Você não precisa ser um “músico profissional” para notar quando um app sonoro ou musical não é responsivo. Ouvidos destreinados responderão imediatamente — e impiedosamente — a crepitações, ruídos e atrasos no som. (O último problema, descrito como “latência”, é sutil mas não menos importante — você toca na tela e espera ter uma resposta imediata. Usuários costumam reagir negativamente aos menores atrasos, conscientemente ou não.)

Assim, quando falamos em “alto desempenho em áudio,” na prática nos referimos a qualquer uso de som em apps. É fácil entender por que isso é importante. Só é difícil do ponto de vista da engenharia.

Elevando o nível, diminuindo a latência

“Latência” não é uma métrica. Pense na velocidade de um carro de corrida. Cada pequeno ajuste no motor, embreagem, peso e aerodinâmica tem um impacto. Esses resultados são cumulativos. Você não pode simplesmente ajustar um fator corretamente; você tem que cuidar de todos eles corretamente. E é isso o que tornava o triste desempenho sonoro do Android complexo de descrever no passado. Ele era uma combinação de fatores — funcionalidades incompletas na API de desenvolvimento, um mixer do sistema que acrescentava latência e problemas em dispositivos específicos eram três dos maiores problemas.

A Apple tem feito um excelente trabalho nessa parte no iOS, o que contribui para a sua quase completa supremacia em apps móveis para música — e justifica, também. Mas isso não deve significar que seja impossível alcançar o desempenho em áudio de baixa latência quando se trabalha com uma grande variedade de fabricantes de hardware. O PC Windows (ou Linux) é um grande exemplo — tanto no que funciona (latência extremamente baixa entre dispositivos que usam uma API como a ASIO) como no que não funciona (mixers de uso geral que direciona latências que passam a 1/10 de segundo).

Baseado no que os desenvolvedores Android estão dizendo, a plataforma está pelo menos indo para a direção certa. Na realidade, ela está em contraste com o que já sabemos do Windows 8 no campo da mobilidade. Os exatos problemas que levantei semana passada  em minha crítica sobre o que está documentado no Windows RT são os que os desenvolvedores do Android estão finalmente corrigindo. O Windows RT e a biblioteca WinRT/Metro para desktop e mobile, baseada nas informações atuais, não só carece de recursos “é legal ter” como USB e áudio em multicanais em uma nova geração de tablets Windows, mas também parece definir uma tolerância com latência inaceitável — +100 ms, ou onde o Android estava há um ano. Esperamos descobrir que há mais coisas das quais não sabemos; mas estamos no aguardo de mais informações da Microsoft. Sobre o assunto: Desenvolvimento musical no Windows 8: um salto para frente nos desktops; um salto para trás no Metro, WinRT? [em inglês].

Naquele artigo sobre o Windows 8, falei sobre a importância de se ter a capacidade de rotear o som através de um mixer do sistema sem outros sons antecipando o que você está fazendo. É isso o que o WinRT e o Windows RT parecem não ter (apesar dos seus nomes), e o que o Android talvez finalmente consiga. (É o que iOS, Windows, Linux e OS X todos têm de alguma forma.)

De volta à metáfora do carro, imagine que você esteja em uma corrida de arrancada. Você gostaria de pisar fundo no acelerador em uma convidativa rua deserta ou numa avenida movimentada de uma grande cidade na hora do rush?

Mixers de sistema genéricos se parecem muito com o segundo cenário. E foi isso que o time de desenvolvimento do Android explicou numa sessão de perguntas e respostas na Google I/O, semana passada. Classificando o projeto de “um trabalho em andamento,” eles dizem que o objetivo é uma execução abaixo dos 10 ms. (“Execução quente” eu acredito que signifique que o motor do áudio esteja ligado e haja algo para tocar  no buffer; alguém me corrija se tiver uma interpretação diferente.)

Como um desenvolvedor do Android disse, a respeito dos mixers de sistema: “Uma vez que você chega àquele nível, qualquer coisa que esteja no sistema e se antecipa torna-se problemática.”

Os desenvolvedores do Android estão fazendo progressos visíveis no software. O maior desafio é provavelmente estar em sintonia com as fabricantes de hardware. No Samsung Galaxy Nexus — um dispositivo sobre o qual o Google tem mais controle — eles já melhoraram a latência de 100 ms no Ice Cream Sandwich (4.0) para “cerca de 12 ms” no Jelly Bean (4.1) e querem ir além. 12 ms é usável; abaixo de 10 ms poderia atrair de verdade alguns desenvolvedores para a plataforma. Nota: gostaria de ouvir mais sobre o tablet Nexus 7, mas por ora, ninguém disse nada sobre o desempenho sonoro daquele hardware, que é fabricado pela Asus, não a Samsung.

O “Fast Mixer” funcionará com as APIs SoundPool, ToneGenerator e OpenSL. Estamos empolgados com a API OpenSL, pois já ficamos sabendo de desenvolvedores tendo ganhos em desempenho em relação a versões anteriores do sistema usando essa ferramenta. (Mais sobre como usá-la com a biblioteca gratuita libpd abaixo.)

A ponto no ar aqui é quando você verá de fato dispositivos chegando a esses níveis no mundo real. Infelizmente, isso pode se tornar mais do que um jogo de espera. O Google diz que eles querem “chegar a um ponto” no qual possam estabelecer a latência máxima, mas não está claro quando isso ocorrerá.

Dada a experiência altamente inconsistente dos dispositivos atuais, meu palpite é de que o desenvolvimento com foco no Android será bem rígido nos requisitos mínimos. Se pelo menos latências abaixo de 15 ms se tornarem a norma para dispositivos Jelly Bean, eu vislumbraria a versão 4.1 do sistema como pré-requisito, evitando assim reclamações dos usuários quando o app não se comportar como o esperado.

O Jelly Bean em geral promete algumas melhorias animadoras: enfim vemos foco em acessórios de hardware, áudio de alta qualidade e animação de alta qualidade e com altos framerates. Essas são algumas das coisas que tornam o iOS tão divertido de usar e tão satisfatório para ambos usuários e desenvolvedores. Especialistas têm corretamente corroborado o que a Apple diz, de que software não é só sobre especificações. Mas essas não são especificações vazias: elas são uma métrica concreta das qualidades que as pessoas experimentam em nível sensorial quando estão usando um software.

Mais qualidade de áudio

Estou também muito ansioso para ver as mudanças visuais, mas no lado do áudio, o 4.1 traz um monte de funcionalidades esperadas:

• Suporte a áudio USB, exposto através do ADK do Android.
• Áudio multicanal via HDMI (instalações de áudio surround baseadas em Android, alguém?).
• Acesso a codecs de mídia na plataforma de hardware em nível de software (com um monte de recursos legais de baixo nível).
• Desencadeamento de gravação de áudio.
• Pré-processamento de áudio.
• Encadeamento de áudio, o que significa (entre outras coisas) suporte para execução sem emendas.
• Roteamento de mídia (um pouco mais próximo do que a Apple faz com o AirPlay).

Dessa lista, claro, o que interessa a nós, músicos, é realmente o multicanal via HDMI e áudio USB. Estarei de olho na forma com que o áudio USB é implementado, se eles darão suporte de classe ao áudio USB como no iOS, e (só pela diversão) se suporte a MIDI USB será possível.

Tudo isso está descrito na visão geral do Jelly Bean, mas acho que os desenvolvedores quererão ir além e pegar o SDK para saber mais detalhes.

OpenSL e libpd

Para vocês, desenvolvedores, o OpenSL é uma coisa grande. (E usuários, apenas… confiem na gente. Em breve vocês terão uma experiência melhor com apps Android como resultado.)

Peter Brinkmann é o desenvolvedor principal da libpd. Para aqueles de vocês que estão chegando agora, libpd é a versão incorporável aberta e gratuita da Pure Data que hoje roda em sistemas desktops e móveis. Ela é, na realidade, o núcleo da Pure Data, não um fork, mas fornece suporte adicional em torno daquele núcleo para facilitar o uso dos patches Pd dentro de outros apps. Peter tem trabalhado duro no suporte ao OpenSL — e se deparou com motivos suficientes para se empolgar com o que está por vir.

Peter nota que o OpenSL está trabalhando melhor que a saída padrão em Java em todos os dispositivos testados. Você pode usá-lo com a biblioteca libpd, mas Java, C e o processamento para desenvolvedores Android devem se beneficiar também.

Ah sim, e o design da ramificação OpenSL deverá ser útil também em outras plataformas além do Android: Peter nota que ele já tem “um protótipo usando PortAudio que levou cerca de 15 minutos para implementar e rodar muito bem no meu Mac. Portar isso para outras plataformas é apenas uma questão de fazer o trabalho duro de ajustar makefiles e coisas do tipo. Resumindo, isso promete transformar a libpd em uma solução autônoma viável para o Java, sem necessariamente precisar do uso de algo como o JavaSound.” (Desculpe por transcrever seu email, Peter, mas com a esperança de que outras pessoas acabem nos ajudando nisso, decidi publicar.)

Leitura recomendada: Peter tem uma série sobre libpd e OpenSL ES. Ela mostra um pouco do futuro do desenvolvimento de áudio em Android e também o futuro do desenvolvimento de software sonoro gratuito e multiplataforma para Pd (e outras plataformas, claro) muito além do Android.

libpd and OpenSL ES, Part I: Squaring the circle

libpd and OpenSL ES, Part II: Yet another JACK-like API for Android

libpd and OpenSL ES, Part III: Receiving messages

libpd and OpenSL ES, Part IV: Extending the API

E para tirar vantagem disso no Android na libpd:

“Eu acabei de criar uma nova variante do pd-for-android que suporta o AudioTrack/AudioRecord para FroYo e anteriores, ou OpenSL ES para Gingerbread e posteriores. Eu consegui resolver esse quebra-cabeça e tornar a transição inteira mais ou menos transparente para os desenvolvedores. Se você se limitar à parte da API que abordo em meu livro (ou seja, tudo menos os métodos de processamento de áudio de baixo nível), então seus apps não precisarão de ajuste algum.”

Enquanto acontece, a habilidade de alternar entre motores de áudio poderá ser relevante no futuro quando usarmos JACK, Core Audio, ASIO e outros em sistemas operacionais diferentes.

Para tudo que você precisa da libpd, incluindo o soberbo livro de Peter que o iniciará no desenvolvimento em iOS e Android, vá ao nosso site: http://libpd.cc.

E fique ligado. Continuaremos trazendo notícias de áudio e música para usuários e desenvolvedores, independente da plataforma.

AMIGA, talvez?

***

Republicado com permissão do Create Digital Music, um site com notícias diárias para pessoas que fazem música com tecnologia. O editor Peter Kirn é também músico eletrônico e desenvolvedor musical e também contribui com a biblioteca libpd.