strange "no more pads available" error generated by a deinterleave element

Fri Jul 9 19:34:57 UTC 2021

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.

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.

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):

########### begin server side pipeline ###########

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

input.src_0 ! tee name=input_ch0
input.src_1 ! tee name=input_ch1

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

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

udpsrc port=32768 ! server_rtpbin.recv_rtcp_sink_0

input_ch0. ! queue ! client0_stream.sink_0
input_ch1. ! queue ! client0_stream.sink_1

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

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

udpsrc port=32769 ! server_rtpbin.recv_rtcp_sink_1

input_ch0. ! queue ! client1_stream.sink_0
input_ch1. ! queue ! client1_stream.sink_1

########### end server side pipeline ###########

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:

########### begin working client side pipeline ###########

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

audiointerleave name=output0 latency=100000000 ! queue ! alsasink
device='hw:CARD=sndrpihifiberry,DEV=0'

input.src_1 ! tee name=input_ch1
input.src_0 ! tee name=input_ch0

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

########### end working client side pipeline ###########

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):

########### begin non-working client side pipeline ###########

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

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'

input.src_1 ! tee name=input_ch1
input.src_0 ! tee name=input_ch0

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

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

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

########### end non-working client side pipeline ###########

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.

This is the debug output relevant to the error produced by the non-working
pipeline code:

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

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:

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.

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.

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