Qobuz no Linux

Também disponível em inglês: Qobuz on Linux.

No Android uso o app nativo do Qobuz e, volta e meia, o USB Audio Player PRO e o HiBy Music (bem raro mesmo - um teste que ficou instalado e uma wishlist dos devices deles), mas ambos logados na mesma conta Qobuz, cada um com seu equalizador e acesso direto ao DAC, contornando o mixer do Android. Escrevi sobre esse arranjo em Transformando antigo smartphone em DAP, e o resto do parque de equipamentos está em meu setup musical.

Uso tanto no celular de 2019 (material do artigo sobre transformando um celular em DAP dedicado), aposentado e sem SIM com o iFi Go Link, quanto no meu smartphone do dia-a-dia.

Para o meu laptop Thinkpad com Arch (Omarchy), outro PC com EndevourOS (Arch novamente) e um desktop com Fedora 44, 64 GB de RAM e uma interface SSL2+ entrega… só uma aba de navegador.

Isso incomoda mais do que deveria.

O Qobuz nunca lançou cliente oficial para Linux. Existem apps para Windows, macOS, Android, iOS, SmartTVs e integração com meia dúzia de fabricantes de hardware. Para Linux, existe o play.qobuz.com e a sua criatividade. Este artigo é sobre até onde a criatividade chega.

O problema não é (tanto) o Qobuz

Antes de comparar navegador vs Wine, vale alinhar o que está sendo medido. “Qualidade” aqui não é subjetivo: é o que sai do servidor, o que chega ao DAC e o quanto se perde no caminho, do Linux até os ouvidos.

Streaming em 24 bits / 192 kHz que passa por um resampler para 48 kHz continua sendo um arquivo de 192 kHz na origem, mas vira um sinal de 48 kHz no conversor. Paga-se o plano Studio para consumir banda e processamento, só.

Usar o Youtube Music (a pior qualidade), obviamente não adianta em nada ter equipamento ou configurações boas… Como também, ouvir via Spotify e não configurar para a melhor qualidade (“Very High” em “Audio Quality”), o ideal com o Qobuz é chegar perto da qualidade oferecida (e paga!) alinhando com os equipamentos disponíveis.

No Linux há três pontos onde a cadeia pode ser quebrada:

1. A aplicação, que pode decodificar e reamostrar por conta própria.
2. O servidor de som (PipeWire, ou PulseAudio em setups antigos), que roda numa taxa fixa e converte tudo que não bate.
3. O device ALSA escolhido, porque plughw: faz conversão silenciosa e hw: não faz.

Esses três pontos são do lado de cá, e todos têm solução. Mas seria desonesto parar por aqui e fingir que o Qobuz não tem culpa nenhuma: os três só viram problema meu porque não existe cliente oficial para Linux. Nas outras plataformas quem resolve isso é o app, que negocia a taxa com o sistema e entrega o stream ao hardware sem intermediário. No Linux esse trabalho foi terceirizado para o assinante, e o resto deste artigo é exatamente o custo dessa terceirização: camada de compatibilidade, credenciais de API extraídas de bundle JavaScript, clientes de terceiros mantidos por voluntários.

Não é falta de demanda nem limitação técnica, o próprio catálogo já é servido por HTTP para qualquer coisa que saiba pedir.

Opção 1: web player no navegador

O catálogo do Qobuz entrega FLAC de 16/44,1 a 24/192 conforme o plano, e o web player em play.qobuz.com acessa o mesmo catálogo. A limitação não está no que o servidor manda, está no que o navegador faz com o que recebe.

Navegadores roteiam áudio pela WebAudio API e pelo mixer do sistema, que opera numa taxa fixa, normalmente 48 kHz. Um FLAC de 192 kHz é decodificado corretamente e depois reamostrado para caber no grafo. Não existe modo exclusivo, não existe passthrough, não existe negociação de taxa por faixa. O próprio projeto QBZ, que é um cliente nativo alternativo, documenta isso na FAQ como a razão de existir.

E entre navegadores, muda alguma coisa?

Não.

Escolha o navegador por privacidade, consumo de RAM ou gosto pessoal. Para áudio, a diferença não existe, irrelevante e inútil.

Instalar o web player como PWA (Instalar página como aplicativo no Chromium) melhora a experiência, tira barra de endereço, ganha ícone e janela própria, integra MPRIS em alguns casos.

Repare no canto inferior direito: o indicador de qualidade é a única pista que o web player dá sobre o que está saindo. Ele descreve a faixa, não o que o DAC recebeu.

Como parar de discutir e medir

Toque uma faixa Hi-Res e pergunte ao kernel o que está realmente acontecendo:

# descubra o card do seu DAC
cat /proc/asound/cards

# com a faixa tocando, veja o que o hardware recebeu
cat /proc/asound/card*/pcm0p/sub0/hw_params

Saída típica com o navegador tocando um FLAC 24/96:

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 8192

rate: 48000 numa faixa de 96 kHz encerra o debate. Complementando:

pw-metadata -n settings | grep clock   # taxa e taxas permitidas do grafo
pw-top                                  # taxa por nó, em tempo real
wpctl status                            # dispositivos e nós ativos

Onde o navegador é uma escolha perfeitamente razoável: descobrir música, ler o editorial do Qobuz (que é bom), montar playlist, ouvir no notebook enquanto trabalha. CD quality reamostrado por um resampler decente continua soando muito acima de qualquer plataforma lossy. O web player só é ruim para audiófilo, não para ser humano - imperceptível caso não tenha deficiências no restante do setup.

Opção 2: o app do Windows via Wine, Bottles ou CrossOver

O instalador oficial é Electron. Ou seja: você vai rodar Chromium empacotado dentro de uma camada de compatibilidade, em cima do Linux, para escapar das limitações de áudio do Chromium. Irônico.

O que salva a manobra é que o app Windows fala WASAPI, incluindo modo exclusivo. E o Wine sabe mapear WASAPI para ALSA.

O caminho de menor esforço é o Bottles: criar uma garrafa do tipo Application, rodar o instalador, funcionar. Há relatos consistentes de sucesso com poucos cliques. O detalhe chato: o Bottles roda como Flatpak, e o sandbox complica o acesso direto ao ALSA. Você ganha o app, e perde exatamente o motivo de ter ido atrás do app.

Para bit-perfect de verdade, o material de referência é o Qobuz-wine-guide, que usa wine-staging com o backend de som configurado em ALSA (não PulseAudio), um launcher que opcionalmente sobe o app fora do PipeWire em modo exclusivo, e ajustes no servidor de som.

CrossOver é o mesmo Wine com suporte comercial e perfis prontos. Se você já paga, tente. Se não paga, não vai pagar por causa disso.

Medindo o app via CrossOver, sem WASAPI exclusivo

Instalei o app oficial (versão 8.2.0-b033, Electron) numa bottle do CrossOver e medi a cadeia inteira no Fedora 44 com PipeWire 1.6.8 e a SSL2+ Mk II. O resultado: não precisei de modo exclusivo nem do backend ALSA do Wine. O caminho padrão, winepulse.drv falando com o PipeWire, já entrega a taxa nativa da faixa ao hardware.

O selo Hi-Res 24-Bit 192 kHz ao lado do device SSL 2+ Mk II Line Output é o que o app afirma estar fazendo. O /proc abaixo é o que confirma.

O primeiro passo é confirmar que não existe DSP no caminho. O grafo precisa ir do app ao hardware em linha reta:

pw-dump | jq -r '.[] | select(.type=="PipeWire:Interface:Link") |
  "\(.info."output-node-id") -> \(.info."input-node-id")"'
pgrep -a easyeffects

No meu caso o caminho foi Qobuz (141) -> Line1 sink (64) -> split (63) -> alsa_output.hw_II_0 (59), sem nenhum nó Audio/Filter no meio. Os nós split são o UCM da SSL2+ separando Line 1/2 de Line 3/4, roteamento de canal, não processamento.

Depois, identifique o stream do app e veja em que formato ele sai do Wine:

pactl list sink-inputs | grep -EA2 'application.name = "Qobuz"'
pactl list sink-inputs | grep -E 'Sample Specification|Resample method|Volume:'

Com uma playlist de 24/96 tocando:

Sample Specification: float32le 2ch 96000Hz
Volume: front-left: 65536 / 100% / 0.00 dB

E o que interessa de verdade, o que o kernel entregou ao USB:

cat /proc/asound/card2/pcm0p/sub0/hw_params
grep -E 'Status|Momentary' /proc/asound/card2/stream0

format: S32_LE
rate: 96000 (96000/1)

  Status: Running
    Momentary freq = 96000 Hz (0xc.0000)

Trocando para uma playlist de 192 kHz e repetindo o mesmo comando, sem mexer em nada:

format: S32_LE
rate: 192000 (192000/1)
period_size: 512

    Momentary freq = 192000 Hz (0x18.0000)

Essa é a prova, e vale entender por que ela é conclusiva. Meu default.clock.rate é 48000. O hardware só sai desse valor se alguém pedir outra taxa e o grafo aceitar renegociar, o que só acontece porque default.clock.allowed-rates inclui 88200, 96000, 176400 e 192000. Se o Wine estivesse reamostrando para um mix format fixo, o hw_params ficaria cravado em 48000 independentemente da faixa. Ele acompanhou 96 e depois 192 kHz, então não há conversão de taxa em lugar nenhum da cadeia.

Para acompanhar a troca em tempo real ao pular entre faixas de taxas diferentes:

watch -n1 'grep rate /proc/asound/card2/pcm0p/sub0/hw_params'

Sobre profundidade de bits: o stream sai do Wine em float32, o PipeWire trafega em float32 e o ALSA entrega S32_LE. Com o volume em 100% / 0.00 dB no sink input, no sink (wpctl get-volume @DEFAULT_AUDIO_SINK@ retornando 1.00) e no próprio app, não há atenuação em ponto flutuante, e a conversão de 24 bits para float32 e de volta para S32_LE é exata. Formalmente isso não é bit-perfect no sentido estrito do modo exclusivo, já que o barramento é float. Na prática a mantissa de 24 bits do float32 carrega o conteúdo sem perda quando o ganho é unitário. Qualquer volume abaixo de 100% em qualquer um desses três pontos quebra o argumento.

Confira também a saúde do stream, porque taxa certa com xrun a cada dois segundos não é vitória:

pw-top -b -n 3
journalctl --user -u pipewire -u wireplumber --since "30 min ago" | grep -Ei 'xrun|underrun'

A coluna ERR do pw-top deve ficar em zero. No meu caso o driver rodou com WAIT 30.5us contra BUSY 4.6us num quantum de 512, folga confortável.

Um detalhe: o pactl list sinks reporta Sample Specification: float32le 2ch 48000Hz mesmo com o hardware em 192 kHz. Isso é a camada de compatibilidade PulseAudio mostrando o formato do grafo, não o do device. Ignore, e olhe o hw_params.

Vale registrar duas configurações da bottle que afetam o resultado. Em ~/.cxoffice/Qobuz_Installer/drive_c/users/crossover/AppData/Roaming/Qobuz/settings-*.json, o campo currentDevice estava vazio, ou seja, WASAPI compartilhado, nenhum device exclusivo selecionado. E downloadQuality estava em 7, que no esquema do Qobuz é o teto de 24/96 (o tier de 24/192 é o 27). Esse campo rege download e import, não streaming, mas se o app parecer preso em 96 kHz é o primeiro lugar para olhar.

Como bônus, o app oficial é o único caminho da lista que dá acesso ao download offline da assinatura, com o filtro Downloads only funcionando normalmente dentro da bottle.

Veredito: Sim, funciona! Rode o app oficial via Wine, e o caminho padrão via PipeWire já basta desde que allowed-rates esteja configurado. O malabarismo de wine-staging com backend ALSA e modo exclusivo resolve um problema que o PipeWire moderno já não tem.

Opção 3: Strawberry

O Strawberry é o player que já uso para a coleção local, é Qt, tem backend GStreamer com saída ALSA direta e traz suporte nativo ao Qobuz. É a opção mais elegante em teoria e a mais irritante de configurar na prática.

O motivo: o Qobuz não distribui credenciais de API para clientes de terceiros. Você precisa fornecer um App ID e um App Secret que o próprio web player usa, extraídos do bundle JavaScript.

Extraindo as credenciais

pipx install qobuz-dl

python - <<'EOF'
from qobuz_dl.bundle import Bundle
b = Bundle()
print("app_id:", b.get_app_id())
for k, v in b.get_secrets().items():
    print("secret:", k, v)
EOF

Saem um app_id e vários secrets. Não existe critério documentado para saber qual funciona, terá que testar um por um até achar o correto.

Configurando

Em Configurações > Qobuz:

• marque Enable Qobuz
• App ID e App Secret conforme extraídos
• usuário e senha da conta
• Preferred audio format: escolha o topo (24-bit / 192 kHz) e deixe o servidor negociar para baixo quando a faixa não tiver
• ajuste os limites de busca, o padrão é baixo e faz parecer que sua biblioteca sumiu

Em Configurações > Backend:

• Output: alsasink
• Device: o hw: do seu DAC, nunca plughw: (o plughw converte em silêncio, que é precisamente o que estamos tentando evitar)
• desative fading, replaygain e equalizador se o objetivo é bit-perfect

Com tudo no lugar, o Qobuz vira mais uma fonte na barra lateral, ao lado de Biblioteca, Arquivos e Rádios:

As colunas Sample Rate, Profundidade de bits e Fonte são o motivo de usar o Strawberry: 192000 Hz, 24 Bit, FLAC e Stream na mesma linha, sem precisar abrir o /proc.

O erro que você vai encontrar

Invalid Request Signature parameter (request_sig) (400)

Busca funciona, playback não. Significa que o secret escolhido não é aceito para assinar a requisição de stream. Volte, troque o secret, repita. Isso não é bug do Strawberry, a secret correta funcionará tudo ok.

Único ponto é que o Strawberry não busca playlists, mas resolvi isso com um script, baixando todas as minhas playlists no formato .xspf (talvez um segundo artigo somente com isso, mas já versionei no meu repo de dotfiles).

Opção 4: clientes alternativos e nativos

QBZ

O QBZ (https://qbz.lol/) é um cliente Qobuz nativo para Linux escrito em Rust, MIT, sem telemetria, e na versão 2.0 abandonou webview e IPC: processo único, UI em Slint. Backends PipeWire, ALSA (com modo Direct hw: de bypass), PulseAudio e JACK, com passthrough para o DAC e troca de sample rate por faixa, de 44,1 a 192 kHz. Tem também DSD com DoP e passthrough nativo, gapless, MPRIS, scrobbling para Last.fm e ListenBrainz, Chromecast e DLNA, e um assistente de configuração de hardware.

Instalação:

# Arch
yay -S qbz-bin

# Fedora / openSUSE (glibc 2.39+)
sudo dnf install ./qbz-*.rpm     # baixe o RPM em github.com/vicrodh/qbz/releases

# Flatpak
flatpak install flathub com.blitzfc.qbz

Aviso relevante: Não vai de Flatpak! - o sandbox dele limita a interação com o hardware.

O login é OAuth pelo navegador, sem senha digitada dentro do app, e existe o modo offline para quem só quer tocar a coleção local:

Depois do login a biblioteca inteira aparece, favoritos e playlists incluídos, com contadores por tipo:

A página de álbum traz uma coluna Quality por faixa, o que evita a surpresa de descobrir no meio da audição que aquele disco específico é só CD quality:

E tem o modo tela cheia, para quando o notebook vira aparelho de som:

Detalhe interessante para quem tem um Pi ou um mini-PC sobrando: o projeto embarca o qbzd, um daemon headless que transforma a máquina num endpoint Qobuz Connect, aparecendo nos apps oficiais como se fosse um streamer de hardware. Existe fork containerizado para quem prefere Docker ou LXC no Proxmox. Isso resolve o cenário “Qobuz Connect no Linux”.

Qobine, ex qobuz-player

SofusA/qobuz-player, agora é SofusA/qobine

Nasceu como fork do hifi.rs e divergiu bastante. Hoje é um monorepo em Rust, GPL-3.0, reunindo TUI, player GTK para GNOME, servidor web com UI própria, player RFID e Qobuz Connect experimental. Suporta até 24 bits / 192 kHz, MPRIS (controle via playerctl ou qualquer cliente D-Bus) e gapless.

O modo RFID é a parte divertida: aproxime um cartão, toca o álbum. Jukebox caseiro para quem sente falta de objeto físico e não quer voltar a limpar agulha de toca-discos. O hifi.rs original está parado desde 2024.

Opção 5: tratar o Qobuz como fonte de rede

Lyrion Music Server + squeezelite

O antigo Logitech Media Server virou Lyrion. O servidor roda em Docker, o squeezelite roda no host que tem o DAC e fala ALSA direto, com suporte a 44,1 até 384 kHz e sincronismo multiroom.

docker run -d --name lyrion \
  -p 9000:9000 -p 3483:3483 -p 3483:3483/udp \
  -v lms-config:/config -v /srv/musica:/music \
  lmscommunity/lyrionmusicserver:latest

# no host com o DAC
sudo dnf install squeezelite
squeezelite -l                          # lista os devices
squeezelite -o hw:2,0 -n "sala-fedora"

Depois, em Settings > Plugins, instale o plugin do Qobuz e faça login.

upmpdcli

Renderer UPnP baseado em MPD, com módulo de media server para Qobuz. É a rota certa para quem controla tudo via BubbleUPnP.

Music Assistant

Se você já roda Home Assistant, o Music Assistant tem provider de Qobuz com o catálogo Hi-Res, seleciona automaticamente a melhor qualidade disponível e sincroniza favoritos nos dois sentidos. Toca em Chromecast, Sonos, AirPlay e afins.

E o equalizador?

No Android eu tenho EQ dentro do próprio player, sem sair da cadeia de bits, porque o UAPP e o HiBy processam antes de entregar ao DAC. No Linux o caminho é o EasyEffects sobre PipeWire, que aceita perfis do AutoEQ para IEMs e headphones conhecidos.

EQ é processamento e o processamento acontece em float, que exige conversão. Não uso e nem sinto falta fora do smartphone.

Comparativo

O que eu uso

Desktop Fedora 44 com KDE, saída pela SSL2+ ou pelo TOSlink para o Edifier. Strawberry.

Notebook Arch com Hyprland, DAC Fosi K5 Pro: Strawberry.

PWA no Navegador (Brave), para navegar na interface, descobrir álbuns e playlists, ler o editorial… Sem culpa, e sem fingir que é audiófilo.

Em todos os casos acima, consigo controlar o player pelo celular com o KDE Connect ou pelo app nativo (atualmente estou usando o Qobuz Beta).

O instalador falhou ao tentar rodar via Wine, porém, instalou tranquilamente no CrossOver, logo não tentei resolver nem fazer um tshot para instalar no wine (até porque, não quero usar nesse formato)… O QBZ é excelente, uma alternativa ótima entre Strawberry e o PWA.

Ah, estou lá no Qobuz Club https://club.qobuz.com/u/7ee25f7b

E minhas playlists são publicas por lá também.

Referências

• QBZ e FAQ do projeto
• Qobine, ex qobuz-player
• Qobuz-wine-guide
• Strawberry Music Player
• Lyrion Music Server e squeezelite
• upmpdcli
• Music Assistant, provider Qobuz
• Bugzilla 1400731, sample rate no Firefox