ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
KxCORP589 has quit [Quit: Bye!]
KxCORP589 has joined #asahi-alt
jeisom has quit [Ping timeout: 480 seconds]
pedantic_picto has joined #asahi-alt
Mik_ has quit [Ping timeout: 480 seconds]
KxCORP589 has quit [Quit: Bye!]
KxCORP589 has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
pthariensflame has joined #asahi-alt
pthariensflame has quit []
opticron has quit [Ping timeout: 480 seconds]
<mps>
nice work! asahi-audio 2.1, wireplumber 0.5.2, pipework, latest kernel and latest m1n1 works fine on m1pro (j316s) with alpine linux. thanks all for good works
<mps>
s/ pipework/pipewire 1.0.5/
<chadmed>
mps: interesting, the only fix between 2.1 and 2.0 was for j416...
<chadmed>
oh btw sam_ if you're keeping track we're no longer a blocker for wp 0.5 so you can take us off the list :)
<chadmed>
now just for *checks notes* literally everything else
<mps>
chadmed: yes, but anyway thank you for fix
<leio>
chadmed: he hopes you and/or me can take on the bump and dealing with it all
<chadmed>
do we have a specific channel for that kind of thing
<leio>
not really, no; could be #gentoo-dev (might need to voice you) or #gentoo-desktop or even #gentoo-arm.
<leio>
maybe desktop is suitable enough.
<leio>
I think mainly it's about knowing what might break, and if some users might need manual migration work, writing a news item for review
<chadmed>
for a vanilla install the only thing that's gonna break is our oddball USE="sound-server" mechanism
<leio>
you probably know most what could be affected; I guess users that have done asahi-audio kind of stuff manually on non-asahi (doubtful such exist?) and maybe someone having used some tooling that does something of that sort via a GUI if such exists? I think easyeffects is doing something else
<chadmed>
for users that are doing weird things they're just gonna have to be on their own and we can write a news item directing them to the porting documentation
<chadmed>
easyeffects doesnt rely on custom config afaict but when 0.5 first dropped a number of folks popped in to #pipewire to voice their disappointment that their funky little scripts no longer worked so i assume we have more than one person who would break
<leio>
so maybe beyond asahi-audio, there's no concerns beyond those that have done scripts manually, which we'd cover with a news item
<leio>
I think wireplumber would be more about stuff like helvum or whatwasit than easyeffects?
<chadmed>
i believe both helvum and qpwgraph talk to libpipewire directly
<chadmed>
yeah it links against libpipewire
<chadmed>
nothing even depends on wireplumber
<chadmed>
waybar and pipewire are the only things in ::gentoo
<chadmed>
ok nvm there are no explicit blockers at the ::gentoo level so i'm going to throw wireplumber 0.5 at ::asahi and see who comes knocking about breakage
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
ah- has quit [Read error: Connection reset by peer]
ah- has joined #asahi-alt
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
chadmed has quit []
chadmed has joined #asahi-alt
Mik_ has joined #asahi-alt
<mps>
iirc someone wrote earlier that is possible to lock (pin) wireplumber to icestorm to get better perfomance. I searched backlog but can't find this explanation
<mps>
anyone could tell how to do this
<chadmed>
enable UCLAMP_TASK in your kernel config
<chadmed>
our wireplumber and pipewire config fragments do the rest
<mps>
chadmed: I enabled it long ago
<chadmed>
oh then youre fine no further action is required
<mps>
thanks for info, but I hear 'cracks' sometimes especially when there is heavy I/O
<chadmed>
oh you mean actual performance
<chadmed>
well pegging wireplumber to icestorm isnt gonna fix that, firestorm are the pcores
<chadmed>
heavy i/o is suspect though, the cores should handle it
<mps>
ah, yes, I meant to say firestorm
<chadmed>
what source are you listening to and what is "heavy io"
<mps>
heavy i/o is usually building software
<chadmed>
sus as
<mps>
kernel, for example
<chadmed>
im building firefox on an m2 air right now and watching 1440p youtube
<chadmed>
and not a single audio underrun
<chadmed>
ah
<chadmed>
ah ah ah
<mps>
sources are usually video/audio from internet and playing locally with 'mpv'
<chadmed>
does alpine list rtkit as a dependency of pipewire/wireplumber
<mps>
let me check
<mps>
no
<mps>
so I should install it, I guess
<chadmed>
ah yeah lol so the uclamp stuff and the rtprio stuff isnt gonna do anything in that case
<chadmed>
which is why youre getting underruns
<chadmed>
pipewire and wireplumber assume the presence of rtkit to renice themselves
<mps>
just installed it
<chadmed>
prio should be 9 and niceness should be -11 for both pipewire and wireplumber
<mps>
chadmed: nice and thank you very much
<chadmed>
no problem :)
<mps>
btw, how the prio and niceness is set on gentoo? Init script?
<chadmed>
nope, rtkit
<chadmed>
like i said the asahi-audio config tells pipewire and wireplumber to set their own prio and niceness via rtkit
<chadmed>
i added the ability to set uclamp to both a while back
<mps>
aha, so only have to start rtkit and restart pipewire and wireplumber
<jannau>
should asahi-audio or asahi-meta[+audio] (optionally) depend on rtkit? it doesn't yet as far as I can see
<chadmed>
yeah i was just thinking that
<mps>
makes sense
<chadmed>
its marked as an optfeature for pipewire/wireplumber, and i think the only reason it's not a hard dep is that its unmaintained
jeisom has joined #asahi-alt
<leio>
chadmed: in gentoo rt is handled via /etc/security/limits.d/25-pw-rlimits.conf - I'm not convinced that's best.
<leio>
because it gets rtprio on all threads, not just those that pipewire might want
<leio>
sam_ knows more, he's the limits.d proponent :D
<chadmed>
yeah i mean it kinda defeats the purpose because then the scheduler is just gonna treat all user processes the same
<chadmed>
which means pipewire is not any more favoured than anything else and we're right back to where we started
<leio>
I'm not following that part
<leio>
via limits.d pipewire, and only pipewire, is running at nice level -19 and rtprio
<chadmed>
that file sets the limits on the user group, and pipewire is not started by a user in the @pipewire group
<chadmed>
it is started as the logged in user
<leio>
in practice I see -11 though
<chadmed>
yes, that's probably rtkit
<leio>
I might have found the wrong limits.d too
<chadmed>
with rtkit uninstalled pipewire starts with 20 0 just like every other user process
<leio>
elog says to add your user to pipewire group
<leio>
and that's one of the parts I don't like about it
<chadmed>
if i create the @pipewire group and add myself to it, then _every single process_ i start will be started at the limits.d right
<chadmed>
which, again, will just make the scheduler treat all my processes exactly the same
<chadmed>
thereby negating any benefit of bumping the niceness/prio of pipewire
<leio>
I see what you mean.
<chadmed>
i think long term if no one is going to step up and maintain rtkit then pipewire should just stop depending on it
<leio>
but I don't know what limits.d is about
<chadmed>
ive already wired up direct sched_{get,set} into pipewire and wireplumber
<leio>
maybe it just allows the process to increase its priority without giving an error when not root
<chadmed>
so maybe we just push to get rtkit yeeted
<leio>
I'm not sure anyone has even asked heftig what's up
<chadmed>
they have not responded to a single PR or issue in 5 years
<chadmed>
i dont think they're particularly interested in telling us whats up :p
<leio>
I know he's somewhat around in gnome circles
<leio>
or used to be less than 5 years ago
<chadmed>
github profile is still very active
<leio>
regarding limits.d stuff, I'm not sure everything will get that priority; it just might be changing the limits
<leio>
allowing a process to lower the niceness value (higher priority) themselves
<leio>
which is also a bit iffy, as anything could go and start doing it then, not just pipewire
<leio>
but I'm not convinced everything out of the box will just run at highest priority if you add your user to the group
<leio>
but not interested in the re-logins to find out :D
<leio>
I would just unconditionally depend on rtkit and get rid of this limits.d business, but lack some historical context
<leio>
if fedora and co rely on rtkit for all this, I don't see a need to be special in this regard
<chadmed>
yeah sorry i was confidently wrong :p
<chadmed>
it just sets the limits
<chadmed>
but thats also really sus as you said
<chadmed>
i dont mind to hard dep on rtkit it's just already extremely brittle (couple of issues on the repo re build failures and odd behaviour during suspend etc) and clearly no one is interested in maintaining it
<chadmed>
so i think long-term pipewire and wireplumber should also just stop depending on it
<chadmed>
especially now that like i said they can both already just sched_{get,set}
<leio>
on GNOME there's a hard dep on rtkit already too
<leio>
how does the kernel let it? As in, how do those sched_set things work?
<chadmed>
i believe any thread can ask for clamping values
<chadmed>
sched_set will probably return EPERM when trying to renice or set prio
<chadmed>
sched_setattr*
<leio>
GNOME needs to give a higher priority to its input and/or kms thread
<leio>
and apparently pipewire does too
<leio>
(the -11 niceness)
<chadmed>
yeah pipewire needs to so that it's not blocked by some non-interactive thing
<chadmed>
not convinced input or rendering have any particular need to be bumped except on extremely gutless systems but eh
<leio>
this made a huge difference.
<leio>
choppy mouse cursor is a very bad experience
<chadmed>
sounds like gnome is brute forcing its way around something terriffically broken in its input handling then because neither kwin nor plasmashell boost their prio or niceness and ive not once had my cursor hang or drop a frame
<leio>
are you sure? I mean, that's kind of the topic with kwin6 in a way right now :D
<leio>
but it makes sense to do, now that it's a very dedicated small thread, the schedulers used to be particularly bad too
<leio>
that said, I can't spot that thread in my htop right now
<chadmed>
26415 james 20 0 2014816 429072 407712 R 10.6 2.7 11:10.56 kwin_wayland
<chadmed>
20 0
<leio>
there's a -21 0 and a 39 19; rest are 20 0
<leio>
not quite sure what the former number means
<j`ey>
chadmed: you dont use chadmed as a username?
<chadmed>
no that's cringe
<j`ey>
haha
<j`ey>
I dont even know if j`ey is a valid linux username
<chadmed>
my uncle (a windows user) is still baffled why he cant use his name anywhere in the system
<chadmed>
his name is constantine but of course goes by a shortened version of that name
<j`ey>
switch him over to linux!
<chadmed>
im working on it
<chadmed>
granddad's got an m2 mini running F39 now
<chadmed>
baby steps
<j`ey>
jealous
<j`ey>
upgrade that bad boy to rawhide
<chadmed>
ill bump it to F40 on thusday when im over there
<chadmed>
i was originally planning to foist gentoo on him but he was already used to fedora after using it for a few years
<j`ey>
:-)
<j`ey>
this is fun, my test is failing inside a VM, non deterministically
<chadmed>
it would be boring if it was deterministic
<j`ey>
I want it to be boring so I can fix it and send my patches out!
<j`ey>
on friday I was like 'finally get round to sending out v4'
<j`ey>
test in a VM again and see a failure D:
<chadmed>
at least you caught it before sending it
<j`ey>
(also I forgot this was #asahi-alt, not -offtopic, woops)
<mps>
(my granddaughter must be happy because her grandfather runs linux exclusively :-) )
<chadmed>
the utter shame, embarrassment and self-disgust one feels when having to force push like 3 minutes after opening a PR
<mps>
oh, also her grandmother
<j`ey>
chadmed: cant force push to LKML!
<chadmed>
no its even worse there - v4 T16:53:00Z... v5 T16:58:00Z
<j`ey>
hehe
opticron has joined #asahi-alt
zerdox has joined #asahi-alt
opticron has quit [Ping timeout: 480 seconds]
jeisom has quit [Ping timeout: 480 seconds]
john-cabaj has joined #asahi-alt
<chadmed>
sam_, leio: i've pushed media-video/wireplumber-0.5.2:0/0.5, media-video/pipewire-1.0.5-r1:0/0.5 and media-libs/asahi-audio-2.1:0/2.0 to the overlay along with a news item explaining things
<chadmed>
been running wireplumber 0.5 locally for weeks now and tested the subslot change and all resolved correctly
alice has quit [Remote host closed the connection]
opticron has quit [Read error: Connection reset by peer]
opticron has joined #asahi-alt
iyes has joined #asahi-alt
iyes has quit [Ping timeout: 480 seconds]
zzywysm has joined #asahi-alt
john-cabaj has quit [Ping timeout: 480 seconds]
pjakobsson has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-alt
iyes has joined #asahi-alt
kloenk has quit [Remote host closed the connection]
kloenk has joined #asahi-alt
Mik_ has quit [Quit: Leaving]
<jannau>
leio: I've pushed a fix for m2 ultra hdmi audio to asahi-wip. not sure if it is indeed a fix or if it is just a race. no need for testing it's verified already
<jannau>
in the case it's a race, `echo 1 > /sys/devices/platform/soc@2200000000/239b540000.audio-controller/probe_snd_card` should reprobe the sound card and fix it. reconnecting the HDMI plug should fix it as well
xal has quit []
xal has joined #asahi-alt
<jannau>
yes, was just a race
<leio>
jannau: ok, old kernel just goes "dcp-dp-audio 239b540000.audio-controller: audio TX DMA channel request failed: (efault)" on the echo
<jannau>
what do you mean by old kernel? asahi-6.8.8-2 or asahi-6.8.6-4?
<leio>
4
<leio>
haven't spotted a 6.8.8-2 PR ;)
<jannau>
there's a tiny difference between those two kernels: https://paste.centos.org/view/f4da6863 - bringing both sio up in m1n1 wasn't a problem on m1 ultra but I haven't tested that on m2 ultra. possible that the current m1n1 code fails to bring up sio1 on m2 ultra
<leio>
ok, I don't want to test as much as use it; the audio jack is seeing some heavy switching as-is between headset and external speakers
<leio>
but happy to test if I know what; 6.8.8-2 or 6.8.8-2 + a patch?