That's clear.
> which gives no more capabilities to a normal user process than they can
> currently get on SCHED_NORMAL tasks. Audio will definitely get priority...
If you mean it will get a quick boost when it needs it, the trouble is, audio 
doesn't need that just sometimes, it needs it all the time.  Hence, the 
tweaks you're doing are fundamentally unable to deliver the kind of audio 
reliablity we'd like to become used to.  That's not to denigrate the value of 
your approach: it does seem to produce good effects in terms of interactive 
response, but it's not a cure-all.
> along with any other interactive task, but not in a real time fashion.
> Basically they effectively get a nice -5 unless they do the wrong thing.
Yes, I noticed pretty quickly that if I wanted to get rid of the audio 
glitches by renicing, I had to use nice -5 or lower.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/