Stderr flooded with debugging messages

[uti5]

Is there a way to use portaudio in a command-line program without getting stderr flooded with debugging messages?

[RossBencina]

There are multiple ways:

1. Make sure that PA_ENABLE_DEBUG_OUTPUT is not defined when you build PortAudio.
   or
2. Redirect error logging by registering a callback with PaUtil_SetDebugPrintFunction see padebugprint.h

[uti5]

Doesn't (1) correspond to ./configure --enable-debug-output=no,
which is the default? As for (2), the user doesn't seem to have
access to that function.

To be specific, my problem is that, even with the above configure
option, just

#include <portaudio.h>

int main()
{
	Pa_Initialize();
	Pa_Terminate();
}

prints this

ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(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
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

to stderr.

[RossBencina]

Those messages are not generated by PortAudio. You would need to work out how to make ALSA and JACK be quiet -- for example by fixing the configuration issues that result in those errors.

[RossBencina]

Seems like a duplicate of this: #555

[uti5]

I thought it was the role of portaudio to talk to alsa and jack for the user? (In case you meant to dismiss this as not a portaudio issue.) It seems that there is an alsa ``debug'' option that can be set to 0, but I'm having a hard time figuring out how.

[RossBencina]

I thought it was the role of portaudio to talk to alsa and jack for the user?

As far as I understand, the error messages arise because ALSA is misconfigured (i.e. your system-level ALSA config files are borked). PortAudio does not take responsibility at that level.

If you think that PortAudio could somehow do something better in this situation, please could you explain.

[uti5]

Would it be possible to add an option to redirect these warnings away
from stderr, and, if necessary, everything printed to stderr while
Portaudio does the things that would trigger them?

If ALSA is misconfigured, it is so on both Void Linux and Kubuntu (and
probably Ubuntu and other distributions). And I suppose Jack must be
misconfigured too.

[fredvs]

@uti5 : If you want a fast-clean solution for your C applications: #555 (comment)
and for your Pascal applications: fredvs/uos#33 (comment)

[RossBencina]

First, please keep in mind that although I am a maintainer of PortAudio I do not generally work with ALSA or Linux. We have a lack of contributors in this area, which is why I am responding.

Regarding the ALSA messages there's some discussion here:

https://stackoverflow.com/questions/31603555/unknown-pcm-cards-pcm-rear-pyaudio
https://stackoverflow.com/questions/7088672/pyaudio-working-but-spits-out-error-messages-each-time

Which mentions the ALSA function snd_lib_error_set_handler, documented here:
https://www.alsa-project.org/alsa-doc/alsa-lib/group___error.html#gae71d39953bf482ba487d811a69a9175c

So you could try using that function in your own code and see whether it works.

Just thinking out loud here: PortAudio could do one of:

1. Keep current behavior (i.e. use the default ALSA behavior of printing errors to stderr)
2. Suppress all ALSA errors using snd_lib_error_set_handler
3. Provide an ALSA-specific API that maps to snd_lib_error_set_handler somehow

The problem with (2) is that perhaps some errors should not be suppressed. How do we know which? Perhaps when PA_ENABLE_DEBUG_OUTPUT is not defined PortAudio should suppress all ALSA output.

For (3) I'm not sure what advantage there is vs. user directly calling snd_lib_error_set_handler. Perhaps there could be some kind of PaAlsa_Enable/DisableErrorPrinting type thing.

[fredvs]

Many thanks for this.

I will deeply study it ( even that I am happy with redirecting the error messages to a log file, as I do for the moment ).

Fre;D

[Chum4k3r]

Just to contribute with the thread, as an user, I prefer (3) over (2). PortAudio already provide an API for special audio host configurations, such as channel mapping for ASIO, exclusive mode for WASAPI, and latency configs for ALSA, so configure warnings wouldn't be an outlier. As regarding (2), it would be somewhat of a regression. PA used to suppress the warnings, and for reasons already said by Ross, the lib abdicated this behaviour. Since Explicit is better than Implicit, being able to suppress the warnigs from an explicit API seems a better option. As for PA provide such API, would be a useful convenience, which I am favorable, rather than a necessity. Hope this contribute for the evolving of this solution Em seg, 14 de nov de 2022 19:22, Fred vS ***@***.***> escreveu:

…

Many thanks for this. I will deeply study it ( even that I am happy with redirecting the error messages to a log file, as I do for the moment ). Fre;D — Reply to this email directly, view it on GitHub <#739 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJPYUKGYDNCTCGYT2LY2BHLWIK3QVANCNFSM6AAAAAARHJSWJ4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RossBencina]

@Chum4k3r thanks for the feedback, I think you've made a good argument that (3) is a reasonable approach.

If someone would like to make a patch we can review it. In the mean time, as a work around, clients can call snd_lib_error_set_handler directly.

Not sure what we can do about the JACK messages.