3

I have a modern PC running Fedora 24 with a real-time patch (CCRMA audio tools) with an ASUS Essence STX II sterio sound card installed on PCIe. With it we run a playback/capture application. Also, we need to integrate CAN (Controller Area Network) and BLE (Bluetooth Low Energy) into the system and have a PCIe-card for each of these functions. The CAN PCIe card is from PEAK (PCAN-PCI Express 2-ch) and the BLE card is an Intel 8260 M2 card that HP have put on a PCIe card (AFAIK).

With only the audio card installed it works fine (using ALSA as API). When the CAN and BLE is installed the following is observed:

  • Playback works as before.
  • One capture channel only returns zero (0) or minus one (-1) in all samples.
  • The other capture channel returns values in the range -2..2 (expected -100..100) and when applying our application signal processing low quality, but detectable, expected results are presented.
  • The ALSA API report no problems in setup and configuration.
  • CAN and BLE functions as expected.

Without any deeper PCIe experience I suspect that CAN and/or BLE PCIe cards jumble the mapping of the sound card functions. I see before me some hands on setup scripting to untangle the cards but have no (!) idea where to begin.

Can someone:

  • Tell me if my hunch is in the ballpark?
  • Inform me on where I might go for information on how to rectify the problem?
  • ...or, share your solution to a similar problem?

Thanks!

UPDATE

arecord -l gives the same report for all card combinations (audio card only, BLE + audio and CAN + BLE + audio).

dmesg does not shout odd, but I'm not qualified to tell.

From lspci -vv, with all three card installed, I have

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

from all entries that claim to be PCI bridges. I interpret that to be a structure where the main (00) bus have four sub-busses (01-04) and that sub-bus 04 have another sub-bus attached (bus 05).

The audio card has BDF 05:04.0 and use IRQ 16, that propagates through the 00-04-05 bridge, 04:00.0. Now, there is a "SMBus" device at 00:1f.4 also using IRQ 16. That device is also present with only the audio card installed (when the audio works as expected), then also using IRQ 16. The fourth (!) user of IRQ 16 is the PEAK CAN network controller, at 01:00.0. All other devices listed has unique IRQ numbers.

I'm learning by the minute but cannot decide if non-unique IRQs are a problem. Is it a problem? Are there better/other information in lspci that I should look at?

  • 1
    PCIe regions shouldn't jumble each others mappings; the configuration process should guarantee that this doesn't happen. If capture works at all it's also unlikely the PCIe communication is broken in some way, this produces much more serious errors. First step to check stuff is to look at lspci -vv for the mappings, and go through dmesg from beginning to end after boot to see if there's something odd. – dirkt Jan 24 '18 at 19:40
  • can you provide a link to the specs for the CAN and BLE cards? or at least a brief description of what they are, those acronyms have many meanings - I presume CAN doesn't mean "Car Area Network". Do either of them provide any sort of analog input, that might present as some kind of sound card's input? If so, that may be shifting the capture channel numbers for your actual sound card. – cas Jan 25 '18 at 0:07
  • 1
    try running arecord -l with only the sound card installed, and then again with either or both of the other cards installed. – cas Jan 25 '18 at 0:09
  • @cas Updated with some clarifications. Sound card is analog in- and output, CAN is also analog in/out but is not operating when problems manifest. The CAN card is accessed using SocketCAN, – peso Jan 25 '18 at 8:43
  • 1
    did you try running arecord -l? i have no specific knowledge about that CAN card but if the system is registering it as some kind of audio in device then it does not matter if it is being actively used at the same time as the sound card's analog input or not - it will still be assigned an input channel number, and that may shift the input device number assigned to the sound card. i.e. examine the output of arecord -l and reconfigure your signal processing software to use the new correct input device if required. – cas Jan 25 '18 at 10:03
2

We've solved it! It seems that us inserting other PCI card affected the mixer in the ALSA driver, diverting the capture to the motherboard built-in sound function's front mic. On top of that the volume for that mic was set to 0. That works with the diagnostics we've seen (single channel capture with very low signal levels). We had missed to properly set up the ALSA configuration, allowing it to be controlled by other processes. One possible culprit could have been the pulseaudio process that allow remote audio control.

The mixer settings, as well as a most comprehensive set of information on all current audio settings can be found using alsa-info.sh where we found the discrepancies affecting our application.

We have now made shure we do explicit setup of the ALSA driver's configuration of all audio functions and verified functionallity on all PCI card. This link show how to save mixer settings and we also set up audio drivers explicitly via an /etc/modprobe.d/alsa.conf configuration file.

Whooho!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.