Maybe queueing a new read after a sample is filtered isn't ideal, thinning is meant to reduce latency, if there's a high load on the queue this could delay things significantly, I believe?
Well, perhaps but I don't see why it should be treated differently from a missed read, which might need to try reading again to satisfy a given stream. Also, all the media source commands (including reads [^1]) are executed on the global shared callback queue, and they should not stall the queue for an unbounded period of time.
It might be better to separate the addition of the DEFINE_MF_ASYNC_PARAMS helper from the "Process SetRate asynchronously" commit.
Sure, split it to a separate change.
[^1]: Actual stream reads should probably use the IO queues but it's probably a trickier design change.