On 09/18/2007 03:57 AM, Rene Herman wrote:

> Oh. This discrepency is caused by the fact that I work against the 
> kernel and only check ALSA HG every once in a while. Too infrequently it 
> seems as the _interruptible was recently (and yes, wrongly) removed from 
> ALSA:
> 
> http://hg.alsa-project.org/alsa-kernel/rev/1768363a5f1e
> 
> It's still there in 2.6.22.x which I run. The setup has been changed 
> around in the meantime again anyway in this case but I guess I'll make a 
> point of working against HG more directly.

And here's the others in that changeset, against current hg. As far as I'm 
aware, the only purpose of the _interruptible versions is bailing out when 
signal_pending(current) and if we're simply looping around without checking 
anyway, they might as well be schedule_timeout_uninterruptible(), also known 
as msleep().

Given that delaying for a jiffy generally doesn't make a great deal of sense 
given variable frequency, they might actually want to be msleep(1) directly 
but I didn't do that.

This also adds a barrier() to one of the /core/seq/seq_instr.c ones which as 
far as I can see is needed to keep the compiler from optimising the check 
away. For the other instances there, the spin_lock functions serve as a 
barrier already I believe but please check me on that -- I'm inexperienced 
at that level.

The wavefront_synth one was strange. It was originally (when still using 
_interruptible) in the absence of signals basically just doing a single:

	msleep(jiffies_to_msecs(timeout));

with the dev->irq_ok check only happening when woken up by a signal which I 
assume was not so much intended. This now just does a sleeping loop.

Otherwise,

Signed-off-by: Rene Herman <rene.herman@gmail.com>