ALSA warnings when running audiodevinfo.cc tests

I see warnings like

ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
Expression 'alsa_snd_pcm_hw_params_set_buffer_size_near( pcm, hwParams, &alsaBufferFrames )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 923
Expression 'alsa_snd_pcm_hw_params_set_buffer_size_near( pcm, hwParams, &alsaBufferFrames )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 923
Expression 'alsa_snd_pcm_hw_params_set_buffer_size_near( pcm, hwParams, &alsaBufferFrames )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 923
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_a52.c:823:(_snd_pcm_a52_open) a52 is only for playback
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card

when the test suite processes audiodevinfo.cc-tst. Is it just me? Do they indicate actual problems that I should fix? If not, is there anything we can do to suppress these warnings?

I’ve seen warnings like those since the audio functions were first added. Here’s mine

ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_a52.c:823:(_snd_pcm_a52_open) a52 is only for playback
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock

I really don’t know if anything can be done, the PortAudio library is an abstraction for all of these other sound libraries, and it blindly tries to probe all of them, spewing warnings and errors like these until it finds a library that can connect to audio devices.

I looked at this a bit more and there seems to be a method in place for capturing these messages:

Here, userCB is a function pointer that can be set with a call to PaUtil_SetDebugPrintFunction. But a declaration for that function is not present in the installed portaudio.h header file. And although the function is present in libportaudio.a on my system, it is not exported from libportaudio.so so audiodevinfo.oct can’t access it even if I work around the declaration problem.

This is not only Octave, see e.g. this post. FWIW, the sounddevice python library decided to redirect stderr while using portaudio.

We could also silence warnings using ALSA library directly (since this is in fact a linux only issue), but this doesn’t look worth the trouble, and adds platform specific code, precisely what PortAudio is meant to avoid.

Aside from platform-specific, we also want the benefit that PortAudio gives GNU/Linux users the option of JACK and PulseAudio before falling back to ALSA (even though PulseAudio may in turn be using ALSA, or vice versa ALSA itself may be configured to use Pulse).

I’m fine with continuing to use PortAudio. It would be nice to be able to do that in some way other than temporarily redirecting stderr, but if there is no other way, we can just do that.

It may be off-topic, but:

On Fedora 34-beta PortAudio has been replaced by PipeWire (as default audio server).
The libraries are still there, i can compile and run “test audiodevinfo”, but then i get SIGSEGV in Qthread at exit. I will post a bug report.

Dmitri.

See also this open issue: application level debug output · Issue #423 · PortAudio/portaudio · GitHub

It would also be great if the typedef and function declaration were in a public header file, but having the symbol exported would be sufficient to allow this feature to work. Thanks.

I assume this was inspired by my recent suppression of the error messages from the QHull library.

changeset:   29517:78ccd8bf439c
user:        Rik <rik@octave.org>
date:        Fri Apr 09 06:38:21 2021 -0700
summary:     Suppress extraneous error messages from Qhull (bug #57727).

QHull was nice in that it internally uses a pointer to FILE for normal output and for error output. And then the library lets you pass in whatever you want as the pointer and it will just use that for all operations. Normally, these would be set to stdout and stderr respectively. In Octave, I diverted the error pointer to /dev/null to silence the warnings.

It is a small thing, but if we could fix this it would be nice. Users may over-react to messages during make check and assume that something is wrong, even if the test is reported as passing. Better to just silence these and not confuse anyone.