<amarioguy>
povik: turns out that was the change we needed all along lol, we boot to userspace and the irq path seems to work without a hitch
<amarioguy>
only thing i'm not sure on at this point is where we want the init_completion call, right now i put it in the pasemi_platform_i2c_probe func after common probe is called, but otherwise assuming we don't see further issues seems like the bulk of the patch is done
<amarioguy>
still need to run all the other things though like getmaintainers and all (btw for anyone who needs to review it's on the same page as before)
benpoulson has joined #asahi-dev
surge9n has joined #asahi-dev
<chadmed>
DmitrySharshakov[m]: i think you misunderstood. i meant that i wont be able to test your changes until some time after next week as i am busy with real life stuff. i cant even pretend to be doing work when doing asahi stuff because my real life duties arent even tangentially related :P
surge9n has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
<amarioguy>
yea ofc definitely needed the other changes too
benpouls_ has quit [Remote host closed the connection]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
benpoulson has joined #asahi-dev
derzahl has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
dmmcf has joined #asahi-dev
surge9n has joined #asahi-dev
dmmcf has quit [Quit: dmmcf]
amarioguy has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
pyropeter3 has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
pyropeter2 has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
dmmcf has joined #asahi-dev
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
<chadmed> "Dmitry Sharshakov: i think you..." <- Alright, I understood you. Maybe povik has an opportunity to see that
surge9n has joined #asahi-dev
<chadmed>
fwiw that policy looks like itll work fine but in the filter chain json i probably wouldnt specify node.name manually if you can avoid it, let pw sort that out itself
<chadmed>
just specify a node.nick for the virtual sink instead
<chadmed>
also you need to hide the hardware sink, not the dsp output
<chadmed>
applications need to be able to see the DSP sink and not the HW
<DmitrySharshakov[m]>
<chadmed> "fwiw that policy looks like itll..." <- On PW chat room I got answer that it'd be better to use autoconnect rather than wiring up from my script. I would also prefer manual immutable routing, let's sort this out later in the MR life cycle
<DmitrySharshakov[m]>
chadmed: I hide both
<chadmed>
yeah autoconnect is fine, i just mean in the filter chain you have given the virtual sink a node.name of audio_output.platform-audio.analog-stereo which i think may be confusing to some
<DmitrySharshakov[m]>
I can hide sink, device (to avoid people messing with profiles in pavucontrol) and stream (like output of the chain in case of speakers)
<chadmed>
we dont want to hide the virtual sink since this is the one we _want_ applications to be able to connect to and configure
surge9n has quit [Ping timeout: 480 seconds]
<chadmed>
i.e. DEs and their pipewire/pulseaudio integrations need to be able to see it so that users can set the volume etc
<DmitrySharshakov[m]>
chadmed: Hmm, alright
<DmitrySharshakov[m]>
That's more up to the config file, and one I sent to you is experimental yet, just to test things in a real case
<DmitrySharshakov[m]>
chadmed: We don't hide it. Virtual = false means it appears as a hw sink
<chadmed>
ohhhh yeah ok i see what youve done there
<DmitrySharshakov[m]>
Api = dsp is for the same thing, since else Plasma PA settings applet doesn't see the device
<chadmed>
yeah yeah i get it now, all good
<chadmed>
then yeah id just give the final sink a nice node.nick, everything else is fine
<chadmed>
then the only question in flight is what upstream would be okay with WP actually doing
<DmitrySharshakov[m]>
chadmed: So if I have say builtin audio, wp will add a virtual sink. There're extra parts we don't want user or stuff like EasyEffects to interact with: real sink, real device and a stream from virtual sink to real sink. Hide those from everybody except WP (and while testing also allow helvum)
<chadmed>
"ucm but not utterly useless garbage" is my preferred way
<DmitrySharshakov[m]>
chadmed: Like the mechanism of discovery
<chadmed>
yeah yeah its all clicked to me now, i didnt notice the beauty in that last line of the filter chain
<DmitrySharshakov[m]>
chadmed: Yes I proposed we should have an API to read files from WirePlumber scripts
<chadmed>
its all good now im totaally happy with that
<DmitrySharshakov[m]>
While George, one of the maintainers, is on his vacation, we'll have to stick with my current approach. Then, if he's fine with the fact WP scripts will be able to read FS under WP config dirs, then I'll implement it the way you proposed as I now agree it should be almost 100% descriptive
surge9n has joined #asahi-dev
<DmitrySharshakov[m]>
I opened a proposal for nobody to forget about this: localhost:7474
<DmitrySharshakov[m]>
I'd wait for comments and concept approval from maintainers and then probably implement some functions for filesystem access
dmmcf has joined #asahi-dev
dmmcf has quit []
surge9n has quit [Ping timeout: 480 seconds]
dmmcf has joined #asahi-dev
dmmcf has quit []
dmmcf has joined #asahi-dev
systwi_ has joined #asahi-dev
systwi has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
benpoulson has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
benpoulson has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
povik: based on https://github.com/chadmed/asahi-audio/blob/main/test_notes/j31x.md?plain=1#L9-L12 it appears to be decent to apply 50 or 100 Hz filter (DC_BLK0 -> HPF_FREQ_PB) in hardware for (sub)woofers, so that vibration is filtered out + DC protection active. as well as 800 Hz for tweeters as it's planned. This could 1. make us able to drop the lower part of woofer FIR filter. 2. People who want raw ALSA can just play sound
<DmitrySharshakov[m]>
on woofers via some sort of custom channelmap.
dmmcf has quit [Quit: dmmcf]
the_lanetly_052 has joined #asahi-dev
surge9n has joined #asahi-dev
dmmcf has joined #asahi-dev
<chadmed>
please note lines 5 and 6 of that document.
<chadmed>
i dont tune the "
<chadmed>
"subwoofers" differently to the woofers anymore, they have the exact same IR
<chadmed>
sounds better at low to moderate volumes and doesnt compromise clarity at all. theres still a teeny bit of boxiness around 400-600hz but ill play around with that when i have the time
<DmitrySharshakov[m]>
Yes, but hardware filter removing DC and vibration frequencies can still improve things. Is 100 or 50 Hz appropriate?
surge9n has quit [Ping timeout: 480 seconds]
<chadmed>
50Hz would make more sense to me, the drivers are still pretty good down to about 70Hz so i dont really want to cut off that real nice low end that gives them their fullness
<chadmed>
but i would just not cut anything out and let the DSP take care of it because that gives us finer grained control over their profile
<DmitrySharshakov[m]>
Yes, so it'd be great to test 800 Hz cutoff for tweeters and 50 Hz for other 4 speakers.
<chadmed>
imo the hardware/kernel should only be concerned with stopping people from melting their laptops and nothing else
<DmitrySharshakov[m]>
chadmed: Maybe 2 Hz then&
<DmitrySharshakov[m]>
> <@_oftc_chadmed:matrix.org> but i would just not cut anything out and let the DSP take care of it because that gives us finer grained control over their profile
<DmitrySharshakov[m]>
* Maybe 2 Hz then?
<chadmed>
is the HPF configurable?
<chadmed>
anything below 20hz is noise and id expect the codec to high pass on that regardless of what we tell it to do
<chadmed>
but it shouldnt do anything to input above that
<DmitrySharshakov[m]>
It's a coarse-grained mechanism which evolved from DC protection. Not really an equalizer or something like that. marcan first found it as a measure to protect tweeters from low frequencies at kernel level
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
dmmcf has quit [Quit: dmmcf]
isoriano has quit [Remote host closed the connection]
MajorBiscuit has joined #asahi-dev
<chadmed>
yeah right, so id set it to 2hz on the woofers and let the DSP handle everything else then
<DmitrySharshakov[m]>
Alright
<DmitrySharshakov[m]>
I have also read some materials on IV sense. That's mostly for cases of overdriving mobile microspeakers. So a speaker like a phone one can be operated on power higher than the rated one while being monitored and corrected with IV sense enabled amp. I guess that's not necessary nor suitable for MacBook pro level audio, since such an overdrive will reduce the quality and tone reproduction, plus I guess builtin speakers are not of
<DmitrySharshakov[m]>
"microspeaker" class so they should not need such a drive mode
<DmitrySharshakov[m]>
How is volume with caps in place? How does it compare to macOS defaults?
<povik>
don't forget that the codec doesn't filter all below the frequency we set
<povik>
it's a frequency at which it has -3 dB attenuation
<DmitrySharshakov[m]>
Yes but should keep things safe I guess. Low volume does no harm typically
<DmitrySharshakov[m]>
Is the volume loud enough with caps?
<DmitrySharshakov[m]>
Is there any progress from yesterday (like testing WP changes and kernel driver)? Is there a decent way of marking the device as either J314 or J316 (probably DT prop on audio node could help)
<povik>
so far i have written in -3 dB cap below macOS values, still very loud, but that was mostly arbitrary while i am focusing on other issues
<povik>
what do you mean DT prop on audio node?
<povik>
if you mean the j314/316 distinction, which is currently lost, that is just matter of modifying the model= property
<DmitrySharshakov[m]>
Like if it should be named `MacBook Pro J314 Internal Speakers` or J316
<DmitrySharshakov[m]>
`-3 dB cap below macOS values` is that about HFP or common volume cap?
<povik>
^ here, we just change that
<povik>
or rather set it from the j314/j316 specific files
<DmitrySharshakov[m]>
Alright
<povik>
common volume cap
<povik>
the HFP i will lock on the highest setting for the tweeters, on the woofers i will let them be set from userspace
<povik>
at least initially
<DmitrySharshakov[m]>
Is HPF 'sharp' enough to cut low frequencies off btw?
<DmitrySharshakov[m]>
What about 2 Hz 'DC protection' mode?
<povik>
i don't know yet, got stopped by some other work on the drivers
<povik>
you mean that it would be good to assure the filter's not disabled on the woofers?
<povik>
i agree, but i want to give chadmed a chance to play with the filter :p
<DmitrySharshakov[m]>
Well, 50 Hz might be too high, but since we can why not enable 2 Hz cutoff? It will protect from DC bias
<DmitrySharshakov[m]>
2-50 Hz should do no damage to woofers I guess, so it should be safe to keep those 'convenience' things to userspace
<povik>
of course we don't want to disable it (2 hz appears default and was set already)
<povik>
chadmed: scratching my head at the prealloc thing now
<DmitrySharshakov[m]>
Ah, alright, wasn't sure if it was enabled by default
<chadmed>
DmitrySharshakov[m]: yeah the idea is the kernel driver passes off a device with a "here is 6 codecs, nothing you do could ever blow them up" and the rest should be entirely up to us
<chadmed>
sound quality, "niceties" like filtering out subsonic frequencies etc is not the job of the kernel
<chadmed>
i already have an aggressive rolloff under 20hz in the DSP and it works absolutely fine, the codec should only do DC protection and the 800hz HPF on the tweeters because those are safety guarantees
<DmitrySharshakov[m]>
chadmed: Exactly. So 2Hz for woofers, 800 to tweeters and we're safe. Then WirePlumber should do the "niceties" and automatic stuff
<chadmed>
yep exactly
<DmitrySharshakov[m]>
So then I'm awaiting for initial testing/review for my WirePlumber MR and maintainers' response on the file access thing to improve further
<povik>
this boils down to allocating admac-usable buffer
<povik>
chadmed: you know more why it fails?
<chadmed>
i assume its trying to allocate that buffer before admac is fully alive
<chadmed>
but im not so sure, it can repro it continuously by unloading and loading snd-soc-apple-silicon
<chadmed>
but if i unload then load apple-admac and then do the same, it allocates successfully
<chadmed>
so maybe admac is being put in a bad state on init?
<povik>
ah
<povik>
12:38 < chadmed> i assume its trying to allocate that buffer before admac is fully alive
<povik>
not sure that can happen. by that point we have requested admac channels so i would assume it's been fully probed
<marcan>
does anyone have the pkg file for grub-2.06.r261.g2f4430cc0-1 lying around? I'm pretty sure yesterday's update broke stuff... (still boots, but the unicode menu is very borked)
<marcan>
I *think* it's throwing up an out of memory followed by "no suitable video mode found", so I'm going to guess something about the hidpi screen breaks it...
<marcan>
(and then it falls back to the uboot text console, which isn't... great)
<povik>
but maybe it's best you try after it makes it's way into asahi
<povik>
i have few loose ends to tie, then it should be ok to merge
<chadmed>
yeah at this point i just want to confirm if its something on my end and im just going insane or something
<povik>
my guess is it's indeed a timing issue manifest when loading modules
<povik>
which i don't do
<chadmed>
ah do you have everything built in
<povik>
yup
chadmed_ has joined #asahi-dev
<kazukih[m]>
Everything? Including the firmware?
isoriano has joined #asahi-dev
* j`ey
builds the firmware in
* povik
did build in the firmware at some point
chadmed_ has quit [Remote host closed the connection]
<kazukih[m]>
Hm, doesn't firmware loading break if you inline modules unless the firmware is also inlined as well?
<povik>
don't think so, i don't need firmware for audio testing though
<kazukih[m]>
Huh weird, last time I inlined everything graphics/wifi/bt broke
<kazukih[m]>
Which was fixed by inlining the firmware
chadmed_ has joined #asahi-dev
<marcan>
graphics does not depend on any firmware
<marcan>
wifi/bt does
<povik>
okay, hpf works. it's audible on the woofers under pink noise
<marcan>
HID on M2 does but does deferred loading, so it will still work
<marcan>
so really just wifi/bt
<marcan>
you don't need to embed it, putting it in the initramfs is enough
<marcan>
I have an initramfs with just firmware lying around for this purpose
<kazukih[m]>
I see, thanks
<kazukih[m]>
marcan: I meant on my Intel machine
gabuscus has joined #asahi-dev
gabuscus has quit []
gabuscus has joined #asahi-dev
gabuscus has quit []
chadmed_ has quit [Quit: Konversation terminated!]
gabuscus has joined #asahi-dev
gabuscus has quit []
chengsun has quit [Quit: Quit]
chengsun has joined #asahi-dev
gabuscus has joined #asahi-dev
gabuscus has quit []
benpoulson has joined #asahi-dev
gabuscus has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
* amarioguy
amarioguy attempts to figure out if i2c should be a patch series or one giant patch
<povik>
one 'giant' patch
<povik>
it's small, really
bisko has joined #asahi-dev
qcyrdqcpzg[m] has joined #asahi-dev
<amarioguy>
sven - figured i'd give a status update, we boot to userspace successfully now without issue after fixing the enable/disable bits, some minor pointer issues and not being an idiot and forgetting to init the completion for the first time (that last one hung me up for some time lol)
<marcan>
I guess "vmlinuz" is a lie at this point, not sure if that should be something else, but shrug
<marcan>
I should look at how Arch does it
<whynothugo>
Oh, nice. I've been using systemd-boot, but have been manually decompressing during installation till now.
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
need to see if kettenis would take patches to improve the u-boot console, because that is *very* broken right now
<marcan>
(and systemd-boot inherits it)
<j`ey>
marcan: how so?
<jannau>
does anyone uses uncompressed images on x86? handling is easier there due to self decompression code
<marcan>
graphic drawing characters confuse it, it has terminal size confusion / scrolling issues (grub without gfx mode ran into this too), and also the keyboard is flaky at least on my m1pro
<marcan>
to the point I need to type character by character and make sure it worked
<whynothugo>
I was going to point out that `bootctl status` is a reliable way to find the ESP mountpoint, but `--json` doesn't work.
<whynothugo>
Any thoughts on tow-boot marcan? It usually targets phones a bit more, but might not be terrible here.
<marcan>
doesn't sound like it fits our model
gabuscus has quit [Ping timeout: 480 seconds]
<whynothugo>
It does work somewhat as a staging for upstreaming to u-boot in some aspects.
<whynothugo>
But I guess it's a stretch for this case.
<jannau>
we do not really have problems getting things into u-boot upstream and we have our own fork anyway
gabuscus has joined #asahi-dev
<jannau>
I still need a see if there's a nicer way to handle the blessed ESP than the way we do it currently
<tpw_rules>
systemd-boot has always worked okay for me on nixos fwiw, but yeah the graphic characters do show up funny
<tpw_rules>
except for the blessed ESP, doesn't tow-boot fit the "just install UEFI" model pretty well?
<marcan>
what does it offer over regular u-boot? the website makes it sound like it's intended to be "board firmware".
<tpw_rules>
yes, that's the point. it's intended to be a standard firmware experience like UEFI firmware is on x86 systems. the big things it offers are a consistent UX and graphical device selection
<tpw_rules>
i don't know if it's ultimately feasible for reasons like the ESP being married to the macos stub, but it seems like an ideal thing for the "just give me UEFI pls" option in the asahi installer
<tpw_rules>
and the eventual "asahi isn't a distro" target. though maybe you always intended to offer a unified installer
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
Looks great! Why 400 Hz as corner frequency? Tweeters are intended for 2 kHz+ playback, so setting corner to 800 Hz effectively cuts off more. Or is 400 fine as well and you gave more freedom to userspace without introducing safety risks?
<povik>
nah, that's just me misremembering the maximum when i wrote it
<povik>
let me fix it to 800 hz right away
<povik>
pushed
<DmitrySharshakov[m]>
Cool. I hope the WP config snippet I sent does work properly.
<povik>
didn't get the chance to try it yet
<povik>
still some work on preparing the kernel side for new merge
<DmitrySharshakov[m]>
Getting everything rebased on top of 6.0 etc?
<povik>
yeah, but mostly getting my wip stuff in shape
<povik>
there's been architectural changes and new features
<povik>
and the old code merged in asahi started conflicting with pieces upstream
<amarioguy>
alright sven just sent the patch email, hopefully i didn't screw up too awfully
* povik
refreshes mailbox
<amarioguy>
first time i used git send-email lol
<amarioguy>
well it's on lore, with the right names and all (though the lack of email addrs may be because i use outlook)