I just had a revelation while sitting on the can: the generation of the “I need another source because this one is empty” event happens in the wrong place. The MultiSource will of course detect the end almost immediately after a source file is decoded which can happen in just a few seconds (even if your MP3 file yields seven minutes worth of music) so obviously (obviously!) it should not send the event; instead the final sink of the pipeline should tell somebody that the source of the pipeline needs new data. Now I only need to figure out which sink I should listen to in case I have several sinks in a pipeline (e.g. one for a streaming server, one for local audio output).
Great, I’m back at the initial problem: the beginning of the pipeline needs to know when the end of the pipeline has processed all the data that the beginning of the pipeline has produced. Unfortunately, with external decoders, that is not done easily or reliably. At least I can not think of a way that does not involve “waiting until x ms have gone by without getting data.”
Turns out I had not really introduced a bug. It was all the fault of the predicate filter which — with the new approach of how to create pipelines with changing formats — can simply be thrown out.
I made good on what I said yesterday: I scrapped all those fancy interfaces that I had and merged them all into Filter. The resulting simplification of some parts of the code was noticable, the commit added 681 lines but removed 906.
Apparently the real problem is to get the metadata of a filter’s input to the output generated by that exact input. So by some magical means I have to wait for a filter plugin to have generated all data that it will generate for the input it has been fed, and we’re potentially talking about dozens of milliseconds! This is an outrage!