As placas PCIe interferem na função umas das outras

3

Eu tenho um PC moderno rodando o Fedora 24 com um patch em tempo real (ferramentas de áudio CCRMA) com uma placa de som sterius ASUS Essence STX II instalada no PCIe. Com ele, executamos um aplicativo de reprodução / captura. Além disso, precisamos integrar o CAN (Controller Area Network) e o BLE (Bluetooth Low Energy) ao sistema e ter uma placa PCIe para cada uma dessas funções. A placa CAN PCIe é da PEAK (PCAN-PCI Express 2-ch) e a placa BLE é uma placa Intel 8260 M2 que a HP colocou em uma placa PCIe (AFAIK).

Com apenas a placa de áudio instalada, ela funciona bem (usando o ALSA como API). Quando o CAN e o BLE estão instalados, observa-se o seguinte:

  • A reprodução funciona como antes.
  • Um canal de captura só retorna zero (0) ou menos um (-1) em todas as amostras.
  • O outro canal de captura retorna valores no intervalo -2..2 (esperado -100..100) e ao aplicar o processamento do sinal do nosso aplicativo de baixa qualidade, mas os resultados esperados detectáveis são apresentados.
  • O relatório da API da ALSA não apresenta problemas na configuração e configuração.
  • As funções CAN e BLE são esperadas.

Sem qualquer experiência PCIe mais profunda, suspeito que as placas PCIe CAN e / ou BLE desorganizem o mapeamento das funções da placa de som. Eu vejo diante de mim algumas mãos no script de configuração para desvendar as cartas, mas não tenho (!) Idéia por onde começar.

Alguém pode:

  • Diga-me se meu palpite está no estádio?
  • Informe-me onde posso procurar informações sobre como corrigir o problema?
  • ... ou compartilhe sua solução com um problema semelhante?

Obrigado!

UPDATE

arecord -l fornece o mesmo relatório para todas as combinações de cartões (somente placa de áudio, BLE + áudio e CAN + BLE + áudio).

dmesg não parece estranho, mas não estou qualificado para contar.

De lspci -vv , com todas as três placas instaladas, tenho

Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
Bus: primary=00, secondary=04, subordinate=05, sec-latency=0
Bus: primary=04, secondary=05, subordinate=05, sec-latency=0

de todas as entradas que reivindicam ser pontes PCI. Eu interpreto isso como uma estrutura onde o barramento principal (00) tem quatro sub-busses (01-04) e que o sub-bus 04 tem outro sub-bus conectado (bus 05).

A placa de áudio tem BDF 05: 04.0 e usa IRQ 16, que se propaga através da ponte 00-04-05, 04: 00.0. Agora, há um dispositivo "SMBus" em 00: 1f.4 também usando o IRQ 16. Esse dispositivo também está presente somente com a placa de áudio instalada (quando o áudio funciona como esperado), em seguida, também usando IRQ 16. O quarto (! ) usuário do IRQ 16 é o controlador de rede PEAK CAN, à 01: 00.0. Todos os outros dispositivos listados possuem números de IRQ exclusivos.

Estou aprendendo a cada minuto, mas não consigo decidir se IRQs não exclusivos são um problema. Isso é um problema? Há melhor / outras informações em lspci que eu deveria olhar?

    
por peso 24.01.2018 / 17:10

1 resposta

3

Nós resolvemos isso! Parece que a inserção de outra placa PCI afetou o mixer no driver ALSA, desviando a captura para o microfone frontal da função de som da placa-mãe. Além disso, o volume daquele microfone foi ajustado para 0. Isso funciona com os diagnósticos que vimos (captura de canal único com níveis de sinal muito baixos). Nós perdemos a configuração adequada da configuração do ALSA, permitindo que ela fosse controlada por outros processos. Um possível culpado poderia ter sido o processo pulseaudio que permite o controle remoto de áudio.

As configurações do mixer, bem como um conjunto de informações mais abrangente em todas as configurações atuais de áudio podem ser encontradas usando alsa-info.sh onde encontramos as discrepâncias que afetam nosso aplicativo.

Nós agora fizemos a configuração explícita da configuração do driver ALSA das todas funções de áudio e verificamos a funcionalidade em todas as placas PCI. Este link mostra como salvar as configurações do mixer e também configuramos os drivers de áudio explicitamente por meio de um /etc/modprobe.d/alsa.conf arquivo de configuração.

Whooho!

    
por 31.01.2018 / 11:28