This makes it more clear that we're matching against Apple machines. The
kernel driver will be updated to use this naming scheme. For backwards
compatibility, we add a rule to rename J313 at runtime (the only enabled
model at this time).
This update must be released together with a matching asahi-audio update
(but the kernel can come later).
Signed-off-by: Hector Martin <marcan@marcan.st>
Disallow nontrivial negative power, but clamp down rounding error to
avoid flickering signs in debug logs.
Signed-off-by: Hector Martin <marcan@marcan.st>
Headroom goes *above* the limit, not below. Replace the max safe temp
thing with a window delta below the limit where attenuation begins.
Signed-off-by: Hector Martin <marcan@marcan.st>
The kernel should clamp this to the correct value. We still read it back
later, to make sure our amp output calculations are correct.
Signed-off-by: Hector Martin <marcan@marcan.st>
Mostly autogenerated from macOS AU preset dumps, with speaker names and
channel orders manually adjusted as necessary.
Signed-off-by: Hector Martin <marcan@marcan.st>
For single-speaker devices, there is no control prefix. So treat the
special name "Mono" as a null prefix in that case.
Signed-off-by: Hector Martin <marcan@marcan.st>
On any panic, we dump out the last ~30 seconds of IVSENSE data along
with the starting state and panic reason.
Also add a feature to panic if the gain reduces too much. This can be
used to try to catch badness.
Signed-off-by: Hector Martin <marcan@marcan.st>
We're not doing explicit error handling, since the kernel is in charge
of safety if we crash. Just panic on anything.
Signed-off-by: Hector Martin <marcan@marcan.st>
ALSA needs special handling to correctly resume after the system is
suspended with a PCM active. Do the required dance.
Signed-off-by: Hector Martin <marcan@marcan.st>
Doesn't really matter for us since all machines we plan to use so far
have the same chip, but might matter in the future.
Signed-off-by: Hector Martin <marcan@marcan.st>
Take the vendor from the DT compatible, since in principle other
manufacturers could use this code too.
Signed-off-by: Hector Martin <marcan@marcan.st>
Just reporting the first nonzero change isn't really useful. Be spammy,
we can always reduce this later.
Signed-off-by: Hector Martin <marcan@marcan.st>
If this is the first time the daemon runs, we assume 99C (just under the
limit, which means no reduction). Otherwise, we assume the max
temperature, and therefore max limit.
Signed-off-by: Hector Martin <marcan@marcan.st>
This is mostly to avoid a sudden jump up in volume on the common case where the
first sound happens after enough catchup has occurred (once we implement
catchup...)
Signed-off-by: Hector Martin <marcan@marcan.st>