[1.5.0.1] JACK devices/ports with regex special characters in their name not usable

[gyroplast]

Running chuck --probe on my Linux/JACK system with pipewire(-jack) backend and chuck 1.5.0.1 fails to find my perfectly fine default mainboard stereo audio device of my laptop named Alder Lake PCH-P High Definition Audio Controller Speaker + Headphones by default.

:exclamation: This should also affect pure JACK backends, not pipewire only.

Note the missing info block for audio device 3 in the probe, where the error message RtApiJack::getDeviceInfo: error determining Jack input/output channels! is printed instead of device info:

[gyroplast@vixen chuck-src]$ chuck --probe
[chuck]: [Jack] driver found 6 audio device(s)...
[chuck]: 
[chuck]: ------( audio device: 1 )---------------
[chuck]: device name = "Alder Lake PCH-P High Definition Audio Controller Headphones Stereo Microphone"
[chuck]: probe [success] ...
[chuck]: # output channels = 0
[chuck]: # input channels  = 2
[chuck]: # duplex Channels = 0
[chuck]: default output = NO
[chuck]: default input = YES
[chuck]: natively supported data formats:
[chuck]:   32-bit float
[chuck]: supported sample rates:
[chuck]:   48000 Hz
[chuck]: 
[chuck]: ------( audio device: 2 )---------------
[chuck]: device name = "Alder Lake PCH-P High Definition Audio Controller Digital Microphone"
[chuck]: probe [success] ...
[chuck]: # output channels = 0
[chuck]: # input channels  = 2
[chuck]: # duplex Channels = 0
[chuck]: default output = NO
[chuck]: default input = NO
[chuck]: natively supported data formats:
[chuck]:   32-bit float
[chuck]: supported sample rates:
[chuck]:   48000 Hz
[chuck]: 
[chuck]: RtApiJack::getDeviceInfo: error determining Jack input/output channels!
[chuck]: 
[chuck]: ------( audio device: 4 )---------------
[chuck]: device name = "Alder Lake PCH-P High Definition Audio Controller HDMI / DisplayPort 1 Output"
[chuck]: probe [success] ...
[chuck]: # output channels = 2
[chuck]: # input channels  = 2
[chuck]: # duplex Channels = 2
[chuck]: default output = NO
[chuck]: default input = NO
[chuck]: natively supported data formats:
[chuck]:   32-bit float
[chuck]: supported sample rates:
[chuck]:   48000 Hz
...

Forcing chuck to use device 3 as dac fails similarly, it's not only a probing issue. By default, chuck grabs one of the HDMI outputs instead, simply skipping the unprobable device. Sucks if that device is the one you want to use, though.

gyroplast@vixen chuck-src]$ chuck --dac3 --shell
[chuck]: RtApiJack::getDeviceInfo: error determining Jack input/output channels!
[chuck]: RtApiJack::probeDeviceOpen: requested number of channels (2) + offset (0) not found for specified device (2:Alder Lake PCH-P High Definition Audio Controller Speaker + Headphones).

:exclamation: Good news, though: I found the issue and I'll provide a fix.

The issue is caused by using the retrieved port's name verbatim in jack_get_ports() as the port_name_pattern argument, which takes regular expression pattern to match a port's name, not a literal name string. This is surely flexible and generally nice to have, but will have unintended effects if the name includes regex meta characters, like the + sign in my case. Unfortunately, the regex pattern including Speaker + Headphones will not match the literal string Speaker + Headphones, JACK doesn't return any ports matching this name, thusly doesn't get any inputs/outputs to enumerate, and (correctly) infers that this device is somewhat broken.

The JACK API reference and the respective sources for JACK and pipewire-jack all corroborate this behavior as working as intended and documented. That arguments expects a regex pattern, not a literal 1:1 string to match.

One instance of this problem in chuck sources: https://github.com/ccrma/chuck/blob/d97b6176110ea285e3622a49261e9947daf11c26/src/host/RtAudio/RtAudio.cpp#L2193

As a workaround, I verified that renaming the audio device to a node.description containing only sane, non-special characters works just fine down the road with chuck.

[gewang]

thank you @gyroplast https://github.com/ccrma/chuck/commit/1906677ad95cf33ceb98342b8c3f5ee0f79384a3 addresses this issue, thanks to you