<div dir="ltr">In a playing pipeline, when a new input is requested and linked to audiointerleave, using getRequest Pad("sink%u").link(...), a corruption of memory happens, that finally produces the crash of the program.<br><br>The sequence is the following:<br>1) assume initially audiointerleave has 1 sink pad, is playing, output buffers are being sent.<br>2) Second sink pad is requested, audiointerleave increases (gst_audiointerleave_request_new_pad) the number of channels to provide at output. Caps for srcpad are updated and audio info is replaced in "srcpad->info".<br>3) gst_audiointerleave_aggreagate_one_buffer is called with arguments outbuf (a buffer allocated when there are only one sink, before update of srcpad->info) and out_offset (offset in frame units). This offset is converted to bytes in statements:<br><div><br></div><div><span style="font-family:monospace"> out_bpf = GST_AUDIO_INFO_BPF (&srcpad->info);</span></div><div><span style="font-family:monospace"> outdata = outmap.data + (out_offset * out_bpf) + (out_width * channel);</span></div><div><br></div>however, out_bpf is now the size of one frame with two channels. That gives and offset greater than the correct one. Moreover, a count of channels is used to copy data from incoming to outgoing buffer. Again, this number of channels is the new one (2) instead of the one when buffer was allocated (1).  In conclusion, a data copy starting at bad (bigger than correct) offset and with bad (bigger than correct) length, causing the memory corruption.<br><br>A workaround is, in function "gst_audiointerleave_request_new_pad", discard the current buffer, adding the statements:<br>  GstAggregator *agg = GST_AGGREGATOR (self);<br>  GstAggregatorClass *klass = GST_AGGREGATOR_GET_CLASS (agg);<br>  klass->flush( agg );<br><br>My question is: how a new input can be added to audiomixer? Must I use a probe in the new pad to inject/wait some events? Or there are an error in the implementation of this element ?</div>