On reflection, this is not really an issue. The streaming code selects on the "pipeline_reader" socket, effectively the output of the pipeline (which makes sense), not the source, as I had thought. Having another select for the source may slightly speed things up at the start but will not really make much difference. The streaming code does not rely on the select - it just uses it as an optimization, and still polls every 400ms.

The concern that triode had, that the streaming code would not retry fast enough to keep the player fed when transcoding to PCM (WAV) because of small pipe buffers, is not valid because this is resolved by selecting the pipe.