FEATURE REQUEST: better alsasink error reporting

[Nicolas Dufresne]

Le samedi 17 juillet 2021 à 17:16 -0400, Charlie Laub via gstreamer-devel a
écrit :
> 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. 

You can get a detailed report of negotiation issue by replacing gst-launch-1.0
with gst-validate-1.0 (make sure you have that installed first). Negotation
failure are not as simple as this thread seems to assume.

>  
> 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. 
>  
>  
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel