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]>
<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>
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 ;-)