xournalpp outputs spurious ALSA lib warning messages in the terminal:

ALSA lib pcm.c:2675:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2675:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2675:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_a52.c:1001:(_snd_pcm_a52_open) a52 is only for playback
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'

As a graphic application, xournalpp should output almost nothing in
the terminal. Such messages are very annoying as they take valuable
space in the terminal.

It's great that people are using Xournal++, and care enough about it
to be bothered by this!

These are coming from libsndfile1. Many Linux GUI programs do output a
constant stream of harmless warnings, and Xournal++ is hardly the
worst offender. The "right" fix is presumably to tell libsndfile1 (the
calls are sf_xxx()) to try other sound systems first, like pipewire or
pulse, before going to devices. Or maybe there's a way to tell it to
be less verbose. Perhaps libsndfile1 has build options that would
avoid this by trying things in a different order, or tell it to be
less verbose. Anyway, patches welcome, at least to Xournal++.

If it really bugs you, as a workaround I'd suggest redirecting
standard error to a log file, maybe via a pipe that removes the
annoying ALSA stuff.

Cheers,

FYI, I've been using Xournal (xournal package) until now, which
doesn't have this issue. But I suppose that xournal will be removed
from Debian as it uses GTK 2 and seems unmaintained upstream
(probably replaced by Xournal++).

This occurred often in the past, but I don't see that often now
(at least for the non-GNOME applications).

On the libsndfile1 side, I think that libraries shouldn't output
any warning/error message in general, except for fatal error
messages. The API should handle errors. Debugging messages may
be useful, but should never be output by default.

FYI, other applications like audacity also use the libsndfile
library, but have no such issues with it. Or does Xournal++ do
something that is really wrong?

I've seen that Xournal++ outputs other useless messages such as

(com.github.xournalpp.xournalpp:49547): xopp-WARNING **: 12:19:13.627: lastOpenPath is not set!

This is completely useless for the end user. Since Xournal++
seems to show errors in dialog boxes instead of the terminal
(not every GUI app does that), a solution could be to redirect
stderr to /dev/null on its side by default (some option could
be added to leave stderr as is, e.g. for debugging).

The only useful error message for the terminal could be the
"cannot open display" one. Fortunately, it occurs before any
spurious warning message:

zira:~> env -u DISPLAY /usr/bin/xournalpp

(com.github.xournalpp.xournalpp:49538): Gtk-WARNING **: 12:19:05.448: cannot open display:

So it might be possible to redirect stderr after that.

In the mean time, in case other users are potentially interested,
I've done the following:

#!/bin/sh
set -e
xrandr > /dev/null
/usr/bin/xournalpp "$@" 2> /dev/null

(the xrandr is useful to get the "cannot open display" error,
assuming that --display=DISPLAY xournalpp option is not used,
but I'm wondering whether any user uses this option).

Well that seems a bit drastic! You don't want to lose *all* the error messages.
I was thinking something which leaves stdout alone and just filters
out annoying stderr lines.
Like this:

#!/usr/bin/bash
set -e
xournalpp "$@" 2> >(egrep -v '^ALSA lib .*snd_')

For further clarification I discussed this issue with claude.ai and here's
what seems to be going on. It's not related to libsndfile, it's actually
PortAudio's fault.

*Issue:*

The device enumeration produces spurious ALSA error messages to stderr
during application startup, despite audio working correctly. These errors
are cosmetic but pollute stderr output, making it difficult to identify
actual problems.

*Root Cause:*

Xournalpp links against PortAudio, which enumerates all ALSA PCM devices at
initialization via snd_device_name_hint() or similar discovery APIs. ALSA's
default configuration files (e.g., /usr/share/alsa/alsa.conf) define
references to numerous hardware PCM devices (surround configurations, HDMI,
modem, phoneline, etc.) regardless of whether the hardware exists. When
PortAudio probes these devices, ALSA attempts to open each one, generating
error messages to stderr for every non-existent device.

all contain "ALSA lib". For instance:

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

Guessing what to filter out in a robust way is intractable.

Control: reassign -1 libportaudio2 19.7.0-1
Control: retitle -1 libportaudio2: should discard error messages from alsa-lib by setting a dummy error handler
Control: affects -1 xournalpp

I agree that this is PortAudio's fault (though I think that
alsa-lib's default for errors is a poor choice). See below
what should be done to fix the issue in PortAudio (not tested).
So, reassigning the bug to libportaudio2.

[...]
in alsa-lib:

/**
 * \brief The default log handler function.
[...]
 * If a local error function has been installed for the current thread by
 * \ref snd_lib_log_set_local, it is called. Otherwise, prints the error
 * message including location to \c stderr.
 */
static void snd_lib_vlog_default(int prio, int interface, const char *file, int line, const char *function, int errcode, const char *fmt, va_list arg)
[...]

I think that sending messages to stderr by default is a poor choice.
So the software using alsa-lib (here, the PortAudio library) should
define either its own log handler function or its own error handler
function, since the default error handler function is what triggers
the log by calling snd_lib_vlog.

/**
 * \brief Sets the error handler.
[...]
 * This function sets a new error handler, or (if \c handler is \c NULL)
 * the default one which prints the error messages to \c stderr.
 */
int snd_lib_error_set_handler(snd_lib_error_handler_t handler)
{
        snd_lib_error = handler == NULL ? snd_lib_error_default : handler;
        return 0;
}

In the PortAudio source, I can see in src/hostapi/alsa/pa_linux_alsa.c:

PaError PaAlsa_Initialize( PaUtilHostApiRepresentation **hostApi, PaHostApiIndex
 hostApiIndex )
{
[...]
    /*ENSURE_( snd_lib_error_set_handler(AlsaErrorHandler), paUnanticipatedHostError );*/
[...]
}

and

static void Terminate( struct PaUtilHostApiRepresentation *hostApi )
{
[...]
    /*snd_lib_error_set_handler(NULL);*/
[...]
}

So it seems that the intent was to set an error handler, but this has
been commented out, together with

/** Uncommented because AlsaErrorHandler is unused for anything good yet. If AlsaErrorHandler is
    to be used, do not forget to register this callback in PaAlsa_Initialize, and unregister in Terminate.
*/
/*static void AlsaErrorHandler(const char *file, int line, const char *function, int err, const char *fmt, ...)
{
}*/

This explanation is actually wrong: AlsaErrorHandler should be
used to discard the error messages (sent to stderr by default)
since PortAudio does not seem to want to handle them.

There are actually several open issues on this subject,
the main ones (still open) being

  • https://github.com/PortAudio/portaudio/issues/163
    ALSA printing undesirable warnings to console
    (AlsaErrorHandler needs work?)
  • https://github.com/PortAudio/portaudio/issues/739
    Stderr flooded with debugging messages

(these are actually errors that are ignored by PortAudio,
not debug info, which is not enabled in Debian).

The underlying problem here is that system components (in this case
some sound library) should not be playing "Wheel of Fortune" to figure
out what hardware is available. "Can I have an R? Can I have a B?"
That's what the config file is doing. But if it *does* play that game,
"sorry no S" should not be an error; at most it should be an
info-level log message. But it shouldn't be playing that game at all:
a central database of available hardware should just list the
appropriate available devices. This is how block devices work, with
/dev/block/ and /dev/disk/by-*/. There are a variety of system
components in a good position to handle this.

But however this is managed, it is crazy for the caller of the sound
library to have to worry it. This is exactly the sort of low-level
concern that the sound library should be shielding the caller from.

The presence of hardware is often dynamic. So probing the hardware
is useful in practice.

Assuming that PortAudio uses the ALSA library correctly, I agree. But
this should not even be info-level log at all (I certainly do not want
such messages each time I start a PortAudio-based application).

Here, I have only one known sound card:

qaa:~> cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0x6189290000 irq 218

So I'm wondering why I get all these error messages with PortAudio.

BTW, aplay does not give me any error:

qaa:~> aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC289 Analog [ALC289 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Is there some ALSA utility that would reproduce the errors as
obtained with PortAudio?

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.