<rkjnsn>
(reading the backlog) I take it Apple Music ended up having a sufficient copy of “I Won the Loudness War”? If not, I purchased as a FLAC from Qobuz once, and the samples were all pegged at one extreme or the other as expected.
<phire>
Oh, yeah. Saw your tweets about that
<phire>
I guess the problem with applecare is that you can't disect the speakers to see if it was a thermal failure, or something else
<marcan>
yeah, unfortunately
<marcan>
rkjnsn: can you confirm the sample rate? if it's 44.1k then I think my copy should be identical after the re-clipping
<marcan>
if it got resampled then maybe not
<chadmed>
id love to be the failure mode analyst getting a macbook top case with tweeters melted into it with no additional context
<marcan>
lol
<marcan>
I'm debating whether I should try to get friendly with the Apple Store technician, and/or let them know what's going on
<marcan>
could very much go either way
<marcan>
but it would be nice to get the old speakers back
<chadmed>
IME theyre trained to maximise customer retention above all else, at least here they are
<chadmed>
ive been blessed with some extremely creative interpretations of the australian consumer law by apple staff in the past just to keep me happy
<marcan>
lol
<marcan>
well, I did pay for AppleCare, so if I have to have my speakers replaced 5 times and they start looking at me weird, I can just say "look, I'm trying to figure out how *not* to kill the speakers so that a few thousand people don't kill them"
<marcan>
but I do wonder if there's any chance of getting the broken speakers back
tardyp has quit [Server closed connection]
<chadmed>
would be worth a shot asking but it depends how far up the ladder the machine needs to go for the repair. if it needs to leave the store and go to one of their refurb warehouses then theres basically 0 chance
<marcan>
oh yeah
tardyp has joined #asahi-dev
<rkjnsn>
marcan, yeah, 44.1k. You can also pay 50¢ extra for a 24-bit download (also at 44.1k). I assume that's automatic because the creator uploaded it in 24-bits, but it's kind of absurd given that the whole track is effectively one-bit samples.
<marcan>
:D
<phire>
hmm... not sure if I could get that kind of damage pasted them on nz consumer guarantees
<marcan>
I did skim the applecare US terms (not going to spend hours trying to parse legalese in Japanese...) and at least those don't explicitly single out anything about software damage due to third-party software
<marcan>
they just say they don't cover such third-party software itself
<marcan>
I suspect it's one of those "nobody thought about this" cases
<marcan>
OTOH they don't cover "intentional" damage, but well, it's not like I'm *trying* to destroy my speakers
<phire>
I could probally argue "not fit for purpose. It really shouldn't damage itself
<marcan>
japanese consumer protection is pretty poor as far as the law goes; most things here rely on the goodwill of manufacturers/shops (which is culturally expected)
<phire>
they are really strong in NZ and Australia
<phire>
and from what I understand, really vauge in North America, to the point that nobody even knows what they cover
<marcan>
yeah
<chadmed>
NA seems similar to japan but without the cultural mores that oblige companies to offer a decent service
<chadmed>
it seems to be changing somewhat though with right to repair type stuff
<phire>
the main problem in NA is no real enforcement. And nobody is going to push things though to courts
<chadmed>
thats why its best that we risk a few Ls ourselves now before thousands of people blow up their macbooks trying to play bass boosted trap remixes on youtube under linux
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
yup
<marcan>
I'm willing to keep doing this even if I start having to pay for repairs (though that would be shameful of Apple)
<marcan>
I practically got AppleCare on these things *for* the speaker experiments
<phire>
could it be worth asking apple nicely for some docs on this one area?
<marcan>
that would be tricky...
<marcan>
I do have friends over there but nobody that works on audio AIUI
<marcan>
and I'm not sure how we'd try to get an official contact
<phire>
well, I wouldn't be supprised if it doesn't take long for the tweets to find the correct team
<marcan>
yeah, but finding the correct team *and* someone willing to talk to us?
<chadmed>
plus im sure theyd come with some ridiculous NDA that would not be worth signing. its not like we're on a wild goose chase or have no clue where to even start looking
<marcan>
the problem here is this isn't just theoretical talk, we'd need actual numbers/curves/datasheets to do it right
<marcan>
and that's solidly in the NDA-violating leak territory unless we get official approval
<marcan>
and I don't see the latter happening any time soon, given how Apple works
<marcan>
and yeah, I'm not signing NDAs
<phire>
yeah, it would require a werid move from their legal team, which would be very un-like them
<marcan>
yup
<marcan>
I think the pragmatic approach here is to just kill some speakers
<marcan>
and then set the caps lower than macOS, which we want to anyway, because I'm convinced you can kill the speakers under macOS
<phire>
a more PR focused company would do it, to avoid the publicitly of more tweets killing more speakers
<chadmed>
yeah but this is the company of "buy your mum an iphone"
<marcan>
and also, there is the very real possibility of this backfiring if it goes up the chain
<marcan>
"asahi linux can damage macs, third party OSes bad"
<marcan>
might be best to just fix the issue ourselves without making too much noise
<marcan>
some management genius could go "well, we can't *guarantee* that third party OSes won't kill speakers, so we need to void warranty if you bputil" or worse
<phire>
good point
<chadmed>
yeah like really the worst case scenario is that the speakers are a bit quieter than macos
<chadmed>
but the tradeoff is that (in my opinion) we make 'em sound better :)
<marcan>
I don't expect apple to cut us off on a whim, but this kind of warranty/damage argument could change their opinion depending on who it gets to
derzahl has quit [Ping timeout: 480 seconds]
<marcan>
anyway, I'm DFUing this thing (with AC2 for now, will re-do it with idevicerestore later to fix it / prove it works) and I should take a shower before I head out to the apple store :)
<marcan>
bbl
thelounge7571340 has quit [Remote host closed the connection]
<phire>
have fun
thelounge7571340 has joined #asahi-dev
linxz has quit [Server closed connection]
linxz has joined #asahi-dev
ModR\M has joined #asahi-dev
e1eph4nt has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
ModR\M has quit [Read error: Connection reset by peer]
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
sjg1 has quit [Server closed connection]
sjg1 has joined #asahi-dev
chip_x has quit [Read error: No route to host]
Simonx22 has quit [Server closed connection]
Simonx22 has joined #asahi-dev
_alice has quit [Server closed connection]
_alice has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<M4t64[m]>
<marcan> "anyway, I'm DFUing this thing (..." <- my uncle is a tenured prof mainly doing ios middlewear (augmented reality afaik). last time we met he was bragging about his new gadgets from a something-mil fund lol. we aren't super close and i cannot guarantee anything but if you can drop the machines/specs you're looking for i can try to get you the best bang. he is based in korea so shipping should be reasonable
e1eph4nt has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
rpirea_ has quit [Read error: Connection reset by peer]
rpirea__ has quit [Read error: Connection reset by peer]
<marcan>
rmk: yes, remember this architecture comes from iOS devices where software was tightly controlled
<marcan>
they failed at reworking some parts for a macOS world
<marcan>
this is one
<marcan>
the NVMe flush performance issue is another
rpirea__ has joined #asahi-dev
<povik>
not sure this is something they 'failed' at
<povik>
seems it works well for them
<povik>
that is of course unless you can break it with their software
<povik>
but that is unproven at this point (with the new lineage of hardware from ios devices)
<povik>
for all we know I/V sense can catch it before you do damage
<marcan>
I'm pretty sure you can break it with their software, but the fact that the platforms supports third-party software changes the safety requirements here
<marcan>
for a general purpose computing platform, yes, I consider offloading all speaker safety limits to a driver a failure
<marcan>
it's not just about third-party OSes either. consider: third-party kext scribbles over memory and it happens to be audio buffers
<marcan>
even moreso: there's a good chance Apple does the DSP in userspace, and that means you could blow the speakers from userspace if the kernel audio system driver doesn't have enough safety using the VISENSE thing
e1eph4nt has joined #asahi-dev
derzahl has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
povik: I'm making some changes to macaudio for safety (renaming the module var to something scarier/more accurate, gating everything except j274 on it) and adding j413
thelounge7571340 has joined #asahi-dev
<marcan>
did you see what I pasted about the speaker data in the ADTs?
<marcan>
I did notice the HPF setting for two models, which actually also includes the upper bits that do other things, so we might want those too
* povik
will take a naked codec over a firmware-laden coprocessor with crazy IPC any day
<povik>
which i see Apple as implementing the safety layer in
e1eph4nt has joined #asahi-dev
<povik>
it's a matter of expectations; although i guess apple does sell it as general computing hardware
<povik>
marcan: feel free, i will look at the changes later
<povik>
i caught the ADT data
<povik>
the higher bits are for a codec register?
<marcan>
yes, they go directly into the DC_BLK0/1 registers
<povik>
i am interested what they do, i thought there isn't anything interesting next to the HPF settings
<povik>
*in
<marcan>
they turn on IRQZ pullup (don't think we need that, it should have IPU on the AP side), turn off spread spectrum, and turn off edge rate control
<povik>
well but the cases i saw it was writing in the default values
<povik>
what you list is non-default?
<marcan>
only two models have this setting
<marcan>
(the latest two)
<marcan>
so yes
<marcan>
(the M2 ones)
<marcan>
see the ADT paste :)
<povik>
nah, only disabling of the spread spectrum is non-default
<povik>
i meant which bits differ from their reset values
<povik>
let's if that's what they do on models before the ADT field
<marcan>
please check my math and please tell me I'm wrong...
pjakobsson has quit [Remote host closed the connection]
thelounge7571340 has quit [Remote host closed the connection]
<DmitrySharshakov[m]>
from what you've written it appears that thermal resistance = heat capacity (you refer to it in that way). That looks a bit weird to me. Maybe my English Physics terms are not on the best level and I misunderstood it
<DmitrySharshakov[m]>
But K/W (or °C/W) most likely should refer to heat capacity. thermal resistance is the value thermal conductors should be measured with (K/W*m or sth like this), the resistance material gives to the heat flow
thelounge7571340 has joined #asahi-dev
derzahl has joined #asahi-dev
<blazra[m]>
<DmitrySharshakov[m]> "But K/W (or °C/W) most likely..." <- I don't know the context, but K/W is thermal resistance. It means how large is a difference of temperature between two regions in space when there is specific heat flow (power) between the two regions.
e1eph4nt has quit [Ping timeout: 480 seconds]
<povik>
right, these are watts, so a rate of energy, not an amount of energy
<marcan>
DmitrySharshakov[m]: you're confused. heat capacity is J/K. K/W is thermal resistance.
<marcan>
thermal resistance refers to the temperature delta you get between two points at 1W of power transfer
<marcan>
in this case the two thermal resistances are between voice coil and magnet, and between magnet and ambient (I believe)
<marcan>
and then the time constants (tau) give you the actual dynamic behavior of those temperatures under changing power
skrzyp has joined #asahi-dev
mkwa[m] has joined #asahi-dev
e1eph4nt has joined #asahi-dev
* rmk
just found an issue with the gpio series I sent...
<rmk>
on arm32:
<rmk>
"Apple Mac Platform-Specific Device Drivers (APPLE_PLATFORMS) [Y/n/?] (NEW)"
<rmk>
should we really be asking that for all architectures, and should that even default to Y ?
<marcan>
gating it on ARM64 or X86 is probably okay, but default to Y I don't see why not? people want their machines to work :p
thelounge7571340 has quit [Remote host closed the connection]
gladiac has joined #asahi-dev
gladiac has quit []
<arnd>
drivers/platform/surface/ uses 'depends on ARM64 || X86 || COMPILE_TEST', which seems like a good idea in general, even if it doesn't make much difference
rpirea has quit [Quit: Leaving]
<arnd>
I would also skip the 'default y' and just put that in the defconfig files, the only reason for default-enabling those options is that it would otherwise break existing defconfigs that don't have it enabled
thelounge7571340 has joined #asahi-dev
<marcan>
defconfig works too
<rmk>
what about "depends on ARCH_APPLE || X86 || COMPILE_TEST" - is there any point offering APPLE_PLATFORMS if ARCH_APPLE isn't set?
<arnd>
right, good idea
<rmk>
arnd: do you want me to separate out the defconfig change?
<arnd>
rmk: yes, I usually keep those in a separate branch
<DmitrySharshakov[m]>
<marcan> "in this case the two thermal..." <- Ahh, more complex thing than I thought. Then sorry, your calculations seem perfectly fine then. Also 0.5W is quite expectable for those speakers
<marcan>
rmk: no, that's wrong
<marcan>
ARCH_APPLE is for ARM only
<marcan>
oh wait
<marcan>
I thought that was &&, nevermind
<marcan>
the thing is though, I thought ARCH_APPLE was supposed to *enable* things required for Apple platforms
<marcan>
so the logic is backwards, no?
<rmk>
also, I think Kalle Valo is waiting on an answer on the arm64 DTS changes for brcmfmac:
<marcan>
or did I confuse myself?
<rmk>
Is it ok to take this via wireless-next? Can I get an ack from the
<rmk>
maintainers of these files?
<marcan>
ah yeah, merging via wireless-next is fine, let me give you an ack
<rmk>
marcan: I suppose we could do 'depends on ARM64 || X86 || COMPILE_TEST; default ARCH_APPLE"
<marcan>
yeah, that's more in line with what I expect
<rmk>
or maybe depends on ARCH_APPLE || ... with that default
<marcan>
though
<marcan>
I think I did confuse myself
<marcan>
everything else seems to do:
<marcan>
/home/marcan/asahi/git/linux/drivers/nvmem/Kconfig: depends on ARCH_APPLE || COMPILE_TEST
<marcan>
I think at *some* point we weren't depending on ARCH_APPLE but then we settled on that form
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
rmk: by the way, you probably also want eb5f6452591, df29598e6b59, 82a001b3158
<marcan>
it will *work* without those but probably not *well* since it's missing calibration/related data
<marcan>
those should apply to all the apple chips too I believe, including yours
<marcan>
(but if it makes the series too long they can always be merged later)
<rmk>
as people generally seem to be happy with the 12 patch series, let's get those merged asap, we can always follow up with more patches before the next merge window.
<rmk>
it's not like these changes are going to be functional until we get the gpio and pci stuff sorted
<marcan>
yeah
e1eph4nt has joined #asahi-dev
nsklaus has joined #asahi-dev
<marcan>
and before I sleep, let me cook up a kernel build from the latest merge so y'all can't say I didn't get the merge done this week either ;)
<marcan>
(still needs the fwextract stuff before I push it to users though)
e1eph4nt has quit [Ping timeout: 480 seconds]
nsklaus_ has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
povik: testing new kernel, cs42l84 ADC seems to be picking up output instead of input (routing issue? this is a typical non-chinese pinout headset mic)
<marcan>
(totally random guess: this is just leakage and the mic is dead, maybe because there is no mic bias voltage?)
thelounge7571340 has joined #asahi-dev
<marcan>
anyway, smoke tested on t6000, wifi works, bluetooth at least enumerates (too lazy to test), headset playback works if you manually raise the volume, nothing obviously broken
<marcan>
pushing to git & asahi-dev
<marcan>
also that was supposed to have been -1, not -2, oops :p (let's just pretend there was a -1 and I got it wrong)
<marcan>
if nothing is botched, this will probably be what we ship to users next, modulo whatever I decide to do with the speakers on some models
MatrixTravelerbot[m]1 has quit []
RowanG[m] has quit [Quit: Client limit exceeded: 20000]
psydroid[m] has quit []
philhug has quit [Quit: Client limit exceeded: 20000]
arisu has quit []
mariogrip[m] has quit [Quit: Client limit exceeded: 20000]
M1bn3mar[m] has quit [Quit: Client limit exceeded: 20000]
Lena has quit [Quit: Client limit exceeded: 20000]
BenjaminGwynn[m] has quit [Quit: Client limit exceeded: 20000]
Guest182 has quit [Quit: Client limit exceeded: 20000]
jevinskie[m] has quit []
ms12[m] has quit []
Deewiant has quit []
gaudem[m] has quit [Quit: Client limit exceeded: 20000]
pashencija[m] has quit [Quit: Client limit exceeded: 20000]
<povik>
marcan: you can see in dmesg if it detected the mic even
<povik>
given the samples are non-zero, it probably did