[EMAIL PROTECTED] said:
> > The sound card allows itself to be unloaded when the pass-through
> > mixer levels are non-zero. This is reasonable iff ...
> I don't think that is reasonable.
You don't think that it's reasonable for the sound card to allow itself to
be unloaded when the pass-through mixer levels are non-zero?
So you're suggesting that we should prevent the sound drivers from being
unloaded at all in that situation?
That would also solve the problem, at the cost of still keeping the sound
module in unpagable RAM all the time.
[EMAIL PROTECTED] said:
> The first thing most drivers do is reset the hardware. That
> inevitably leads to some sort of blip, when it comes to sound drivers.
A _momentary_ blip on certain hardware is acceptable if it's unavoidable.
Changing the levels and leaving them wrong for seconds before a user-space
post-install script fixes them is not acceptable.
[EMAIL PROTECTED] said:
> You are depending on the hardware to keep its state -between- driver
> unload and driver reload. That seems inherently unstable to me.
No we're not. After the kerneld code was removed, I hacked up something to
do that, but it was a suboptimal solution and wasn't reliable on all
hardware. As I said, persistent storage is the better solution.
With persistent storage, the sound driver is free to reset and initialise
the sound card hardware upon reload - it's just that it can initialise it to
the levels which the user had previously set, rather than to the compiled-in
default levels (which are preferably zero).
Initialising the levels to a default and expecting a user-space app to fix it
later is not good enough.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
