Re: [linux-audio-dev] questions to be resolved

[Paul Davis]

>"may" is a bit weak... you're assuming that audio thread does not have
>enough free time to change the graph. This is not sure.

Since there is no way to know how long it may take to change the
graph, the audio thread cannot know whether it will have time or
not. OK, we could put an upper bound of maybe a few 100ms on it, but
even that involves making some assumptions. And yes, in most cases,
its probably more like 10usec, but thats not relevant since we need a
guarantee. 

>I don't see why you want to enforce concurrency when it's not strictly
>needed and when this means to ask for troubles.

You *cannot* change the graph from the audio thread without risking an
xrun, which notably worse than simply doing nothing for one or two
engine cycles. So I don't want concurrency per se, just a mutex thats
used in a non-blocking way by the audio thread.

--p