<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style></style></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1>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.<o:p></o:p><o:p> </o:p>Here is a simple example:<o:p></o:p>First, here is an error-free pipeline:<o:p></o:p>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<o:p></o:p>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. <o:p></o:p><o:p> </o:p>Next, we change the format to S16LE, which the card does not accept:<o:p></o:p>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<o:p></o:p>The error produced is:<o:p></o:p>ERROR: from element /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0: Internal data stream error.<o:p></o:p>Additional debug info:<o:p></o:p>gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0:<o:p></o:p>streaming stopped, reason not-negotiated (-4)<o:p></o:p><o:p> </o:p>Note that the alsasink is not mentioned as part of the error, but rather it is the audiotestsrc. <o:p></o:p><o:p> </o:p>Inspection of the entire debug output for alsa related messages only shows:<o:p></o:p>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;<o:p></o:p><o:p> </o:p>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. <o:p></o:p><o:p> </o:p>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:<o:p></o:p>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<o:p></o:p>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.<o:p></o:p><o:p> </o:p>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. <o:p></o:p><o:p> </o:p>For example, from the command line I can run this command:<o:p></o:p>aplay -D hw:CARD=USB --dump-hw-params /dev/zero<o:p></o:p><o:p> </o:p>And get this very informative output:<o:p></o:p><o:p> </o:p>Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono<o:p></o:p>HW Params of device "hw:CARD=USB":<o:p></o:p>--------------------<o:p></o:p>ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED<o:p></o:p>FORMAT: S32_LE<o:p></o:p>SUBFORMAT: STD<o:p></o:p>SAMPLE_BITS: 32<o:p></o:p>FRAME_BITS: 192<o:p></o:p>CHANNELS: 6<o:p></o:p>RATE: [44100 192000]<o:p></o:p>PERIOD_TIME: [125 495352)<o:p></o:p>PERIOD_SIZE: [6 21845]<o:p></o:p>PERIOD_BYTES: [144 524280]<o:p></o:p>PERIODS: [2 1024]<o:p></o:p>BUFFER_TIME: (62 990703)<o:p></o:p>BUFFER_SIZE: [12 43690]<o:p></o:p>BUFFER_BYTES: [288 1048560]<o:p></o:p>TICK_TIME: ALL<o:p></o:p>--------------------<o:p></o:p>aplay: set_params:1368: Sample format non available<o:p></o:p>Available formats:<o:p></o:p>- S32_LE<o:p></o:p><o:p> </o:p>There is an analgous command for getting recording info:<o:p></o:p>arecord -D hw:CARD=USB --dump-hw-params /dev/null<o:p></o:p><o:p> </o:p>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. <o:p></o:p><o:p> </o:p><o:p> </o:p></div></body></html>