thelounge7571340 has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
off^ has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
e1eph4nt has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
e1eph4nt has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Ping timeout: 480 seconds]
Z750 has joined #asahi-dev
ids1024 has joined #asahi-dev
kode54 has joined #asahi-dev
esden has joined #asahi-dev
koorogi has joined #asahi-dev
arnd has joined #asahi-dev
kendfinger has joined #asahi-dev
_alice has joined #asahi-dev
Simonx22 has joined #asahi-dev
sjg1 has joined #asahi-dev
turo has joined #asahi-dev
Chainsaw has joined #asahi-dev
philpax___ has joined #asahi-dev
linxz has joined #asahi-dev
tardyp has joined #asahi-dev
tmlind has joined #asahi-dev
x56 has joined #asahi-dev
tych0 has joined #asahi-dev
jkkm has joined #asahi-dev
kendfinger has quit [Quit: Updating details, brb]
azenla has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
SSJ_GZ has joined #asahi-dev
refi64 has joined #asahi-dev
e1eph4nt has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
jluthra_ has quit [Remote host closed the connection]
jluthra_ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
nsklaus_ has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
rpirea__ has quit []
rpirea has joined #asahi-dev
<marcan>
jannau: does your DT update also include all of povik's updates? (looks like it, but just checking)
<povik>
AFAIK it does
<marcan>
re the speaker volume caps, is there any chance we can move that config to the DT? it feels a bit wrong to have to hardcode that in the driver for each model
e1eph4nt has quit [Ping timeout: 480 seconds]
<jannau>
marcan: yes
<povik>
not sure it's that wrong, since there's other model-specific quirks we need to hardcode
<povik>
having said that, i plan to move the caps to DT
e1eph4nt has joined #asahi-dev
nsklaus_ has joined #asahi-dev
<marcan>
what model-specific quirks can't be encoded in the DT? (not arguing with you, just want to get the full picture)
<povik>
as i plan it the driver won't probe with speakers on the general compatible (unless void_warranty=1), only for models for which we have written down the quirks or which we have explicitly blessed to be okay without quirks will the driver probe
<povik>
marcan: see the fixup_controls in macaudio.c, e.g. the j314 tweeter highpass and over-current retry
<povik>
or the locking of left/right slot selection on codecs where it doesn't make sense
<povik>
so i just want to point out that as i plan it we have to explicitly enable each model in macaudio.c anyway
<jannau>
can't we add that all to the dts and fail to probe if the devicetree doesn't have entries?
<marcan>
^ this
nsklaus has quit [Ping timeout: 480 seconds]
<marcan>
testing new kernel merge now
<povik>
like a quirk list?
<povik>
or express it in props and the driver refuses probe if there are props it doesn't know?
<marcan>
ah, you mean so it can refuse to probe for "new things" it doesn't know about? can't we just use compatibles for that?
<marcan>
we can just have models have a fallback compatible to the oldest "equivalent" model as far as driver support
<povik>
yeah, that i like
<marcan>
if we introduce new props that require handling the driver does not currently do, then those models don't get the old compatible
<povik>
still some level of general compatibles
<povik>
coarser than per-model
<marcan>
yeah, doesn't make sense to have true "general" compatibles here since the audio setups are quite diverse, but it does make sense to throw fallbacks in for models which are effectively the same setup as older ones
<povik>
that actually works with the driver already, listing the compatible of past similar model
<marcan>
that way we can support new machines that basically look like old ones (with different volume caps and other parameter values)
<marcan>
yeah, it'd just be adding actual properties for things on top of that
<marcan>
(for things we do expect to change like caps)
<povik>
and if we move the caps to dt, that may increase the versatility sonewhat
<marcan>
yup
<povik>
yeah, sounds good
<marcan>
I see we already use the "* Tweeter" pattern to match tweeters, so that's probably pretty general already. Mostly just volume limits then (which probably should be specified per-speaker, ideally in those DT nodes but that might be a bit difficult with how ASoC is organized?)
<marcan>
going to try to add j413
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
<marcan>
looks like ~the same as j314
<marcan>
povik: what does the ASI1 Sel force do?
<marcan>
heh, enabled everything and audio just works without any userspace :) (sounds like crap of course)
<marcan>
looks like by default it only routes to tweeters
<marcan>
alright, first let's try to kill the speakers :p
<marcan>
I wonder if I can actually buy the "proper" version of I Won The Loudness War on Apple Music
<marcan>
okay, I'm concerned this track might destroy my speakers *in macOS*
<marcan>
just hitting preview, lol
<marcan>
povik: dare I say macOS-3dB was a good idea
<marcan>
and apparently I don't have AppleCare on the M1 MBA... ha. I know I do on the M2 one at least.
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
e1eph4nt has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
e1eph4nt has joined #asahi-dev
<marcan>
povik: honestly, this sounds way scarier on the M1 MBA in macOS at full volume than on the M2 MBA in Linux
<marcan>
oh wait. I forgot volume=0.1, lol.
<marcan>
yeah okay this is properly scary
<marcan>
let me get on macOS and get a reference for how these speakers are *supposed* to sound
<marcan>
heh, there's quite a bit of harmonics on a sine sweep... I wonder if I already screwed the speakers up a bit or it's normal
<chadmed>
are you just pumping the sine sweep into each driver with alsa? harmonics at ~480-500 and multiples thereof are non-pathological
<chadmed>
the chassis themselves are quite noisy even going back to intel macbooks
<marcan>
I was using macos, but now trying alsa
<marcan>
it actually sounds more balanced without any EQ on alsa, I think apple are doing some really weird stuff...
<marcan>
especially the woofer part
<chadmed>
yeah im really not a fan of what apple do
<chadmed>
its quite muddy and gross, almost like they got the beats team to handle the EQ
<chadmed>
the woofers really pop at 500ish especially but its almost like apple try to accentuate that even more with whatever they do to give the perception of bass response at low volumes
<marcan>
it does look like I have more harmonics than with macOS, but this isn't a very controlled test
<marcan>
probably also cancellation issues since I'm just sending it out of all drivers all at once
<marcan>
let me do one at a time as a control
<marcan>
hmm... I think the highpass isn't getting applied to both tweeters?
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
alsamixer does show both controls at 800Hz though
chadmed_ has joined #asahi-dev
<marcan>
povik: you silly, you got the wrong register!
<marcan>
it's DC_BLK1, not DC_BLK0
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
thelounge7571340 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
wait no, it is 0, I can't read
<marcan>
but then why does it look like it's not working for one tweeter?
<marcan>
I may have already damaged a tweeter...
off^ has joined #asahi-dev
<marcan>
the left one sounds super low compared to the right one
<povik>
applying the filter is audible on the woofers, so i think that should be alright
Race has joined #asahi-dev
<chadmed>
when i played around with some of the alsamixer controls it also smushed the volume until i rebooted so you could try that too i guess
<chadmed>
specifically the amp gain sliders did that
<marcan>
povik: yeah, something else is the issue with my left tweeter
<marcan>
it's not just volume though
<marcan>
something is very wrong here
<marcan>
let me go back to macos...
<povik>
wasn't that before the volume field fix to tas2764, very early into development?
<povik>
chadmed: ^
<marcan>
okay, even the boot chime sounds weird now
<marcan>
I'm pretty sure I did damage
<povik>
uh oh
<chadmed>
povik: probably, i never touched them again after the initial incident
<chadmed>
marcan: oof thats unfortunate
<marcan>
and I had the volume caps all along, though I did briefly remove the HPFs and run sine sweeps in my confusion
<povik>
so it wasn't from macos you did the damage, that would make for a more amusing story :p
<marcan>
okay yeah this is rattling in macos
<marcan>
I screwed up my speakers yay!
<marcan>
it's weird though
<chadmed>
it mustve been teetering on the edge of death already somehow then, i ran multiple full volume sine sweeps when i was doing the DSP stuff :/
<povik>
this isn't j314 i think
<povik>
marcan: right?
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
j413
<chadmed>
oh yeah, odd that itd be significantly weaker though
<marcan>
oof these speakers are definitely busted, yup.
<povik>
so you can blow your speaker if you try very hard :D
<marcan>
I didn't try that hard!
<povik>
not that we didn't know all along
<marcan>
I somehow managed to fry, I think, both tweeters? in different ways
<marcan>
the left one is just half dead, very quiet and with a poor response
<marcan>
the right one rattles
<marcan>
the thing is, I don't know *when* I fried them
<marcan>
because if I'm reading my audacity recording right, they were already like that before I messed with the HPF
<marcan>
and the only thing I did between the macOS boot when things sounded fine and that, was run a few full sine sweeps (all drivers at once), *with* HPF and volume limiting
<povik>
hah
<marcan>
so that suggests the HPF + volume limit are *not* enough to prevent damage
<marcan>
unless... I fried them from macos running sine sweeps there
<marcan>
I'm not sure if I tested something sane in macos after the sweeps
<marcan>
but it has to have been one of those two
<marcan>
ok, comparing the last macos sweep with a new one, the rattling is definitely new
<chadmed>
huh i wonder if it was indeed macos then
<chadmed>
that would be incredible and hilarious if so
e1eph4nt has joined #asahi-dev
<marcan>
comparing the first 2 recordings I have of linux sweeps, I think it was already damaged by the second one
<marcan>
but possibly not the 1st
<marcan>
so it sounds like I killed it from linux, with a full-volume all-driver sweep, with all the safeties enabled
<povik>
so you traced macos before to get the cap
<povik>
on j413?
<marcan>
yes
<marcan>
and I think I may have also damaged at least one of the woofers :D
chipxxx has joined #asahi-dev
<marcan>
since it now rattles before even hitting the HPF threshold for the tweeters
<povik>
hm, i think the next step is finally looking at macos impulse response
<povik>
so we will see the precise envelope, and if there's a significant component of software attenuation
<marcan>
this does also suggest that we need significantly lower volume caps, if we want to not have userspace responsibilities, unfortunately
<povik>
it is bit suspect the amp gain settings from macos are mostly the same across models
<marcan>
I do suspect you can kill the speakers from macos too, given the right audio (I mean, I did see a T2 Mac's speakers die from a simple electric piano patch, not even at full volume)
<marcan>
but yeah, I think this time the damage was from linux
<chadmed>
povik: would it not be better to just bump the kernel driver limits way down instead of copying the IRs from macos? both in terms of infallibility from userspace and affording us the ability to maximise the sound quality from these things
<chadmed>
theyre already stupidly loud
<marcan>
I mean we should look at the macOS IRs just to see *what* it does
<marcan>
anyway, I guess all that's left now is to blast I Won The Loudness War on it and see how much worse I can kill them?
chadmed_ has quit [Quit: Konversation terminated!]
<marcan>
let's see. took a reference speaker-test + sweeps before.
chipxxx has quit [Remote host closed the connection]
<povik>
chadmed: i am not advocating for copying it, but we will be able to tell at what point we are contained in the vendor's frequency envelope, for example
<povik>
not sure there's point in torturing the speakers further, marcan :D
<marcan>
science!
<chadmed>
it's fun
off^ has quit [Ping timeout: 480 seconds]
<marcan>
okay, I played the whole song and I can *smell* the voice coils cooking
thelounge7571340 has quit [Read error: Connection reset by peer]
<chadmed>
awesome :D
<marcan>
let's see how much damage I did :D
<marcan>
okay, now both tweeters are properly damaged, not just the left one
<marcan>
but get this - the right woofer now rattles less!
<marcan>
the song *improved* it!
<povik>
it just occurred to me we could have with a bit of work recorded the isense/vsense values from the test
<povik>
well, next time...
<marcan>
yeah, I think that's also something we need to figure out
<marcan>
want to work a bit on figuring that out, for when I get the machine back?
<marcan>
I was doing a pretty slow sine sweep (40 seconds). it's possible a much faster one will give us enough data while being less likely to kill drivers.
<marcan>
yup, definitely fixed the rattling. this is hilarious!
<chadmed>
i used either 10 or 15 seconds with REW, the machine was loud enough that it was able to pick up its sync/cal signals
<marcan>
then again, the "fixed" right woofer might just be because it damaged it in a way that reduces its volume, and now it doesn't hit rattling level :D
<marcan>
though I'm not entirely sure
thelounge7571340 has joined #asahi-dev
<marcan>
but yeah, in macOS now it basically just sounds like no tweeters, otherwise fine
Race has quit [Ping timeout: 480 seconds]
<marcan>
anyway, given all this, I'm going to make sure speakers are disabled across the board and push out testing kernels
<dottedmag>
This song is a "repair" song, kinda similar
<marcan>
:D
<chadmed>
plasma burn in fixer but for melted electromagnets
<chadmed>
anyway i have tomorrow (mostly) off so happy to test on my machine if youve got asahi-wip rebased by then
e1eph4nt has quit [Ping timeout: 480 seconds]
chipxxx has joined #asahi-dev
e1eph4nt has joined #asahi-dev
<marcan>
as for the woofers: macOS doesn't get anything below 80Hz out of them, though it does spit out odd harmonics from inputs as low as 25 Hz, which I suspect is a deliberate saturation filter
<marcan>
so we should probably set the HPF for the woofers to 50 Hz, I don't see the point in trying to pump out anything lower
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<DmitrySharshakov[m]>
If you got colis overheated then it definitely seems that the problem lies in gain. Frequency related problems must not have caused that, since those could only do mechanical damage by oscillations
<DmitrySharshakov[m]>
<marcan> "so we should probably set the..." <- Yes, I suggested that. povik said it's the default of that amp (reset state)
<povik>
isn't it 4 Hz? let's check
<DmitrySharshakov[m]>
4 Hz wasn't there in the datasheet
<DmitrySharshakov[m]>
Ah, I forgot. it's 2 hz default (DC block)
<DmitrySharshakov[m]>
But I suggested 50, we agreed on that being excess
<DmitrySharshakov[m]>
It's unlikely to have had caused damage, but still
<marcan>
DmitrySharshakov[m]: I don't think that's true. the movement of the coils has feedback effects on voltage/current, which could increase current flow.
<povik>
exactly, the power transfer is frequency-dependent, i would imagine
<DmitrySharshakov[m]>
Well, inductance could do something bad as well...
<marcan>
yes
<marcan>
hence, ISENSE/VSENSE might be useful here
<marcan>
I don't think this is what damaged the woofers though / caused the rattling, I think it's more likely that there are resonant peaks that cause things to break/get loose mechanically
<marcan>
but it's still dumb to try to put put anything lower than 50Hz, you can *hear* the things moving at 20Hz even though they don't do much
<marcan>
*put out
<marcan>
as for the tweeters though, I do suspect those just cooked themselves at this volume, to some extent
<DmitrySharshakov[m]>
marcan: Also, chadmed noticed case vibrations on <50Hz, so they're unpleasant to users as well
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
it's possible they seized up, and the remaining frequency that comes out is whatever the mechanical state they ended up in allows via resonance
<DmitrySharshakov[m]>
Seems to be. So lower the volume limits in HW
<marcan>
yeah, in general I think the tweeters are too loud sans EQ anyway, they actively hurt my ears
<marcan>
so maybe the trick here is to just lower the max volume of the tweeters
<DmitrySharshakov[m]>
I think we don't need high volume, let it be quiter. Laptop is a device for personal use, not public events, so we can reduce its output power
<DmitrySharshakov[m]>
IV sense is an interesting thing, actually interesting to implement just for the sake of coding. However, that leads to more risks
<povik>
what? no
<povik>
it has ~zero risk, and i know how to implement what we need to asoc so we can get the measurements
<povik>
also, my goal is to get it safe, otherwise i am not going to limit the volume
thelounge7571340 has quit [Remote host closed the connection]
<povik>
i enjoy how loud my macbook can get, and there will be others too
<DmitrySharshakov[m]>
Also, TAS2764 does that by streaming back, unsure whether it's easy to handle in kernel
<DmitrySharshakov[m]>
Is it implementable?
<povik>
yes.
<DmitrySharshakov[m]>
povik: We can get the measurement, but need to react to it (preferably in kernel)
<povik>
no.
<povik>
i will implement what's needed so we can peek at the measurements, but we are not going to inspect them in kernel
<DmitrySharshakov[m]>
How? We just measure stuff?
<DmitrySharshakov[m]>
Ah, you mean during tests
<povik>
not now, and probably never, given the upstream's stance on this
<DmitrySharshakov[m]>
Sorry for misunderstanding
e1eph4nt has joined #asahi-dev
<DmitrySharshakov[m]>
I first thought we could make use of those measurements in runtime for extra safety
<povik>
well we can, but it has to happen in userspace
<DmitrySharshakov[m]>
Yes, so that would be risky as I mentioned earlier
thelounge7571340 has joined #asahi-dev
<marcan>
povik: for safety reasons, there is an argument for doing something with the I/VSENSE data in the kernel I think, especially if the alternative is DSP in the kernel / trusting userspace
<marcan>
it depends on what we see, so let's get the data out first
<DmitrySharshakov[m]>
btw does Apple Care return the replaced parts?
<marcan>
no
<marcan>
but I think we might be able to do something like a partial sampling where we don't necessarily process all the data, but just do RMS measurements on part of each frame, enough to decide whether to trip a safety mute
<marcan>
it's not nice but it's nicer than DSP in the kernel or requiring sane userspace
<DmitrySharshakov[m]>
marcan: Probably sth as simple as 'if higher than (say) 2 watts in some time, lower the gain'
<DmitrySharshakov[m]>
marcan: Yea, nice idea
<marcan>
I wouldn't lower the gain, I'd just mute for a second or so. this is supposed to be a last resort safety, under the assumption that userspace *is* trying to do the right thing in the normal case.
<DmitrySharshakov[m]>
But still I guess we just need to lower the volume
<DmitrySharshakov[m]>
marcan: Hmm, might be done like that as well
<DmitrySharshakov[m]>
Does macOS activate the I/V sense feedback ever?
<marcan>
I think macOS does activate it
<marcan>
povik: an alternative would be to build this as a "speakersafetyd" that both enables the higher volume caps and watches over the I/VSENSE data, and is supposed to be simple / unrelated to any sound system in use
<marcan>
then that'd need kernel checks to make sure that process is alive and processing input data, and if it stops, revert the increased volume caps
<rmk>
is "brcm,cal-blob" still being used?
<marcan>
but at that point I'm not sure if that *really* buys you a whole lot over a kernel thread doing the same thing, so that'd be a discussion to have on the MLs
<marcan>
rmk: yes
<marcan>
m1n1 populates those properties
<povik>
that's actually what upstream hinted towards in macaudio RFC v1/v2, not sure which one it was
<povik>
re: speakersafetyd
<povik>
when i wanted to get rid of the ISENSE/VSENSE stuff
<marcan>
yeah, the main thing is really how much processing does it have to do, and do you actually get anything out of it being in userspace at that point
raytracer has joined #asahi-dev
raytracer has quit []
<povik>
i can guess the upstream's arguments...
<marcan>
if it's just taking some envelopes and doing some simple hysteresis or whatever, I'm not sure punting that to userspace (with the additional complexity of watching over it from the kernel anyway, and having a handshake for the uncapping) actually buys you much?
<marcan>
I mean I know the usual arguments here
<DmitrySharshakov[m]>
Probably if maintainers are not against this kernel driver should take care of it
<marcan>
but the usual use case isn't safety related
<marcan>
and the kernel is supposed to ensure safety
<DmitrySharshakov[m]>
btw I/V sense is used by most phones. Do some have upstream drivers for that? If so, let's take a look
<DmitrySharshakov[m]>
marcan: and another question is whether we really want that high volume level which will then be protectively clipped/muted/attenuated when it goes out of safe range
<marcan>
povik: anyway, please see if you can get the data out :)
<marcan>
and I'll see about getting this thing repaired
<marcan>
DmitrySharshakov[m]: the problem is it being frequency-dependent
<marcan>
having volume caps is trivial
<povik>
marcan: yeah, happy to :)
<marcan>
but the maximum safe volume for all possible inputs may wind up being significantly lower than what macOS achieves
<povik>
and the other points i will leave for others to argue over on the lists
<marcan>
let's see if the data is even useful at all
<DmitrySharshakov[m]>
marcan: Yes, so if it is significantly lower, then we have a need in something like that
<povik>
yup
<DmitrySharshakov[m]>
Yes, after we get a look at data we could try to find out how Android handles those events
<marcan>
I wish these things had a couple biquads we could just program... they already do a significant amount of DSP anyway
<marcan>
DmitrySharshakov[m]: Android has a whole audio framework, and you can trust it because Android is a fixed OS built for specific machines
<marcan>
they have a different paradigm
<marcan>
same as Chrome OS
<marcan>
which is why I blew my Chromebook speakers when I poked around alsamixer
<marcan>
with platforms like that, the platform can assume userspace is doing the "right" thing
<marcan>
our requirements are not the same for desktop linux
<DmitrySharshakov[m]>
marcan: Like the userspace is fixed and kernel gives no guarantees?
<marcan>
yes
<DmitrySharshakov[m]>
marcan: I know
<marcan>
I doubt most Android platforms implement proper safeties in the kernel, they just rely on the userspace config being correct
<marcan>
case in point: at one point LineageOS for one of my older phones had the vibrator gain set too high, and it would rattle like hell
<marcan>
they rely on userspace for everything on Android
<DmitrySharshakov[m]>
At least finding the code might make us know the amount of processing
<DmitrySharshakov[m]>
I guess RMS values with some multiplier should give us enough to trigger the safety mute
<DmitrySharshakov[m]>
But other platforms are likely to even scale the volume based on that data
<DmitrySharshakov[m]>
* DmitrySharshakov[m] goes to Texas Instruments website to find out more and revise the datasheet
<DmitrySharshakov[m]>
I think I've seen a whitepaper from them about using I/V sense in products
<marcan>
so yeah, I have ~no hope of finding anything in this field that we can actually use
<DmitrySharshakov[m]>
However, that code looks to have some potential to reach the kernel. Not FFT, way smaller memory footprint, no tons of maths
<marcan>
ah, it actually is tinyalsa, but it also uses custom stuff around it, so shrug
skipwich has joined #asahi-dev
<DmitrySharshakov[m]>
Yes, some MSM audio headers at least. So probably it's not a standardized kernel API... Well, we should get that problem discussed on the LKML
<marcan>
DmitrySharshakov[m]: from what I can tell in that code, they only use VI feedback to compute speaker calibration, not normally at runtime
<DmitrySharshakov[m]>
Not the thing I recalled of, but definitely nice to read through (will do)
thelounge7571340 has quit [Remote host closed the connection]
<DmitrySharshakov[m]>
https://www.ti.com/lit/an/slaa900/slaa900.pdf refers to a program used as a playground for evaluation, as well as some more (yet not directly related) facts about I/V sense
<DmitrySharshakov[m]>
Do all known AS Macs (except the iMac) use TAS2764 codecs?
e1eph4nt has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
I've read that those need software speaker protection, but there are ones from within SmartAmp lineup which implement the algorithm themselves. Sadly those likely aren't included in any models
thelounge7571340 has joined #asahi-dev
e1eph4nt has joined #asahi-dev
<marcan>
so I may have found where in the ADT the speaker amp level is set, and also it seems some macs use speaker-protection (which I think means VI sense) and some don't
thelounge7571340 has quit [Ping timeout: 480 seconds]
<marcan>
it seems the original M1 trio never had speaker-protection, and the desktops (including iMacs) don't have it enabled. every laptop after that (t6k series and M2) does have it.
<DmitrySharshakov[m]>
Some do enable the feedback? Does j413 you've been testing use that, is there a backchannel in the traces?
<DmitrySharshakov[m]>
So j314 might be okay without it but with sound properly confined by amp settings?
<DmitrySharshakov[m]>
I think jannau once sent us a value being set somewhere for DC blocker. that was for like 2 Hz. Have you found a new DT prop then?
<DmitrySharshakov[m]>
* set somewhere in ADT for DC
<marcan>
apple does not use the DC blocker
<DmitrySharshakov[m]>
I know
<DmitrySharshakov[m]>
But where have you found that new info? Is it a register value embedded into DT or just a flag like `speaker-protection = 1`?
<marcan>
it's literally speaker-protection = 1
<marcan>
but you can also tell because the speaker config has data for bytes 2-3 per speaker, which is probably the TDM feedback slots
<marcan>
and yeah, I'm pretty sure I know where the gain is set, hold on, let me augment the adt decoder for this
<DmitrySharshakov[m]>
are they in the speaker config (like some blank space in registers from the ADT)? I believe they are not in registers at all
<DmitrySharshakov[m]>
marcan: Wasn't it decoded automatically before?
<marcan>
no? it's a binary property
<marcan>
oh wait, there is this too
<marcan>
amp-dcblocker-config = 16641
<marcan>
so I guess they *do* use the dcblocker sometimes
<DmitrySharshakov[m]>
I've previously decoded this when jannau sent it. It means IRQZ on + 2 Hz DC blocker on both playback and recording (ivsense). Basically the default values after reset
<marcan>
only for j413 and j493, but they just set it to 2Hz globally
<DmitrySharshakov[m]>
This means they added a config to the driver but are not currently using it so keep the default
<DmitrySharshakov[m]>
Maybe future software/hardware versions would make use of it
<zzywysm>
marcan: i saw you closed a bunch of pull requests and said you cherry picked some commits, but i don't see any linux branches with changes in the past 24 hours. are the commits only cherrypicked to your working copy so far?
thelounge7571340 has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<jannau>
zzywysm: bits/* branches were updated I didn't check the contents
thelounge7571340 has joined #asahi-dev
<zzywysm>
jannau: most recent bits branch modification was 3 days ago, specifically bits/030-misc. is that where the cherrypicks landed?
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<jannau>
zzywysm: the merge requests / cherry-picks landed there and everything was rebased on v6.0-rc5
<zzywysm>
is that the new master branch? the asahi branch is still based on 5.19
<jannau>
hmm, shouldn't that result in a most recent branch modification of sunday? or is github just looking at the author date of the last commit
<jannau>
there is no new merged branch since someone decided to test/destroy speakers instead
<kloenk>
and the NVMe driver is not async, wonder what that will do.
<kloenk>
As soon as I have time to maybe maybe understand the Mailbox framework, I plan to look, if it would make sense writing async for that, and the port RTkit to async rust. But sadly time is always not enough
<marcan>
I didn't push the merge yet, because I haven't properly tested it yet
<marcan>
kloenk: I wouldn't spend time on mailbox, there's a good chance we just stop using that subsystem altogether
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<sven>
6.0-rc5 will break Bluetooth fwiw
<marcan>
already reverted that
<marcan>
(see that bits branch)
e1eph4nt has joined #asahi-dev
<jannau>
I hope you saw the comment in devicetree pull request
<jannau>
breaking change is already in rc4
<jannau>
b82a26d8633cc89367fac75beb3ec33061bea44a
thelounge7571340 has quit [Read error: Connection reset by peer]
off^ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<shorne>
Hello, I watched the youtube stream about wifi debugging, and it seems marcan found out the broadcom suspend protocol is essentially the same as the current linux driver just using ringbuffer instead of register
<shorne>
Is the code for wlan_tracer.py posted anywhere?
<shorne>
I couldn't really tell how the Ring buffer tracing worked
<shorne>
i.e. is it using a apple,asc-mailbox-v4 or apple,m3-mailbox-v2 ring buffer? or something else?
<kloenk>
marcan: oh, what will be used instead of mailbox?
<kloenk>
Mailbox would make it easier to have a more generic reactor
<shorne>
yeah, I think mailbox should be used, I was just wondering which of the mailbox drivers the wlan cummunication was using
<j`ey>
shorne: kloenk was replying to a comment about not using the linux mailbox api
e1eph4nt has joined #asahi-dev
<sven>
I’m not sure if a lot of rtkit gains much from being converted to rust. Possibly the crashlog thing but im
<sven>
*but I’m not so sure about the rest
<sven>
shorne: Wi-Fi doesn’t use any of the apple, mailboxes
<shorne>
sven: not yet, it seems for the power suspend its using some ringbuffer (its not in the driver yet)
<sven>
no
<sven>
that’s not related to these apple mailboxes
<shorne>
hence my question, what is the ring buffer protocol bieng used there?
<sven>
I guess just the normal Broadcom WiFi thing
thelounge7571340 has quit [Read error: Connection reset by peer]