O Orin é um projeto de aplicativo para transformar o microfone de um celular Android em uma entrada de áudio para computadores Linux e Windows, usando a rede Wi-Fi local.
A primeira entrega utilizável será voltada ao Linux. O suporte ao Windows virá depois, aproveitando o núcleo Java e adaptando a integração com os dispositivos de áudio do sistema.
Estado atual: as bases de reprodução PCM, recepção UDP e codificação/decodificação de pacotes já foram implementadas e testadas no desktop Java. O pipeline experimental UDP → codec → reprodução PCM foi integrado e validado em loopback, incluindo dois processos Java independentes. O Orin ainda não captura áudio do Android, não cria um microfone virtual e não está pronto para substituir os aplicativos existentes.
| Componente | Estado | O que existe |
|---|---|---|
| Projetos e automações | Implementado | Monorepo com builds Gradle independentes para Android e desktop; CI e Dependabot |
| Saída PCM no desktop | Implementado e testado | PcmAudioOutput, AudioLineFactory, controle de abertura/escrita/fechamento e drain() |
| Reprodução real no Linux | Validada manualmente | Programa que gera e reproduz um tom de 440 Hz por um segundo |
| Receptor UDP | Implementado e testado | UdpAudioReceiver, porta configurável, timeout, liberação do socket e testes em loopback |
| Codec de pacotes | Implementado e testado | AudioPacketCodec e AudioPacket; cabeçalho experimental e testes de entradas inválidas |
| Integração UDP → codec → áudio | Implementada e validada em loopback | DesktopAudioPipeline recebe, decodifica e encaminha o PCM à saída de áudio |
| Captura e transmissão Android | Pendente | AudioRecord e envio dos quadros PCM por Wi-Fi |
| Microfone virtual Linux | Pendente | Encaminhamento do áudio para dispositivo virtual via PipeWire |
| Microfone virtual Windows | Pendente | Integração com um dispositivo virtual existente, como VB-CABLE |
| Segurança da conexão | Pendente | Pareamento, autenticação e transporte criptografado |
Os testes de unidade e integração local cobrem os componentes de áudio, rede e protocolo, além do pipeline e da rejeição de datagramas excedentes mesmo após truncamento. As quatro entregas iniciais do desktop foram integradas à main: PCM, receptor UDP, codec experimental e configuração do Gradle Configuration Cache.
O que já foi demonstrado: reprodução de PCM por uma saída real no Linux e transmissão de tons por UDP com decodificação e reprodução no próprio computador, tanto em um processo como entre dois processos Java independentes. O que ainda não foi demonstrado: áudio vindo do celular e chegando a um programa que reconheça o Orin como microfone.
| Área | Tecnologias e decisões |
|---|---|
| Android | Kotlin, Jetpack Compose e Material 3; captura futura com AudioRecord |
| Desktop | Java 25, Java Sound API; interface gráfica ainda não definida |
| Rede | UDP na rede local, inicialmente com IP e porta informados manualmente |
| Áudio | PCM mono, 48 kHz, 16 bits com sinal, little-endian |
| Linux | PipeWire para integração com microfone virtual (pendente) |
| Windows | Dispositivo de áudio virtual existente, inicialmente VB-CABLE ou equivalente (pendente) |
| Build | Gradle Kotlin DSL; projetos Android e desktop independentes |
| Testes | JUnit, Mockito e testes com sockets UDP reais em loopback |
| Automação | GitHub Actions para builds/testes independentes e Dependabot |
Não há necessidade planejada de servidor na nuvem, conta de usuário ou banco de dados. Código nativo em Rust ou C++ será considerado apenas se a integração com os sistemas operacionais exigir.
O formato de áudio adotado nos primeiros experimentos é PCM sem compressão:
| Propriedade | Valor |
|---|---|
| Taxa de amostragem | 48.000 Hz |
| Canais | 1 (mono) |
| Profundidade | 16 bits com sinal |
| Ordem dos bytes PCM | Little-endian |
| Duração de um quadro | 10 ms |
| Payload por quadro | 960 bytes |
O codec experimental do desktop monta um datagrama de 976 bytes, formado por um cabeçalho de 16 bytes em big-endian e 960 bytes de PCM em little-endian. O cabeçalho inclui a assinatura ORIN, versão, tipo, número de sequência, timestamp e comprimento do payload.
Android (planejado) Desktop (pipeline experimental)
AudioRecord
│
Quadros PCM
│
Envio por UDP ───── Wi-Fi ──────> UdpAudioReceiver
│
AudioPacketCodec
│
PcmAudioOutput
│
Saída de áudio / diagnóstico
│
Microfone virtual (futuro)
O trecho desktop UDP → codec → reprodução PCM está integrado. UdpAudioReceiver utiliza um buffer de 977 bytes: recebe o pacote válido de 976 bytes por inteiro e preserva um byte adicional para que o codec rejeite datagramas excedentes. Pacotes maiores que o buffer são truncados para 977 bytes e continuam inválidos. A captura Android e o microfone virtual permanecem planejados.
Ainda faltam controle de sessão, ordenação e temporização de pacotes, jitter buffer e proteção criptográfica. O cabeçalho é experimental e poderá mudar após os testes de interoperabilidade com Kotlin ou a avaliação de protocolos consolidados. Consulte a documentação do protocolo para detalhes dos campos e limitações.
- Git e os Gradle Wrappers incluídos no repositório.
- IntelliJ IDEA e JDK 25 para desenvolver o desktop.
- Android Studio e Android SDK para o aplicativo Android.
- Um dispositivo Android com microfone para os testes futuros de captura.
- Um dispositivo de saída de áudio disponível para o teste manual de reprodução.
O repositório contém dois projetos Gradle separados e um único histórico Git. Os comandos de build devem ser executados dentro da pasta correspondente.
Abra desktop/ no IntelliJ IDEA como projeto Gradle. Para compilar e executar os testes:
cd desktop
./gradlew buildPara executar somente os testes do componente PCM:
./gradlew test --tests dev.orin.desktop.audio.PcmAudioOutputTestO programa de diagnóstico dev.orin.desktop.diagnostics.AudioOutputManualCheck pode ser executado pela ação Run no IntelliJ. Ele gera um tom senoidal de 440 Hz com duração de um segundo e amplitude reduzida. Comece com o volume do sistema baixo. O programa usa drain() para aguardar a reprodução antes de fechar a saída.
Para validar o pipeline em loopback, execute dev.orin.desktop.diagnostics.UdpAudioLoopbackCheck pela ação Run. Ele envia 300 quadros de 10 ms com um tom de 440 Hz e aguarda a reprodução, totalizando aproximadamente três segundos.
Também é possível executar dois processos Java independentes: inicie primeiro dev.orin.desktop.diagnostics.UdpAudioReceiverCheck e aguarde a mensagem de recepção na porta 50000; depois execute dev.orin.desktop.diagnostics.UdpAudioSenderCheck. O emissor usa o endereço de loopback, portanto ambos devem rodar no mesmo computador. O receptor espera 300 quadros e possui timeout de 30 segundos por recepção. Esses diagnósticos requerem uma saída de áudio disponível e foram validados manualmente no Linux.
DesktopAudioPipeline.receiveAndPlayNext() processa um datagrama por chamada e propaga erros de recepção, decodificação ou reprodução. Após tratar um pacote inválido, o chamador pode tentar a próxima chamada. Os diagnósticos atuais encerram ao encontrar um erro; não implementam recuperação automática, controle de sessão, reordenação ou compensação de perda.
A aplicação desktop ainda não possui um fluxo completo de conexão ou uma interface final para utilização como microfone.
Abra android/ no Android Studio, instale o SDK correspondente e execute no dispositivo desejado. Para compilar o APK de depuração e executar os testes unitários disponíveis:
cd android
./gradlew :app:assembleDebug :app:testDebugUnitTestO projeto Android ainda não implementa a captura nem a transmissão do microfone. Uma conexão USB pode ser usada para instalação e depuração pelo Android Studio; o transporte de áudio pretendido continua sendo o Wi-Fi.
O workflow em .github/workflows/ci.yml executa separadamente o build do desktop com JDK 25 e a compilação/testes do Android com JDK 17 e Android SDK. As dependências são acompanhadas pelo Dependabot.
O desktop tem Gradle Configuration Cache habilitado, atualmente configurado para reportar eventuais problemas de compatibilidade como avisos.
orin/
├── android/ # Aplicativo Android em Kotlin e Compose
├── desktop/ # Núcleo Java, áudio, rede e protocolo
├── docs/
│ ├── architecture.md # Visão arquitetural e integração com os sistemas
│ ├── protocol.md # Formato experimental dos pacotes e comunicação
│ └── roadmap.md # Fases e critérios de conclusão
├── .github/
│ ├── workflows/ci.yml # Build e testes dos dois projetos
│ └── dependabot.yml # Atualização de dependências
├── .editorconfig
├── .gitattributes
├── .gitignore
└── README.md
A primeira versão realmente utilizável do Orin deverá permitir usar a voz capturada no Android como microfone no Linux, em aplicações como Discord e navegador, com latência adequada para conversas.
Para isso, ainda será necessário capturar e transmitir áudio no Android, criar a entrada virtual via PipeWire e implementar pareamento, autenticação e criptografia. Também serão necessários controles de início/parada, tratamento de desconexões e uma interface mínima.
O Windows será uma expansão posterior, aproveitando a mesma aplicação Android e a maior parte do receptor Java. A versão 1.0 pessoal tem como objetivo oferecer instalação e uso nos dois sistemas desktop.
O Orin foi projetado para operar na rede local, sem contas, serviços de nuvem ou telemetria. O áudio não deverá ser gravado durante o funcionamento normal; quaisquer arquivos ou tons de diagnóstico serão utilizados somente em testes explícitos.
Uma rede Wi-Fi local não torna o tráfego privado. Os testes experimentais sem criptografia devem ocorrer apenas em ambientes controlados. O Orin não está pronto para uso cotidiano com dados sensíveis enquanto não houver autenticação, integridade e criptografia do transporte.
O Orin não oferece hoje conexão automática entre dispositivos, microfone virtual ou gerenciamento completo de sessões. No Windows, poderá ser necessária a instalação independente de um dispositivo virtual de terceiros; não há driver próprio planejado para o MVP.
| Documento | Conteúdo |
|---|---|
| Arquitetura | Organização do sistema, responsabilidades e integração com Linux/Windows |
| Protocolo | PCM, cabeçalho experimental, validações, temporização e segurança |
| Roadmap | Etapas previstas e critérios para um protótipo e MVP úteis |
- Exercitar perda, reordenação e atraso de pacotes no pipeline experimental e definir o tratamento desses eventos antes da integração com o Android.
- Implementar captura com
AudioRecorde envio de quadros PCM no Android. - Ouvir no Linux o áudio capturado pelo celular por Wi-Fi.
- Integrar PipeWire para disponibilizar o áudio como microfone virtual.
- Medir e melhorar latência, estabilidade, segurança e experiência de conexão antes de considerar um MVP utilizável.
Descoberta automática, áudio via USB, Bluetooth, compressão com Opus, filtros avançados, vários transmissores e driver virtual próprio ficam fora do escopo inicial.