<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>Below is another example of this problem. It’s basically the same client pipeline, except I only am sending one audio channel via RTP. This generates the same gst_parse_no_more_pads error from deinterleave element. I can’t understand what is causing this error, since there is only one element (a tee) connected to the deinterleave. One difference between the version of this pipeline that runs successfully and this one that generates an error is the presence of a second audiosink, however, I don’t’ see why that would cause any problems. I typically do not use more than one audiosink on a client so I have not encountered this particular problem before now.<o:p></o:p><o:p> </o:p>rtpbin name=client_rtpbin ntp-time-source=ntp ntp-sync=true latency=60 rtp-profile=avpf buffer-mode=synced <o:p></o:p><o:p> </o:p>udpsrc port=32768 caps='application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)L16, channels=(int)1, payload=(int)96' ! client_rtpbin.recv_rtp_sink_0 <o:p></o:p>client_rtpbin. ! rtpL16depay ! audioconvert ! audio/x-raw,format=F32LE ! deinterleave name=input <o:p></o:p>udpsrc port=32769 ! client_rtpbin.recv_rtcp_sink_0 <o:p></o:p>client_rtpbin.send_rtcp_src_0 ! udpsink host=192.168.1.201 port=32769 sync=false async=false <o:p></o:p><o:p> </o:p>audiointerleave name=output0 latency=100000000 ! queue ! alsasink device='hw:CARD=sndrpihifiberry,DEV=0' <o:p></o:p>audiointerleave name=output1 latency=100000000 ! queue ! alsasink device='hw:CARD=Audio,DEV=0' <o:p></o:p><o:p> </o:p>input.src_0 ! tee name=input_ch0 <o:p></o:p><o:p> </o:p>input_ch0. ! queue ! ladspa-acdf-so-acdf type=26 db=-5 fp=950 qp=1.3 ! ladspa-acdf-so-acdf type=28 fp=1200 qp=0.5 fz=1800 qz=0.5 ! ladspa-acdf-so-acdf type=5 db=-4 fp=6000 ! tee name=right <o:p></o:p><o:p> </o:p>right. ! queue ! ladspa-acdf-so-acdf type=22 db=-1 fp=2700 qp=0.6 ! ladspa-acdf-so-acdf type=22 fp=2700 qp=0.71 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x1' ! output0.sink_0 <o:p></o:p>right. ! queue ! ladspa-acdf-so-acdf type=21 fp=2200 qp=0.71 ! ladspa-acdf-so-acdf type=21 fp=2200 qp=0.71 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x2' ! output0.sink_1 <o:p></o:p><o:p> </o:p>input_ch0. ! queue ! ladspa-acdf-so-acdf type=28 db=-3 fz=38 qz=0.42 fp=27 qp=0.8 ! ladspa-acdf-so-acdf type=21 fp=120 qp=0.71 ! ladspa-acdf-so-acdf type=21 fp=120 qp=0.71 ! tee name=sub <o:p></o:p><o:p> </o:p>sub. ! queue ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x1' ! output1.sink_0 <o:p></o:p>sub. ! queue ! ladspa-acdf-so-acdf type=0 polarity=-1 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x2' ! output1.sink_1<o:p></o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p>.<o:p></o:p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'>From: gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> On Behalf Of Charlie Laub via gstreamer-devel Sent: Friday, July 9, 2021 3:35 PM To: 'Discussion of the development of and with GStreamer' <gstreamer-devel@lists.freedesktop.org> Cc: Charlie Laub <charleslaub@sbcglobal.net> Subject: strange "no more pads available" error generated by a deinterleave element<o:p></o:p></div></div><o:p> </o:p>I wrote an application for gst-launch-1.0 (version 14.x) that generates gstreamer code and executes it on machines on my LAN so that I can send and process audio data within my home, sort of like a distributed home audio system with DSP that uses a server/client model.<o:p></o:p>Recently I decided to implement an additional sink on a client computer. When I attempted to run the audio stream, no sound was produced and some debugging discovered a warning/error message regarding a deinterleave element.<o:p></o:p>My server pipeline sends 2 channels of audio to one or more clients using RTP (as part of RTPbin). The pipeline code on the server side looks like this (carriage returns added for readability):<o:p></o:p>########### begin server side pipeline ###########<o:p></o:p>rtpbin name=server_rtpbin ntp-time-source=ntp ntp-sync=true rtp-profile=avpf alsasrc device='dsnoop:CARD=Loopback,DEV=1' provide-clock=false ! audio/x-raw,rate=48000,format=S32LE,channels=2 ! queue ! audioconvert ! audio/x-raw,format=F32LE ! deinterleave name=input<o:p></o:p>input.src_0 ! tee name=input_ch0 input.src_1 ! tee name=input_ch1<o:p></o:p>audiointerleave name=client0_stream latency=100000000 ! audioconvert ! audioresample quality=10 ! audio/x-raw,rate=48000,format=S16LE ! audioconvert ! rtpL16pay ! server_rtpbin.send_rtp_sink_0<o:p></o:p>server_rtpbin.send_rtp_src_0 ! udpsink host=192.168.1.233 port=32768 server_rtpbin.send_rtcp_src_0 ! udpsink host=192.168.1.233 port=32769 sync=false async=false<o:p></o:p>udpsrc port=32768 ! server_rtpbin.recv_rtcp_sink_0<o:p></o:p>input_ch0. ! queue ! client0_stream.sink_0 input_ch1. ! queue ! client0_stream.sink_1<o:p></o:p>audiointerleave name=client1_stream latency=100000000 ! audioconvert ! audioresample quality=10 ! audio/x-raw,rate=48000,format=S16LE ! audioconvert ! rtpL16pay ! server_rtpbin.send_rtp_sink_1<o:p></o:p>server_rtpbin.send_rtp_src_1 ! udpsink host=192.168.1.234 port=32768 server_rtpbin.send_rtcp_src_1 ! udpsink host=192.168.1.234 port=32769 sync=false async=false<o:p></o:p>udpsrc port=32769 ! server_rtpbin.recv_rtcp_sink_1<o:p></o:p>input_ch0. ! queue ! client1_stream.sink_0 input_ch1. ! queue ! client1_stream.sink_1<o:p></o:p>########### end server side pipeline ###########<o:p></o:p>Each client pipeline receives the 2-channel audio stream, de-interleaves it, and then each channel is teed so that any number of connections can be connected to it. Audio is processed using LADSPA (DSP processing) and sent to one or more sinks. To illustrate, here is the code when only the onboard DAC is being used. This gstreamer code runs perfectly, produces audio, and does not generate any errors:<o:p></o:p>########### begin working client side pipeline ###########<o:p></o:p>rtpbin name=client_rtpbin ntp-time-source=ntp ntp-sync=true latency=60 rtp-profile=avpf buffer-mode=synced udpsrc port=32768 caps='application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)L16, channels=(int)2, payload=(int)96' ! client_rtpbin.recv_rtp_sink_0 client_rtpbin. ! rtpL16depay ! audioconvert ! audio/x-raw,format=F32LE ! deinterleave name=input udpsrc port=32769 ! client_rtpbin.recv_rtcp_sink_0 client_rtpbin.send_rtcp_src_0 ! udpsink host=192.168.1.201 port=32769 sync=false async=false<o:p></o:p>audiointerleave name=output0 latency=100000000 ! queue ! alsasink device='hw:CARD=sndrpihifiberry,DEV=0'<o:p></o:p>input.src_1 ! tee name=input_ch1 input.src_0 ! tee name=input_ch0<o:p></o:p>input_ch1. ! queue ! ladspa-acdf-so-acdf type=26 db=-5 fp=950 qp=1.3 ! ladspa-acdf-so-acdf type=28 fp=1200 qp=0.5 fz=1800 qz=0.5 ! ladspa-acdf-so-acdf type=5 db=-4 fp=6000 ! tee name=right right. ! queue ! ladspa-acdf-so-acdf type=22 db=-1 fp=2700 qp=0.6 ! ladspa-acdf-so-acdf type=22 fp=2700 qp=0.71 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x1' ! output0.sink_0 right. ! queue ! ladspa-acdf-so-acdf type=21 fp=2200 qp=0.71 ! ladspa-acdf-so-acdf type=21 fp=2200 qp=0.71 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x2' ! output0.sink_1<o:p></o:p>########### end working client side pipeline ###########<o:p></o:p>The problem appears when I add a second sink to each client and configure the pipeline to send audio to it. This generates errors and does not produce audio (debug info is found below the pipeline code):<o:p></o:p>########### begin non-working client side pipeline ###########<o:p></o:p>rtpbin name=client_rtpbin ntp-time-source=ntp ntp-sync=true latency=60 rtp-profile=avpf buffer-mode=synced udpsrc port=32768 caps='application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)L16, channels=(int)2, payload=(int)96' ! client_rtpbinrecv_rtp_sink_0 client_rtpbin. ! rtpL16depay ! audioconvert ! audio/x-raw,format=F32LE ! deinterleave name=input udpsrc port=32769 ! client_rtpbin.recv_rtcp_sink_0 client_rtpbin.send_rtcp_src_0 ! udpsink host=192.168.1.201 port=32769 sync=false async=false<o:p></o:p>audiointerleave name=output0 latency=100000000 ! queue ! alsasink device='hw:CARD=sndrpihifiberry,DEV=0' audiointerleave name=output1 latency=100000000 ! queue ! alsasink device='hw:CARD=Audio,DEV=0'<o:p></o:p>input.src_1 ! tee name=input_ch1 input.src_0 ! tee name=input_ch0<o:p></o:p>input_ch1. ! queue ! ladspa-acdf-so-acdf type=26 db=-5 fp=950 qp=1.3 ! ladspa-acdf-so-acdf type=28 fp=1200 qp=0.5 fz=1800 qz=05 ! ladspa-acdf-so-acdf type=5 db=-4 fp=6000 ! tee name=right<o:p></o:p>right. ! queue ! ladspa-acdf-so-acdf type=22 db=-1 fp=2700 qp=0.6 ! ladspa-acdf-so-acdf type=22 fp=2700 qp=071 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x1' ! output0.sink_0 right. ! queue ! ladspa-acdf-so-acdf type=21 fp=2200 qp=0.71 ! ladspa-acdf-so-acdf type=21 fp=2200 qp=0.71 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x2' ! output0.sink_1<o:p></o:p>input_ch1. ! queue ! ladspa-acdf-so-acdf type=28 db=-3 fz=38 qz=0.42 fp=27 qp=0.8 ! ladspa-acdf-so-acdf type=21 fp=120 qp=0.71 ! ladspa-acdf-so-acdf type=21 fp=120 qp=0.71 ! tee name=sub sub. ! queue ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x1' ! output1.sink_0 sub. ! queue ! ladspa-acdf-so-acdf type=0 polarity=-1 ! audioconvert ! 'audio/x-raw,format=S32LE,channel-mask=(bitmask)0x2' ! output1.sink_1<o:p></o:p>########### end non-working client side pipeline ###########<o:p></o:p>The only difference between these two pipelines is in the last approximately 7 lines of code, starting with "input_ch1.", which is a teed input.<o:p></o:p>This is the debug output relevant to the error produced by the non-working pipeline code:<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>The above error seems to be generated between the deinterleave element named "input" and the tees named input_ch0 and input_ch1, which are only found on these two lines:<o:p></o:p>input.src_1 ! tee name=input_ch1 input.src_0 ! tee name=input_ch0 These two lines are simply connecting the deinterleaved channels received from the RTP depayloader to tees named using the convention "input_ch' plus an integer for the channel number. There is only ONE connection between deinterleave and tee for each channel, so I do not understand why an error saying there are no more available pads is generated. Only one pad is needed or used! So something seems wrong here. Maybe its a bug, so I am posting this here for help/comments, etc.<o:p></o:p>Additionally, I use the same type of pipeine in which a deinterleave is connected to tees, as part of my server pipeline, and in the example I am using each tee twice. No problems there, and that how a tee should work. So why not on the clients? All machines are running gstreamer 14.4. The server is an Intel box and both clients are Raspberry Pi 4.<o:p></o:p><o:p> </o:p></div></body></html>