Arch Linux

Los Frijoles

Member

Registered: 2012-06-23

Posts: 40

What causes pulseaudio's "failed to find a working profile" error?

I'm currently developing some USB hardware for my own personal hobby use (It is planned to be OSHW, but since it's not presentable yet I haven't yet posted it). I've built a USB device and I'm trying to make it accept/generate MIDI commands.

My main device configuration descriptor defines the device as both an HID (as a vendor-defined device) and Audio device. My log tells me that although my HID descriptor is good and working, something could be wrong with my audio descriptor or maybe my Arch configuration (I'm not sure, that's why I'm asking):

Aug 16 22:42:41 my-desktop kernel: usb 4-1.4.3: new full-speed USB device number 40 using ehci-pci
Aug 16 22:42:41 my-desktop kernel: usb 4-1.4.3: New USB device found, idVendor=16c0, idProduct=05dc, bcdDevice= 0.10
Aug 16 22:42:41 my-desktop kernel: usb 4-1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Aug 16 22:42:41 my-desktop kernel: usb 4-1.4.3: Product: MyDevice
Aug 16 22:42:41 my-desktop kernel: usb 4-1.4.3: Manufacturer: MyWebsite
Aug 16 22:42:41 my-desktop kernel: hid-generic 0003:16C0:05DC.0031: hiddev3,hidraw5: USB HID v1.11 Device [MyWebsite MyDevice] on usb-0000:00:1d.0-1.4.3/input0
Aug 16 22:42:41 my-desktop mtp-probe[15877]: checking bus 4, device 40: "/sys/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4.3"
Aug 16 22:42:41 my-desktop mtp-probe[15877]: bus: 4, device: 40 was not an MTP device
Aug 16 22:42:41 my-desktop systemd-udevd[15874]: Process '/usr/bin/alsactl restore 3' failed with exit code 99.
Aug 16 22:42:41 my-desktop pulseaudio[1399]: E: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
Aug 16 22:42:41 my-desktop pulseaudio[1399]: E: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="3" name="usb-MyWebsite_MyDevice-01" card_name="alsa_card.usb-MyWebsite_MyDevice-01" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.

Wireshark tells me that the host requests my device descriptor, followed by my two string descriptors, followed by the configuration descriptor. Eventually it asks for my HID Report descriptor and runs the SET_CONFIGURATION and SET_IDLE commands, but that's where it stops. It doesn't try to do any Audio-specific requests (not that they would work...I haven't implemented them yet). Beyond Wireshark, I do not have a USB Protocol Analyzer I could use for personal use.

Normally I would just read the source of module-alsa-card.c (and I may end up needing to) to see where this error is generated, but I'm wondering if anyone here could enumerate to my the reasons why "Failed to find a working profile" might appear?

Audio in general works just fine on my machine, which I lasted updated a week or so ago. The sound card is whatever comes with an ASRock Z68 Pro3-M motherboard, but that really shouldn't have a bearing on my custom device working. In general, my luck with audio on Arch has been somewhat hit-and-miss and my skills configuring it properly in weird situations are not exactly the sharpest. I did not do anything to my audio configuration in preparation for this since my Yamaha synthesizer attaches up just fine to the computer over USB without anything special.

I realize this is a very esoteric question and the likelihood of getting an answer is quite low. If there is some config file or something I can provide, please let me know. I can even post my USB configuration descriptor if that helps.

Last edited by Los Frijoles (2018-08-17 04:09:48)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,237

Re: What causes pulseaudio's "failed to find a working profile" error?

Pulseaudio - by default - queries the PCMs exposed by ALSA and generates logical profiles for these. If you run

aplay -L

your "working" card should be exposing PCMs for different channel counts and configurations, e.g. on my USB headset ALSA will expose

front:CARD=Headset,DEV=0
    KAVE XTD Headset, USB Audio
    Front speakers
surround21:CARD=Headset,DEV=0
    KAVE XTD Headset, USB Audio
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Headset,DEV=0
    KAVE XTD Headset, USB Audio
    4.0 Surround output to Front and Rear speakers
surround41:CARD=Headset,DEV=0
    KAVE XTD Headset, USB Audio
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Headset,DEV=0
    KAVE XTD Headset, USB Audio
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Headset,DEV=0
    KAVE XTD Headset, USB Audio
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Headset,DEV=0
    KAVE XTD Headset, USB Audio
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers

pulseaudio will use these and generate a different pulseaudio profile for each of those, so you can switch between the different channel counts as wanted (which will in turn trigger a few additional things such as upmixing stereo sources if configured so that you get something out of all 5.1 channels, or muting disabled sources etc.) since these are missing it cannot create a default profile. Should you, for some reason, use different identifiers than the example I used (but from what I gather you don't expect this to be working in any way yet anyway) you can create device specific profile definitions and tell pulseaudio to use those instead via a DBUS rule. All of these mappings, and the default config I mentioned are defined within pulseaudio profile-sets that you can find at /usr/share/pulseaudio/alsa-mixer/profile-sets/ here the default.conf is what creates aforementioned default mappings and that file also includes some comments as to how the logic works exactly.

Los Frijoles

Member

Registered: 2012-06-23

Posts: 40

Re: What causes pulseaudio's "failed to find a working profile" error?

I ran aplay -L and I found that it is actually adding something for my device! I think I know why the error message is showing up in my log: My descriptor doesn't actually declare any actual audio interfaces, only the midistreaming interface. So, it seems nothing is wrong.

Running "aseqdump" and selecting my device causes wireshark to show that my device is sending midi events to the host (though aseqdump itself doesn't show anything happenning...gotta figure that one out).

This is so exciting. Thanks!