FEATURE REQUEST: better alsasink error reporting

[Charlie Laub]

I can construct a simple pipeline that sends audio data to an alsasink with
an incorrect format, causing the pipeline to fail to launch. Instead of
reporting an error about the alsasink, a message is generated about some
element further up towards the pipeline source. These gives the user no
hints regarding the source of the problem, which lies with the alsasink
properties. So I am asking the developers for improvement in alsasink error
reporting.

 

Here is a simple example:

First, here is an error-free pipeline:

gst-launch-1.0 -vm  audiotestsrc ! audioconvert !
audio/x-raw,format=S32LE,channels=6,rate=48000 ! volume volume=0.01 !
alsasink device=hw:CARD=USB,DEV=0

The soundcard can accept only 6 channels of audio at S32LE (it's a pro audio
card), and at a variety of rates including 48kHz. 

 

Next, we change the format to S16LE, which the card does not accept:

gst-launch-1.0 -vm  audiotestsrc ! audioconvert !
audio/x-raw,format=S16LE,channels=6,rate=48000 ! volume volume=0.01 !
alsasink device=hw:CARD=USB,DEV=0

The error produced is:

ERROR: from element /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0:
Internal data stream error.

Additional debug info:

gstbasesrc.c(3072): gst_base_src_loop ():
/GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0:

streaming stopped, reason not-negotiated (-4)

 

Note that the alsasink is not mentioned as part of the error, but rather it
is the audiotestsrc. 

 

Inspection of the entire debug output for alsa related messages only shows:

Got message #15 from element "alsasink0" (state-changed):
GstMessageStateChanged, old-state=(GstState)GST_STATE_NULL,
new-state=(GstState)GST_STATE_READY,
pending-state=(GstState)GST_STATE_VOID_PENDING;

 

Any non-supported format will cause an error to be reported for an upstream
element (in this case the pipeline source) and never for the alsasink. This
is not very helpful. 

 

Recently I posted about a more complicated pipeline that was experiencing an
error. The pipeline actions involved receiving an RTP stream, deinterleaving
the audio, teeing, processing via LADSPA, interleaving, and sinking to two
different alsasinks. The reported error was:

Got message #401 from element "input" (warning): GstMessageWarning,
gerror=(GError)NULL, debug=(string)"./grammar.y(510):\
gst_parse_no_more_pads\ ():\
/GstPipeline:pipeline0/GstDeinterleave:input:\01$ WARNING: from element
/GstPipeline:pipeline0/GstDeinterleave:input: Delayed linking failed.
Additional debug info: ./grammar.y(510): gst_parse_no_more_pads ():
/GstPipeline:pipeline0/GstDeinterleave:input: failed delayed linking pad
src_0 of GstDeinterleave named input to some pad of GstTee named input_ch0

In that case, the error was being reported for a mid-pipeline element, a
deinterleave element named "input". The actual source for the error was a
simple mistake in choosing the audio format for the alsasink. Once that was
rectified, the pipeline ran error-free, as intended.

 

I would like to ask the developers to improve error checking and reporting
for alsasink. Likely the same issue may exist for alsasrc as well. It should
be trivial to do a check for support of rate, format, channel count, etc.
and then reporting the error as an alsa related one. 

 

For example, from the command line I can run this command:

aplay -D hw:CARD=USB --dump-hw-params /dev/zero

 

And get this very informative output:

 

Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono

HW Params of device "hw:CARD=USB":

--------------------

ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED

FORMAT:  S32_LE

SUBFORMAT:  STD

SAMPLE_BITS: 32

FRAME_BITS: 192

CHANNELS: 6

RATE: [44100 192000]

PERIOD_TIME: [125 495352)

PERIOD_SIZE: [6 21845]

PERIOD_BYTES: [144 524280]

PERIODS: [2 1024]

BUFFER_TIME: (62 990703)

BUFFER_SIZE: [12 43690]

BUFFER_BYTES: [288 1048560]

TICK_TIME: ALL

--------------------

aplay: set_params:1368: Sample format non available

Available formats:

- S32_LE

 

There is an analgous command for getting recording info:

arecord -D hw:CARD=USB --dump-hw-params /dev/null

 

The code to generate the supported configurations for any ALSA device is
already written as part of ALSA, and it could be adapted for use within
Gstreamer to check on and report ALSA errors. 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210717/fc0a6385/attachment-0001.htm>