al3xtjames has quit [Quit: Ping timeout (120 seconds)]
<chadmed>
povik: in reference to your comment, you can define one set of woofers as SNDRV_CHMAP_SL and SNDRV_CHMAP_SL in macaudio.c to differentiate them from the "rear" ones, which id probably use just for the (sub)woofers
al3xtjames has joined #asahi-dev
<chadmed>
it doesnt really matter at the end of the day since each driver is still accessible individually if you know its address, but since they really do different jobs as members of the array they should probably be called different things
ChaosPrincess has quit [Ping timeout: 480 seconds]
<marcan>
oh?
<marcan>
honestly though we should have a separate dtbs package with all the magic autopulling from asahi etc
<marcan>
definitely shouldn't be in m1n1 itself since that just makes updates more annoying
<Glanzmann>
Why not take the dtb from the kernel? Or is it to much hassle for building m1n1/u-boot?
<_jannau_>
creating a separate git repo from the splitted device tree repo is not a problem. I'll check how fast the filtering of the asahi kernel branch is
<_jannau_>
Glanzmann: yes, it would be annoying to use the whole kernel repo just for the *.dtsi?
<_jannau_>
on distro level it might make sense to install the dtbs from the kernel build and use them when creating the the m1n1+dtb+u-boot binary
<marcan>
we should be able to fork that, tweak the scripts a bit and merge in the asahi changes in the same way robher does it
<marcan>
I looked at it in the past but I could've sworn someone else here already gave it a shot at some point?
<sven>
I think that shot was the PR jannau linked above that you closed ;)
<_jannau_>
I used it to filter the dts commits in the pull request
<_jannau_>
the problem with using the reposiptory directly is that it is ~2GB large
<marcan>
ahh it was merged directly into m1n1? that's why I was confused
<_jannau_>
yes, I used it to rewrite the commits for m1n1
<marcan>
I wonder why that repo is so large though, is there a ref that points back to the full kernel history? there's no way there's 2GB of just DTS changes...
<marcan>
--reference indeed skips most of the objects so something is fishy here
<marcan>
ok yeah this tracks back to the whole kernel, lol
<marcan>
where...
<_jannau_>
2GB sounds small for the whole kernel history
<marcan>
nah it's in here
<marcan>
my .git in asahi/git/linux is <1GB
<marcan>
git is efficient
<marcan>
and I think there was a snafu at some point in that repo and the whole kernel history got pulled into a merge parent...
<j`ey>
4.1G .git :|
joske has joined #asahi-dev
<joske>
maybe git repack and or git gc?
<marcan>
fb17f9df8dd0353331 is one of the problems at least, not sure if there are more
<marcan>
that links the DT-only branch and the rest of mainline history
<chadmed>
marcan, povik: i spent most of today doing a bunch of testing, and i seriously do not think we should be applying whatever transformations macos does to the audio. these speakers actually sound significantly better with far less processing, mostly just a crossover and linear coefficient on the tweeters to tame them back a bit
<chadmed>
the only transformation absolutely neccessary through that method though is taming down 400-600 Hz on the main set of woofers a bit, but the rest can actually be feasibly done via plain old ALSA through UCM
<povik>
superior audio under asahi when?
<povik>
interesting
<chadmed>
povik: well in my opinion, basically as soon as we get the left woofers to stop dropping out randomly if we go with my method
<povik>
haha, list of music under EQUIPMENT :-p
<povik>
chadmed: working on it
<chadmed>
part of any good science experiment is being able to reproduce it perfectly, so of course i need to add the list of music i used heh
<povik>
of course
<chadmed>
its far from the weirdest thing ive had to include in a paper, i once had to write a real one about peoples biological reaction to counter-strike match replays
<povik>
well i won't go through it in detail right now, but thanks for sharing what looks like a great write-up!
<chadmed>
no problem, the main thing is just that whatever macos does actually sucks and we should think about something else when the time comes
<marcan>
chadmed: the FIR/IIR would still be done through asound, there's no other good place to put it AFAICT
<marcan>
it's either this or we put it in pipewire and just pretend everything else doesn't exist
<marcan>
it's definitely not going in the kernel
<marcan>
chadmed: either way we still want to characterize what macos does, if only for comparison purposes within linux, and to see about that stereo magic they do which is a different story
<marcan>
is your testing just by listening, or did you grab samples of the sample streams?
<marcan>
FWIW I also have a calibration mic lying around, so we can plot the real speaker response if we want
* j`ey
hopes there will be a simple approach for those that arent picky
<marcan>
the simple approach is we ship some asound profiles and you just pick the right device :)
<marcan>
also +1 for ムーンライト伝説 :D
<j`ey>
why are the first characters so simple compared to the last 2?
<marcan>
because the first characters are katakana and spell "moonlight", and the last 2 are kanji (chinese characters) a mean "legend"
<marcan>
*and mean
<chadmed>
marcan: my testing was just by listening, but i can pull out my calibration mic tomorrow and do some log sweeps or something if you want. ive just brought the "subs" down to 20 Hz and by themselves with a bit of EQ magic they actually sound really really good so ive definitely got more work to do regardless
<marcan>
nice
<j`ey>
marcan: ooh
<marcan>
and if you have the mic lying around I'll certainly defer to you for the sweeps :D
<chadmed>
only thing im worried about is pipewire exploding constantly, but that happens even without my asound so that seems like a driver thing
<marcan>
j`ey: hiragana and katakana are like lowercase and uppercase, two versions of a vaguely phonetic alphabet, but the usage is more like normal text and italics
<marcan>
kanji is a totally different thing that encodes actual meaning in each character so... yeah, a lot denser
<chadmed>
ive deferred my japanese minor for two years because i dont quite fancy trying to memorise all the kyouiku kanji in one semester lmao
<kettenis>
ideally the filters would be described in the DT somehow
<povik>
uh
<kettenis>
but I guess coming up with an agreed upon representation of the filters will be a challenge
<marcan>
chadmed: btw, did you up the pulseaudio resampling quality? IIRC it's... pretty garbage by default
<j`ey>
chadmed: マルカン
<marcan>
kettenis: nah, the linux audio world has given up on that, that's why we have ALSA UCM and all that stuff
<marcan>
and whatever android does etc
<marcan>
I'm not aware of any push to fully describe the audio chain in the DT and I'm not going to block us on that :p
<marcan>
(for better or for worse)
<chadmed>
marcan: i left it on the default because it was working okayish for what i was doing, but the crackling starts becoming very apparent once i start messing around in carla so thats another job for tomorrow's to do list
<marcan>
wait carla on top of PA?
<chadmed>
yeah jack and pipewire kept exploding...
<marcan>
umm...
<marcan>
yeah that's weird
<marcan>
honestly if you're doing serious audio testing you should probably be using JACK
<marcan>
pipewire is good but the automagic resampling scares me a bit, JACK is a lot dumber (and thus more predictable)
<marcan>
PA is, well, PA
<marcan>
"good enough for listening", woudln't be doing quality tests through it if I can help it though :-)
<chadmed>
yeah i know but i couldnt get it going properly, with or without my custom config
<marcan>
weird, I should look into that I guess
<marcan>
oh, also, we need safeties for the blowing up speakers problem
<marcan>
possibly a DT-side volume cap or something like that
<povik>
noted in TODO
<marcan>
do we know how macOS caps, is it in the gain setting at the amps or does it just send quieter sample streams and consider that headroom for the filters/etc?
<marcan>
(or both?)
<povik>
i don't
<marcan>
should look into that, I guess
<povik>
will be easy enough to check next time i have macos under hyper
<marcan>
kk
<marcan>
this is another Unsolved Linux Problem (sigh), I blew up my Chromebook speakers by clicking the wrong thing in alsamixer...
<marcan>
but at least even if we can clip the drivers a bit, we should limit the max gain kernel-side to something that won't immediately blow them up
<povik>
yeah, i had to work out something to hide some knobs from userspace
<marcan>
yeah...
<povik>
apple,macaudio driver does it now
<marcan>
then we can leave some headroom for the filters anyway
<marcan>
cool!
<povik>
but it requires some changes to ASoC i will a have to push through
<marcan>
yeah, this is all for good cause and I consider *this* a release blocker
<marcan>
btw, I'm leaning towards not shipping audio (beyond jack-only and mac mini speaker maybe?) for the first release, if only because I want to make sure we nail the safety bit
<chadmed>
yeah it would suck if people blew up their speakers, and i guarantee no ones going to read my little "hey dont turn the volume up" comment in asound
<marcan>
and now the DT updates aren't a problem
<marcan>
so we can push that whenever we feel confident
<povik>
good by me
<chadmed>
+1
<marcan>
yeah, I've been saying these machines are unbrickable, and I've abused GPIOs enough to be quite confident we'll be fine there
<marcan>
but you can *definitely* blow up your speakers
<marcan>
definitely don't want people ending up there
<kettenis>
the tas2770 chip has "Real-Time Diagnostics Using I/V Speaker Sense"
<povik>
i don't have the capacity to rush it to the release anyway
<chadmed>
yeah im thinking we hide that stuff plus the "amp gain" sliders from userspace entirely
<marcan>
yeah, of course, I meant not even the guesswork DTs
<povik>
but still we want to update some bits as there are fixes to known issues
<marcan>
and yeah, honestly, the specific kernel driver should hide all the nonsense, the ASoC idea of exposing everything by default is batshit insane and *completely* unsuitable for desktop systems like these
<marcan>
maybe you can get away with it on embedded with custom userspace
<marcan>
absolutely not on a macbook
<povik>
all on the same page here :)
<povik>
chadmed: i am just thinking about capping the "amp gain" knobs
<chadmed>
honestly i have them at zero and the speakers already start clipping at like 70% volume
<povik>
kettenis: macos drives the speakers with the I/V sense set up
<povik>
it's gues over the I2S bus back to the SoC
<povik>
s/it's gues/it goes/
<kettenis>
yes, that is my understanding as well
<povik>
the speaker amp drivers have an option to enable the I/V sense stuff, but i don't see any way the signals are picked up by anything
<povik>
^^ in linux
<povik>
meaning the codec side gets enabled, but then the signals don't reach anything
<povik>
AIUI
<povik>
chadmed: something is broken there then, stand by on that front
<arnd>
marcan: is it intentional that you have not sent any dt changes for 5.18 my way? I see one small patch for the pmu that went into linux-next through the arm64 tree, but nothing else.
<povik>
also, continuing on what marcan said, the option to enable I/V sense circuitry is exposed... as a knob to userspace :D
<kettenis>
povik: that makes absolutely no sense
<kettenis>
limiting the gain is probably the best we can do without embarking onto an interesting research project ;)
<marcan>
arnd: it is, we haven't really upstreamed anything worth adding this time and t6000 isn't ready yet. I guess it vaguely is as of today, but without the DART changes USB/PCIe don't work so... still rather useless with no way to do networking
<marcan>
been focusing on tying up a bunch of jellybean drivers for a public alpha release, then I can kick the kernel upstreaming train again :)
<marcan>
also t6002 might make me redo how we organize the t600x device trees, so that's another reason not to rush that one
<kettenis>
personally I would have liked to see the ans2/nvme bindings and dt changes upstreamed even if there are still some loose ends in the Linux driver
<marcan>
yeah, that was the plan, but... kinda got stuck on that one :(
<marcan>
OTOH they are trivial enough there's a good chance they won't change
<sven>
I guess I could even send a first nvme RFC. this atcphy has just been more fun than sending patches
<marcan>
sven: tbh just the schema would be good to get in at least
<kettenis>
well, if it changes, expect some serious pushback from my end
<marcan>
no point in rushing the RFC for the driver, that won't go in at this point
<marcan>
but a little binding could
<sven>
I’m not sure there’s much more to change for the driver fwiw
<sven>
at least nothing that can’t be fixed later anyway
<marcan>
we did just change the binding relatively recently to fix the power domains
<marcan>
so that was good to catch
<marcan>
can't think of anything else that could be wrong
<sven>
yeah. maybe some discussions about the compatibles or something but those can happen in the ML anyway
<sven>
so I guess I can just submit bindings/rtkit/SART/nvme as a single series?
<marcan>
yeah, just put the bindings patch first so if that gets ACKed I can push it via our tree or something
<marcan>
I expect the rest will need several takes anyway
<sven>
yeah, I think those are supposed to come first anyway
<sven>
yeah
<matthewayers[m]>
Something else I find interesting is how no networks appear under the network config menu in Debian.. is this because of wpa_supplicant.conf doing something fun or is there a disconnect somewhere in the driver when it discovers networks?
<marcan>
I assume you saw the changes I made in our bits/ branch right?
<arnd>
marcan: ok, sounds good. just making sure we aren't missing the merge window by accident. Sounds like 5.19 will be bigger then.
<marcan>
yeah
<sven>
I saw some, but I guess I’ll just squash the fix up commits
<sven>
the atomic rtkit stuff can go in with smc then
<marcan>
OTOH it doesn't actually matter if the DT binding makes it in early at that point
<marcan>
once it's ACKed that's all kettenis cares about
<marcan>
so no reason to rush the merge either
<sven>
once it’s in there’s less temptation to change anything ;)
<arnd>
not sure how much time I'll be able to spare on t6002 bringup myself, I might wait for you to get it all running first and use a VM guest until then.
<marcan>
of course
<marcan>
arnd: when does yours arrive?
<arnd>
Apr 6
<marcan>
eh, it'll be done by then :)
<marcan>
the bringup will be a day of work and then a couple months of bikeshedding over whether to use macros or patch dtc for the devicetrees ;)
<arnd>
right
<sven>
you people aren’t helping what little control I still have left that prevents me from buying that thing :P
<marcan>
ahahahaha
<matthewayers[m]>
marcan: would you consider the networks not appearing under a desktop env to be release blocking too, since the majority of end-users don’t even know how that works?
<marcan>
matthewayers[m]: the desktop env I ship will have networks appear, at least they appear for me on KDE :)
<marcan>
where does this problem occur?
<arnd>
sven: feel free to come visit me in Dettenhause when I have mine and you want to try stuff out
<arnd>
Dettenhausen'
<sven>
hah, that’s actually not that far from me :)
<marcan>
matthewayers[m]: FWIW the first release criteria is "core image boots and runs on everything with the expected hardware working at the kernel level and iwd for wifi; plasma image boots and runs on everything and the KDE/preinstalled frontends for stuff that is supposed to work work as expected"
<marcan>
(plasma image will have NetworkManager backed by iwd)
<matthewayers[m]>
marcan: Debian 11 with GNOME. I believe they appeared under KDE when I ran it yesterday afternoon.
<marcan>
other desktops/userspace stacks/network stacks/etc are out of scope at this point, i.e. I want people to report these bugs as part of this first release
<matthewayers[m]>
marcan: Good thing I like KDE :)
<marcan>
obviously there will be bugs, and some bugs will even have nothing to do with us (e.g. wpa_supplicant doesn't work for WPA3 because it doesn't support what brcmfmac uses; clearly not our problem at *this* stage, though something we might want to submit a patch for at some point)
<marcan>
but also by having people running this, hopefully some subset will be devs willing to track down these problems and fire out patches themselves and save us work :)
<j`ey>
matthewayers[m]: are you sure wifi came up? a few people have had issues with it coming up, so it miht be that rather than a GNOME/DE issue
<marcan>
yeah that's a different issue (that one *is* a release blocker)
<matthewayers[m]>
I was able to ping 1.1.1.1 with 0% packet loss
<matthewayers[m]>
… in KDE
<matthewayers[m]>
I’ll do more testing today once I finish my last assignment for the week
<marcan>
I think for some people it comes up or not randomly on any given boot
<marcan>
if it doesn't you won't see the device at all
<matthewayers[m]>
Gotcha. I’ll de-stress with the soothing Mac startup chime and see what the frequency of that is on my build. I’m using asahi-next
<marcan>
:)
<marcan>
actually going to get into kernel-wrangling mode now, so hopefully I'll fix some of these things
<marcan>
first figure out wtf is going on with the Mac Mini module stuff
<mps>
marcan: you are not only one who fried speakers on chromebook, also I did about 2-3 years ago
<marcan>
:)
<marcan>
mine literally melted the plastic case
<marcan>
like the outer case
<povik>
uh
<povik>
let's see we can keep our "0 speakers blown" stat until the safeties are in
<mps>
my just starting to 'crackle' when playing anything, and speech can't be understand by anyone
<mps>
fried them also with alsaconf knobs
<mps>
but jack works and using headphones is ok
<marcan>
thankfully I was working for Google at the time, so after I shouted angrily at an internal mailing list someone was nice enough to send me replacement speakers for free
<marcan>
and I do believe they fixed that particular problem
<povik>
no they didn't :D
<povik>
asoc still doesn't behave sanely
<marcan>
I *thought* they did on that model at least!
<marcan>
the samsung arm chromebook
<marcan>
(at least with official kernels)
<marcan>
asoc in general, yeah, no
<marcan>
:p
<mps>
I tried to find them on the net and order but didn't found, thank you samsung ;p
<mps>
marcan: also samsung one plus rk3399?
amarioguy has joined #asahi-dev
<marcan>
no, the exynos one
<marcan>
the first one
<mps>
ah, I have also exynos peach pi, didn't had problem with it
<mps>
actually peach pi is best one of all notebooks I used till now
<mps>
good keyboard, good anti glare screen, good battery life and fast enough for daily work, only not so for compiling
<marcan>
ah, just realized what was wrong with the Mini. nothing, it's just that the firstboot systemd stuff runs before any modules load so it wasn't loading the USB keyboard support...
<marcan>
honestly I don't like that unit, I'm going to just turn off the timezone prompt
<j`ey>
wtf was going on? nothing :D
ChaosPrincess has quit [Remote host closed the connection]
amarioguy has quit [Ping timeout: 480 seconds]
darkapex has joined #asahi-dev
amarioguy has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
joske has quit [Remote host closed the connection]
nico_32 has quit [Remote host closed the connection]
nico_32 has joined #asahi-dev
ChaosPrincess has joined #asahi-dev
yuyichao_ has joined #asahi-dev
bisko has quit [Read error: Connection reset by peer]
<marcan>
maz: rebased asahi on top of yesterday's linux-next + irqchip-next, everything seems in order on t6000
<marcan>
though I noticed I explicitly have to specify firestorm/icestorm to `perf stat`, otherwise by default it only shows the icestorm counters which confused me
amarioguy has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
Major_Biscuit has quit []
<maz>
marcan: that's how we deal with big.little. one PMU per CPU type.
<maz>
the perf tool is not exactly friendly with this sort of setups.
<marcan>
right...
<jannau>
maz: one of the imac configs doesn't used pcie port 2. I deleted the port in the model specific dts file. That causes mismatched MSI interrupts. It's trivial to fix in the dts
<jannau>
fixing it in the dts is probably the right thing, the port doesn't vanishes just because it's unused
<maz>
jannau: I'm not sure I get what you changed exactly. we should be able to handle having less ports being described, but it could be that there is a driver bug using the number of ports
<maz>
but yeah, the port does exist on the HW, and we should just mark it as disabled.
yuyichao_ has quit [Quit: Konversation terminated!]
<marcan>
yeah, I know, but that's not what upstream uses (yet)
<marcan>
and I'm not sure I want to diverge right now
<marcan>
might try it later
<jannau>
probably not an option if you want to work on top of devicetree-rebasing
<marcan>
povik: btw, re what Glanzmann mentioned, see the nvme driver for an example of how to handle multiple power domains properly
<jannau>
it was painless and reasonably fast for filtering devicetree-rebasing for m1n1
<marcan>
hm, might give it a try
<marcan>
for now I'm going to let this run overnight :p
<marcan>
not sure if it'll be (much) faster on subsequent runs if I keep the state branch or not (I am resetting the upstream branches but doing a merge-a-fu on the filter state)
<marcan>
ETA is 1h30 :')
<marcan>
and that's after I hacked it to move the tempdir to a ramdisk
<kettenis>
hmm, the aic2 DT changes break things for me
<marcan>
they're supposed to, the binding changed incompatibly
<marcan>
(for t6000)
<kettenis>
yeah, but the timing sucks a bit :(
<kettenis>
I can work around this i the DT though by extending the first register set a bit
<marcan>
not sure if linux will like the overlapped map...
<kettenis>
let's see what I need to change in my driver to make it work
* marcan
-> sleep
PaterTemporalis has joined #asahi-dev
<povik>
marcan: it's fixed in wip (and yes, i did use the nvme driver for reference)
<Glanzmann>
povik: Is the wip branch ready for merging into asahi?
<povik>
it's not. let me extract what's safe to merge
amarioguy has quit [Ping timeout: 480 seconds]
<kettenis>
ok, found a relatively clean way to support both the old and the new DT
<kettenis>
pushed a DT resync to the u-boot repo
<kettenis>
now also has the nvme shutdown patch in it
PaterTemporalis has quit [Remote host closed the connection]
PaterTemporalis has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
<jannau>
yeah, t600x dcp crash fixed, constantly missed a mapped page for disp0
ChaosPrincess has quit [Remote host closed the connection]
darkapex1 has joined #asahi-dev
darkapex has quit [Ping timeout: 480 seconds]
<jannau>
argh apple, why? ServiceRelay::sr_set_uint_prop() and ServiceRelay::sr_setProperty_int()
<nico_32>
consistency in naming function, what's that? :)
<jannau>
also the uint one is only used for a single property with a value of 0. the int one is used with properties which should be unsigned
ChaosPrincess has joined #asahi-dev
<jannau>
and a working dcp framebuffer on t6001
<sven>
nice!
int80 has joined #asahi-dev
<Dcow[m]1>
so it can hit the alpha release? or something else to fix?
ChaosPrincess has quit [Remote host closed the connection]
<jannau>
probably not although a scaled display is nice on on the retina screen
<jannau>
not sure if we can as easily hide the notch with dcp
<sven>
ugh… brought to you by hours of debugging: 1) when the usb2 phy is powered down the dwc3 soft reset never completes and ofc dwc3 only calls phy_power_on *after* that soft reset ofc
<sven>
and 2) if a phy is connected to a port and that phy is also connected to dwc3 dwc3 won’t probe anymore (silently ofc) because it assumes an extcon connected to the phy must exist :-(
<sven>
and that’s just for the usb2 part. I bet usb3 doesn’t work yet due to another dumb problem like that