Olá @Ranke
Lembro de dialogar contigo tentando entender o problema também.
Vendo aqui o post chamou-me atenção a questão do relacionar o controle de conexão e gerenciamento do USB ao Pipewire.
Considerando o funcionamento padrão e até o manual do Pipewire não é função dele realizar tal coisa. O controle de conexão USB e portanto a convenção de padrão de banda fica por cargo do Kernel e nesse caso junto ao driver snd-usb-audio. Esse driver por padrão, sim, verifica estabilidade e jitter a ponto de forçar um dispositivo baixar a banda saindo de um padrão usb 2.0 para padrão usb 1.0 a fim de manter estabilidade. Similar ao padrão de rede que quando percebe muito ruído baixa banda para manter estabilidade.
Agora, é bem curioso que ao trocar o sistema de áudio para o Pulse tenha dado certo. Penso que seja uma questão colateral na stack que atua junto ao Pipewire que esteja induzindo a esse erro, não o Pipewire em si. Ainda que o Pipewire faça controle de banda do áudio como um fluxo de dados podendo aumentar ou reduzir de acordo com o bit depth e sample rate ele não muda a conexão “física” que foi negociada pelo Kernel, Alsa ou driver de som USB. Por isso ainda creio que seja “configuração de arquivo” e o Pipewire possui várias camadas de arquivos de configuração devido à grande complexidade de controles de nós, mixer, plugins tantas outras coisas que o Pulse já não tem inclusive a correlação com controle de sessão wireplumber e a parte de vídeo que também possui no Pipewire. E as configurações nesses arquivos podem induzir o Pipewire a comportar ou requisitar algo que conflita com os outros drivers fazendo a parte de captação do áudio não funcionar.
Na documentação de desenvolvimento do PipeWire, confirma que ele é Class Compliant, ou seja segue os padrões definidos pelos drivers Kernel/ALSA que incluem o UAC1 (que é o padrão de áudio nativo para USB 1.1). No caso o Pipewire vai manter a tratativa com o periférico como um dispositivo ALSA. Inclusive em fóruns já li músicos confirmarem trabalhar com USB1.1 no Pipewire. Então o fato, no seu caso, se houve limitação da conexão do MIC a USB 1.1 o Pipewire em si conseguiria trabalhar, mas alguma outra config dos arquivos no conjunto da pilha de áudio deve induzir ao erro que acontecia ai. Afirmando conforme documentação do Pipewire que ele usa a referência do ALSA e as especificações de SPA **(**usando o módulo spa.alsa) para criar e gerenciar os nós.
Bom, a intuito da conversa é clarificar sobre se o problema é ou não do Pipewire em si. Uma pena não ter o conjunto aqui para testar e saber mais a fundo, rs. Mesmo porque, como falamos na época, os relatos similares apontam para inconsistências mais ligadas aos drivers e as controladoras antigas nas placas mães de gerações passadas frente ao USB. Tanto que um colega até aqui do fórum arrumou o problema dele só trocando a controladora do USB e com isso o Kernel Linux carregou uma parte do driver em versão mais recente para conexão USB3 e funcionou o mic Fifine com Pipewire normal. Aliás tem outras pessoas que usam o mesmo mic Fifine A6V em Linux e Pipewire e funciona normal ( Reddit - Please wait for verification ).
Resumindo, o ponto que a base do erro seja porque o Pulse por padrão trabalha com perfil de requisito menor, normalmente 16bit/44.1KHZ, mas o Pipewire por padrão tem nos arquivos de config “vindo de fábrica” para atuar com 32bit float e 48KHZ e isso é um limite superior quando o driver USB se limita ao USB1.1 (12Mbits). Por isso o mic é reconhecido, ele enxerga o device, mas não deixa gravar porque o Pipewire foi induzido pelas configs a criar um nó em requsito de tráfego maior que a banda do USB1.1.
Ah, outra coisa que vale a pena checar na sua afirmação é que o Gnome em si tem requisito de dependência o Pipewire. Talvez isso seja mais uma questão de meta pacote e config da distro do que o Gnome em si, será? Vale a pesquisa para tirar a dúvida. Mas isso deixo pra outro momento.
De qualquer forma, que bom resolveu ai!
#sucesso
Edit: olhando rapidamente a questão de dependência do Gnome-Pipewire tornou algo essencial pela parte de vídeo/portals (levianamente falando). parece que tem como manter a stack pipewire de boas no Gnome e mudar o padrão de sound server para o usar o do pulseaudio mascarando o a funcionalidade do pipewire audio.