strange "no more pads available" error generated by a deinterleave element
Charlie Laub
charleslaub at sbcglobal.net
Sat Jul 10 17:25:18 UTC 2021
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.
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)1,
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'
audiointerleave name=output1 latency=100000000 ! queue ! alsasink
device='hw:CARD=Audio,DEV=0'
input.src_0 ! tee name=input_ch0
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
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
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
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
.
From: gstreamer-devel <gstreamer-devel-bounces at 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 at lists.freedesktop.org>
Cc: Charlie Laub <charleslaub at sbcglobal.net>
Subject: strange "no more pads available" error generated by a deinterleave
element
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/20210710/61a512dc/attachment-0001.htm>
More information about the gstreamer-devel
mailing list