<chadmed>
povik: max volume in alsa overdrives the speakers by about double on j314s now
yuyichao_ has joined #asahi-dev
<chadmed>
also i assume it sounded "off" when you tried it because only woofer 1 L/R is actually pumping sound
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi-dev
hizon has joined #asahi-dev
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
the_real_briel[m] has joined #asahi-dev
<the_real_briel[m]>
Hey everyone! I think this project is awesome! I would love to help with this project but I don't necessarily know where to start or what prerequisite information I should work on for this kind of reverse engineering process. What kind of value do you guys think I could best provide to this project only really having university and web dev experience?
kov has quit [Quit: Coyote finally caught me]
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
kov has joined #asahi-dev
user982492 has joined #asahi-dev
WindowPain has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
WindowPain has joined #asahi-dev
WindowPain has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
WindowPain has joined #asahi-dev
<emergenz[m]>
I don't have a M1, but a MacBookAir9,1 but I think progress towards getting Bluetooth working on 9,1 would also be valuable for M1 (and vice versa). Has anyone already looked into Bluetooth (of M1 or 9,1)? If yes, please let me know
WindowPain has quit []
<emergenz[m]>
So nobody has started looking into Bluetooth, correct?
WindowPain has joined #asahi-dev
<chadmed>
nah bluetooth is far down the priority list at the moment
<the_real_briel[m]>
🥲
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi-dev
King_InuYasha has quit [Read error: Connection reset by peer]
<chadmed>
sooooo turns out a bunch of the CMT LADSPA filters are written in x86 assembly...
<chadmed>
most importantly to us, the low, high, and bandpass filters
<chadmed>
actually no theyre not, but they wont link for aarch64 in any case with bfd or lld
shenki has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
<Jamie[m]1>
gotta do something custom to utilise the AMX instructions :3
<Jamie[m]1>
/s
<chadmed>
if i could i would just as a proof of concept lmao
<chadmed>
on a more positive note though, i now have all 6 drivers working simultaneously with some very simple alsa configuration
<chadmed>
granted, they sound like arse, but thats what the LADSPA plugins were meant to fix
<chadmed>
my plan was to drive them as if they were triple-driver floorstanders, because they are in essence exactly that
<chadmed>
i.e. have a high pass filter cut the crap below ~6.5k of the tweeters, have each woofer handle ~250-6.5k independently, and then sum both of them as a single channel to handle 0-250
the_lanetly_052__ has quit []
<chadmed>
this could have been done pretty simply if those plugins worked on aarch64, and then once we had that array set up as a device, hand that off for FIR/IIR correction
<jannau>
chadmed: there are debian packages for all architectures so I suppose they should build on aarch64
<chadmed>
if you try installing them, youll notice that some plugins are missing
<chadmed>
if you grab the sources and build like that, it also just doesnt build those plugins
<chadmed>
if you try forcing it to build them by using "make filter", the linker explodes
<Jamie[m]1>
hmm why does the debian package show as amd64 only for me?
<Jamie[m]1>
ah because I am on the page for the amd64 version
<Jamie[m]1>
never mind lol
<chadmed>
oh bfd also explodes on amd64
<Jamie[m]1>
i don't see any notable differences between the amd64 vs arm64 cmt.so's that would suggest one has more filters than the other
<chadmed>
yeah i just tried on my amd64 machine now, filter doesnt build by default here either
<chadmed>
and if you try it blows up
<Jamie[m]1>
both so files contain the string "High Pass Filter (One Pole)"
<Jamie[m]1>
which comes from filter.cpp
<Jamie[m]1>
so I think they must actually have filter?
<chadmed>
yeah so i wonder why those plugins dont install/ladspa cant see them
<chadmed>
they dont show up by ID in /usr/lib/ladspa on my j314s
<chadmed>
rather, if you try to reference them by ID, ladspa has a whinge
<Jamie[m]1>
they should all be in cmt.so
<Jamie[m]1>
they're not separate plugins
<Jamie[m]1>
*not separate files
<marcan>
< Glanzmann> jannau: Yes, it works perfectly. <- perfectly as in using efifb?
<marcan>
it sounds to me like simpledrm isn't working for you at all and you're actually using efifb
<marcan>
chadmed: it should be possible to just drive each speaker as a FIR/IIR combination of L/R
<marcan>
yes, L/R because I'm pretty sure Apple does cross-processing too, for stereo width
<marcan>
no need to first set up a crossover or anything like that
<marcan>
one FIR filter can handle everything flat
<marcan>
and we can just steal those impulses from macOS
<Jamie[m]1>
anti-piracy font you wouldn't download a frequency response curve
<marcan>
you wouldn't download it, but you would certainly sample it!
<marcan>
impulse responses are not copyrightable :-) (the underlying response isn't anyway; the data file might be, but re-computing it isn't)
<Jamie[m]1>
cleanroom reverse-engineering is so last century. asahi linux does anechoic chamber reverse-engineering
<marcan>
:D
<marcan>
actually we just run macOS in the hypervisor and send out a test signal and capture the speaker streams :p
<marcan>
and heh, ADTs have so much garbage... those have camera sections in the product info
<marcan>
also it looks like Ultra is just another max at 0x2000000000 in MMIO space
<marcan>
I wonder if we can literally re-organize our DTs to include the T6000 and T6001-delta subcomponent bits in includes
<marcan>
then #include them into buses with range translation
<marcan>
and do it all that way
<marcan>
robher: what's your take on #include in DTs within buses, for something like this where a vendor glued two SoCs together?
<marcan>
only problem though is aliases would collide, hm
<marcan>
any ideas on how to handle this, other than writing it all out twice?
<marcan>
maybe could have a macro around/next to aliases, which gets redefined around each include
<marcan>
to prefix things, like i2c0 -> d0_i2c0, d1_i2c0
<kettenis>
marcan: the marvell armada 7k/8k and cn9k device trees use some tricks to avoid repetition
<marcan>
also are subdirectories allowed/preferred under arch/arm64/boot/dts? I think it might get unwieldy if we have everything flat, I'd favor top-level/platform DTs at the top level (and maybe top-level SoC/MCM includes), then a per-soc-family directory with bits and pieces, if that's reasonable
<kettenis>
but I'm not impressed by the results
<marcan>
ah, like armada-cp11x.dtsi
<marcan>
yeah, I guess that's a similar idea
<povik>
chadmed: ah... so i *did* push last night!
<povik>
seems like you are having fun
<povik>
how can you tell the overdrive?
<povik>
also when i said it sounded off, it was when i simply duplicated the stereo stream to all speakers
<povik>
chadmed: is it realiable on your end? because i had issues with one speaker dying off randomly
<povik>
the configuration now is that when you open the device for 2 channels, it only drives L/R woofer 1
<povik>
that's on purpouse, because it sounded best to me
<povik>
(in comparison to picking another pair of speakers)
<chadmed>
povik: the clipping is extremely prominent at volumes > ~60 in alsamixer, which tells us that the amps are being driven too hard
<povik>
ok
<povik>
i didn't dare turning up the volume that high yet
<povik>
but you are more brave than i am
<chadmed>
also yeah something is really unstable at the moment, i can reliably poke the array directly through alsa but doing so via pulse, pipewire or jack causes it to explode (drivers start dropping out, volume control lost, etc)
<chadmed>
marcan: oh too easy then, ill just leave the alsa config at routing the stereo signal to each driver then at the same signal level for now
<povik>
^ that's when i said it sounded off
<marcan>
also you absolutely *can* kill Mac speakers with volume
<marcan>
... I've seen a T2 Mac have a speaker die like that, in macOS, with an EP patch
<povik>
yeah, that's why chadmed is brave
<povik>
pulling some random branch and turning up the volume :D
<marcan>
... so yeah, I hope you have AppleCare :p
<marcan>
(I'm actually putting on AppleCare on these expensive macs for that reason...)
<chadmed>
huh, to me it sounds marginally better with everything enabled, i have non-uniform coefficients set in my ttable right now though
<chadmed>
marcan: ive got something better than applecare, the australian consumer law :P
<marcan>
lol
<chadmed>
theyre usually really good about replacing stuff here, a couple of friends have even had liquid damaged machines replaced for free
<kettenis>
marcan: my advice would be to keep it simple; working with those armada 7k/8k device trees has not been a joy
<kettenis>
you end up building dtbs and decompiling them to see what the macros really do
<marcan>
I don't think what I want to do would be very complicated
<chadmed>
povik: is it left woofer 1 that drops out for you occasionally?
<povik>
i think left woofer 2, definitely one of the left woofers
<chadmed>
yeah its consistently whichever driver is mapped to 0 for me
<povik>
mapped to 0 in the DT list?
<povik>
i tried reordering them and the order didn't seem to matter, it was still left woofer
<chadmed>
i guess 0 in the dt, if thats what alsa also calls 0
<jannau>
chainload experiments/dcp.py problem on the t6001 solved, dcpep breaks if the shared memory is not zero initialized
<chadmed>
its definitely one of the left woofers
<chadmed>
i cant seem to reliably repro it with any particular actions, it just happens
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amw has quit [Ping timeout: 480 seconds]
amw has joined #asahi-dev
misteraftermath[m] has joined #asahi-dev
johey has joined #asahi-dev
the_lanetly_052 has joined #asahi-dev
<marcan>
power-gates = [268435998]
<marcan>
-> 0x1000021e
<marcan>
heh, so they aren't even putting both dies in PMGR, they just added a field
<kettenis>
marcan: that u-boot nvme shutdown patch looks reasonable to me and seems to have no ill effects on my setups
<kettenis>
you should probably just send that out, unless you expect more nvme-related tweaks
<j`ey>
kettenis: I never managed to boot nvme without that patch
<kettenis>
that's because the linux driver makes too many assumptions about the state of the device ;)
<kettenis>
but I should add it to the asahi branch
<kettenis>
I'll probably do another round of updating and rebasing tonight or tomorrow
yuyichao_ has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
limegorilla[m] has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<robher>
marcan: we generally discourage macros for constructing DT nodes, but for includes whatever works for you.
<robher>
marcan: sub-directories are up to you, but I think would be an overkill. arch/arm/boot/dts is what is unwieldy. :(
<marcan>
robher: I think we'd want at least some pasting or wrapping to construct alias names and phandle references, otherwise there's no way to avoid the 2x copy and paste for these socs...
<marcan>
something like DIE##i2c0: ... or L(i2c0): ... or similar
<sven>
marcan: you've also spent to much time with USB: is it correct that there's USB 3.x that only uses a single lane (i.e. one TX/RX pair) and USB 3.2 Gen 2x2 that uses two lanes (i.e. both TX/RX pairs)? and I can combine USB 3 with DP on the other lane on a type c port but if I want that Gen 2x2 thing I can no longer send a DP signal?
<marcan>
and then define DIE to d0_ or d1_ and include the file twice within buses that apply the MMIO offset
<marcan>
sven: yes
<marcan>
also apple gets this wrong in macOS, and ends up reserving everything for DP even when the DP version should let you run that resolution over 2 DP lanes, not 4, and then ends up downgrading USB to 2.0
<marcan>
at least on some monitors
<marcan>
(confusing thing: one USB lane (TX/RX) = two DP lanes (TX/TX))
<sven>
i hate this already :D
<kettenis>
of course they might do that because the hardware is actually broken...
<marcan>
I'd be surprised if they screwed that one up...
<sven>
at least the crossbar configuration supports modes like USB / DP and also DP / DP afaict
<sven>
but apparently not usb / usb unless i'm still confused :/
<marcan>
robher: also unrelated, but ideas for a /chosen property name to hold the EFI system partition PARTUUID? since we're going to have multiple, this seems like the sanest way to pass it down to the bootloader/OS... not sure if this one should be an apple,foo thing or not.
<robher>
marcan: for things on buses, 'ranges' should help you. 'aliases' shouldn't be shared anyways. They usually should be board specific.
<marcan>
I meant labels, sorry, not aliases
<marcan>
since e.g. each die has to self-reference without colliding, and be referenceable by things outside of that file as that specific die
<maz>
as long as it doesn't look like the Armada 80x0 stuff...
<robher>
marcan: if we can't express what's needed in dts syntax, we can always add to the syntax.
<marcan>
robher: we'd need some kind of namespace thing, e.g. a special kind of node or a special prop within a node which causes all labels within it to be prefixed with something... and then some escape syntax to break out of that where needed
<marcan>
I can test tomorrow, I think I have an NVMe thing that should be 2x2
<sven>
sure
<marcan>
the monitor is at at friend's place, would have to test there
<sven>
i'm actually a bit more curious about the 2x2 device
<marcan>
sure
<marcan>
off to sleep, kinda exhausted today :p
<sven>
DP might even be more complex. there's references to some kind of DP phy as well
<sven>
goodnight :)
<sven>
fwiw, xnu will spam a *lot* when you enable those bootargs so make sure to store the output somewhere because it'll overflow your terminal scrollback very quickly
<robher>
marcan: Right. Raise the question on the devicetree-compiler list.
<robher>
marcan: Though if you just used macros for labels that would be a lot better than the Armada crap.
<kettenis>
glad to learn I'm not the only one who didn't like the armada approach
<maz>
it's totally unmaintainable. but at the same time, nobody maintains this platform.
<maz>
(will trade an mcbin for... anything)
<robher>
macstudio?
<kettenis>
sold
<maz>
robher: btw, if you could look at marcan's AICv2 series, I need an Ack from you on the binding patch (at least).
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi-dev
heli0s[m] has joined #asahi-dev
the_lanetly_052 has quit [Quit: Leaving]
user982492 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gladiac has quit [Quit: k thx bye]
___nick___ has quit [Ping timeout: 480 seconds]
V has quit [Ping timeout: 480 seconds]
V has joined #asahi-dev
<marcan>
OTOH, still no news on the IOMMU stuff, right sven?
<marcan>
maz: I can respin it today with the commit message fix robher pointed out if you want (plus alyssa's nit)