robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
jglathe has quit [Ping timeout: 480 seconds]
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
<steev> rc8 is out, i'm assuming because of the holidays?
<broonie> steev: Yes, that was the preannounced plan - the idea is to do the release next week.
<steev> ah
<steev> i miss those :D
<steev> i'm not on the actual list
paddymahoney has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<clover[m]> Happy new year
<steev> happy new year sir, or ma'am
<HdkR> /8
paddymahoney has joined #aarch64-laptops
paddymahoney has quit [Remote host closed the connection]
paddymahoney has joined #aarch64-laptops
matrix638[m] has joined #aarch64-laptops
jglathe has joined #aarch64-laptops
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
f_estive is now known as f_
f_ has quit [Ping timeout: 480 seconds]
f_ has joined #aarch64-laptops
f_ has quit [Ping timeout: 480 seconds]
f_ has joined #aarch64-laptops
f__ has joined #aarch64-laptops
f_ is now known as Guest12521
f__ is now known as f_
f_ is now known as funderscore
funderscore is now known as f_
Guest12521 has quit [Ping timeout: 480 seconds]
<Bioxvirizm-x13s[m]> HNY!=)
f_ has quit [Remote host closed the connection]
<Jasper[m]> craftyguy, at first glance, iwd does seem to be somewhat better at switching AP's. Not perfect yet, but NetworkManager is now reporting more than a single bar of signal and it's connected to something other than the one wifi6 ap in my house
<Jasper[m]> @jhovold I recopied the configs for good measure, stopped alsa-state.service. removed /var/lib/alsa/asound.state and rebooted
<Jasper[m]> speakers are now crackling but properly amped, headphone jack still blasts too loud
<Jasper[m]> Opening Chromium froze the laptop, had to reboot and now sound is entirely broken: https://paste.centos.org/view/33c9db6c
<Jasper[m]> Safe to say it's not having fun
<Jasper[m]> <Jasper[m]> "speakers are now crackling but..." <- the former is a problem with firefox and pipewire, chromium works fine
f_ has joined #aarch64-laptops
f_ has quit [Remote host closed the connection]
f_ has joined #aarch64-laptops
<exeat> This seems to eliminate the speaker crackling on pipewire for me: "pw-metadata -n settings 0 clock.max-quantum 1024". It clamps the quantum range to 32-1024 (from the default 32-8192 IIRC).
<exeat> To unclamp use a 0 value; to persist see end of https://wiki.debian.org/PipeWire
<exeat> I haven't investigated enough to understand why _higher_ quantum sizes (more relaxed latency) give choppy audio...
<exeat> Maybe something to do with pipewire's timing approach, the alsa pcm's period size and batch property (and pipewire's treatment of batch devices), some bug in the driver...
<exeat> (I say this because it kind of sounds like unplayed samples are overwritten.)
<exeat> Anyway, I suspect that the reason why you hear crackling with firefox and not chrome is that chrome uses a small enough audio buffer to force pipewire to quantum <= 1024, while firefox uses a larger buffer and allows a higher quantum (should be visible in pw-top).
<exeat> If so, you should be able to get non-choppy audio from firefox while playing silence with chrome (because pipewire would then use a smaller quantum to satisfy the lower-latency client).
<jglathe> any idea why sound appears to be the most complicated thing in programming?
<steev> because it is complicated
Ablu has quit [Read error: Connection reset by peer]
Ablu has joined #aarch64-laptops
embr has joined #aarch64-laptops
<Bioxvirizm-x13s[m]> <steev> "because it is complicated" <- Why? :)
embr has left #aarch64-laptops [#aarch64-laptops]
<steev> i'm not smart enough to know why, but someone like broonie could possibly explain it (not meaning to actually ping him)
<jglathe> I'm just baffled. Anyway, Happy New Year everybody.
<exeat> Low frequency signal processed by ubiquitous commodity hardware, driven by software...
<exeat> Which can further process it in a myriad ways to amuse the monkey brain :)
<broonie> You’re doing analog/digital conversion and usually trying to do things with minimal latency which means you can start stressing scheduler stuff if you push hard, or run on a system vastly different to the one you tuned for.
<broonie> Also there’s a bunch of different ways of building the hardware which sometimes surprises people.
<broonie> Plus there’s UX stuff where people expect things like headphone jacks to behave in one way or another but that one way can be different in different situations
<jglathe> okay... just noticed that the sound driver stack was way deeper than any other stuff. That has changed a bit (everything is complex now), but it was striking.
<jglathe> and config of it is opaque.
<steev> clover[m]: pushed out lenovo-x13s-v6.7.0-rc8, it's the rc7 stuff, on top of rc8
<broonie> jglathe: graphics is similarly complex really (for similarish reasons)
<jglathe> I would expect it for graphics
<robclark> we just had a big head start on gfx.. 10yrs ago it would have been equally broken ;-)
<Bioxvirizm-x13s[m]> robclark: So-so perspective :)
DigitalPirate[m] has quit [Quit: Client limit exceeded: 20000]
ungeskriptet is now known as Guest12554
ungeskriptet has joined #aarch64-laptops
Guest12554 has quit [Ping timeout: 480 seconds]
<steev> clover[m]: also pushed 6.6.9