<chadmed>
turns out pipewire actually ignores asound.conf and opens a direct port to the hardware by default, unless you specify in its own configuration that it should use an already defined ALSA PCM as its default sink
<chadmed>
problem with this is that it does not work with ALSA PCMs that route through LADSPA plugins, pipewire expects you to create a virtual pipewire sink to do that (again in its own config), link that to a "coupled" sink (a source-sink passthrough in pipewire) and then feed that directly to hardware
<chadmed>
and the problem with THAT is that pipewire opening direct ports to this driver somehow breaks pipewire-pulse, which is what has caused mpv and VLC to explode. the failure mode is similar to if you disable resampling in vanilla pulseaudio so im thinking pipewire is not telling pipewire-pulse to do it or something
<chadmed>
the other shit thing is that REW or Java relies on some stuff llvmpipe cant do and so its GUI breaks on launch, which makes it basically impossible to get well-calibrated response curves for the drivers. doesnt matter anyway, since plugging in my interface to use the calibration mic makes the internal speakers unusable :)
<chadmed>
its been a really fun morning
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
PaterTemporalis has quit [Ping timeout: 480 seconds]
<psykose>
that sounds incredibly fun indeed :)
kov has quit [Quit: Coyote finally caught me]
nepeat has quit [Remote host closed the connection]
nepeat has joined #asahi-dev
bpye has quit [Quit: Ping timeout (120 seconds)]
linuxgemini has quit [Quit: Ping timeout (120 seconds)]
kode54 has quit [Quit: Ping timeout (120 seconds)]
KDDLB has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #asahi-dev
bpye has joined #asahi-dev
nkaretnikov has quit [Read error: Connection reset by peer]
linuxgemini has joined #asahi-dev
robher has quit [Remote host closed the connection]
<marcan>
kettenis: I'm working on extracting out the DTs so we can package those separately, ideally automatically from the asahi branch
<marcan>
I'll merge that compat hack into asahi for now
<marcan>
is there anything else you need DT-wise?
WindowPain has quit [Remote host closed the connection]
skipwich has quit [Quit: DISCONNECT]
tardyp has quit [Read error: Connection reset by peer]
KDDLB has joined #asahi-dev
skipwich has joined #asahi-dev
tardyp has joined #asahi-dev
nkaretnikov has joined #asahi-dev
erincandescent has quit [Quit: No Ping reply in 180 seconds.]
robher has joined #asahi-dev
WindowPain has joined #asahi-dev
erincandescent has joined #asahi-dev
<marcan>
chadmed: hey, I once REWed through a JACK to network to ffmpeg bridge to get an impulse response of my smartphone, there's always a way :D
<marcan>
the bus routing in that Ardour project was... interesting
<chadmed>
marcan: that sounds... interesting... heh
<chadmed>
ive got everything routing through JACK (pipewire and pulse are both happy to act as clients to it) so it doesnt fall apart when i plug my interface in, so i can now either use REW remotely by waypipe-ing Xwayland to my main machine or get a 24/96 WAV of a log sweep and just play that via aplay to each driver and use the calibration mic through another machine with known parameters
<marcan>
kettenis: how are you handling AIC in the end?
<marcan>
chadmed: cool!
<marcan>
chadmed: and yeah, my standard setup these days is JACK behind everything for my main interface, though I hope to move to pure pipewire in the future
<marcan>
JACK itself has a lot of problems pipewire fixes, but pipewire also has a lot more complexity... :-)
<marcan>
chadmed: mind if I try to start some conversation on the EQ story in #pipewire?
<chadmed>
by all means
<Jamie[m]1>
is it worthwhile/annoying to fix typos in drivers? apple-admac.c says "dmaegine" in a comment
<chadmed>
i think it is, but not if its the only thing youre committing (unless theres a whole mess of em)
<marcan>
jannau: that's not upstream yet, so just letting povik know is probably easiest
<marcan>
chadmed: ideally at +∞ gain (it's supposed to be a 1bit song before the lossy compression :D)
<marcan>
might be a good speaker torture test once we have filters/safety limits
<marcan>
I might actually be willing to sacrifice one of my (AppleCare'd) laptops to that once we're reasonably confident it's *mostly* safe for normal audio...
<chadmed>
it would definitely make a good "do not try this at home" demonstration :P
darkapex1 is now known as darkapex
dsrt^ has quit [Remote host closed the connection]
<chadmed>
huh ok so the crossovers and EQ i set by ear are pretty much exactly where they need to be :D
<marcan>
nice
<marcan>
I really want to know wtf macOS is doing now then, if only to figure out why it sounds worse :p
<chadmed>
sounds to me like theyre expanding the mids. one thing it does better though is the tightness of the bass response. its pretty dead under linux regardless of what i do with the EQ, which makes me think theyve got some funky phasing going on to overcome standing waves set up in the chassis
<marcan>
that wouldn't surprise me, yeah
<marcan>
would be good to take a look at the impulses once we capture them
gladiac has joined #asahi-dev
tanty has quit [Remote host closed the connection]
<marcan>
from macOS I guess the interesting bit is going to be the group delay in the lows, though we ought to be able to work out a good solution for that with just those impulses, right?
<chadmed>
im hoping so. i want to see what happens when i apply them to the drivers as is using brutefir or something similar
<chadmed>
hopefully some magic
<marcan>
I imagine you might want to smooth out the response in the mid-highs, since otherwise you're going to end up over-correcting for a very specific position
<marcan>
(and also it's not a head model measurement, so will be slightly off from a normal listening position in that sense)
<bluetail[m]>
how is that behaving individually on each m1 machine?
<bluetail[m]>
mac mini m1 vs m1 laptop might have different acoustical properties
<chadmed>
yeah this is going to have to be a per-machine thing
<chadmed>
im just using the j314s as a proof of concept and to establish a process going forward for new machines
<chadmed>
the hardest part is forging the path
<chadmed>
that said i dont really have the money or time to do this for each and every new machine that comes out, as much as id love to :P
<bluetail[m]>
Do you think apple does this real-time, following a harman curve?
<chadmed>
its the only way to do it lol
<bluetail[m]>
you make it sound so obvious (laughs)
<chadmed>
audio signals are time-dependent, theres no such thing as non-real-time DSP
<chadmed>
well i mean, if youre driving speakers live that is
<chadmed>
of course you could apply an EQ curve to a file or something, but if the output of your filters is going to speakers, you can only really do it as the samples arrive
<marcan>
chadmed: your setup is probably better than mine, but I can run this on all the machines once we have a process and cross-check against your results for j314s
<marcan>
I've been meaning to acoustically treat this room properly anyway... might be a good excuse to finally do it soon
<bluetail[m]>
And it is easy to install. I have it in white.
<bluetail[m]>
4 screws into the ceiling, then pull on the 4 wires to lift it. Done.
<bluetail[m]>
its lightweight, and if it comes off, you aren't dead. I have other absorbers that would certainly kill me if they drop down at night
<marcan>
I don't have any problems with external noise in either direction, I just want some wall treatment to reduce reflections
ChaosPrincess has joined #asahi-dev
<jannau>
oh, dcp already blanks the mac book pro display, that was not working for the HDMI display on the mini
<jannau>
marcan: do you have a todo list for the release? if you're not working on it I can adapt the ESP uuid matching to passing the uuid in chosen
<marcan>
jannau: in u-boot you mean?
<marcan>
that's on the list indeed
<jannau>
yes
<marcan>
also it would be useful to have two scripts: one that boots the ESP as specified in the DT, and one that explicitly does *not* and instead prioritizes USB devices
<marcan>
for rescue purposes
<marcan>
I'm looking into the DT filtering; seems to work fine, with the state branch a re-filter only takes a minute including all the pulls/merges/mangling involved
<marcan>
so I'm going to try to turn it into a GH action so we have fresh DTs updated when asahi gets pushed
<jannau>
my hack did both, it tried first to find the specifed partition and if that was not found it falled back to any bootable partition
<marcan>
yeah, that works fine but it'd be nice to have one that explicitly goes for USB first, then NVMe
<marcan>
so users can use that as an explicit override
<jannau>
ah, so something an user would invoke manually from u-boot's command line. there might be already a boot_usb in the distro boot scripts
<jannau>
and fail if the specified esp uuid is not found
<j`ey>
doesnt it currently check USB first?
<j`ey>
oh no, nvme first
<kettenis>
the idea is that once you've installed on nvme you don't want it accidentally boot from usb just because someone plugged in a usb stick of some sorts
<marcan>
yup
PaterTemporalis has joined #asahi-dev
<marcan>
I'd say the default behavior should be specific ESP -> USB (ignore other ESPs in NVMe, always, to avoid confusion)
<marcan>
and the explicitly invoked recovery script should be USB -> any ESP in NVMe
<marcan>
(if no ESP is specified in /chosen then it should just pick the first though)
chadmed has quit [Read error: Connection reset by peer]
<kettenis>
marcan: fixing the aic2 issue in the OpenBSD driver in a way that works with the old DT comes kinda natural, so don't worry about tweaking the DT
<marcan>
ah, ok, I thought you wanted to keep compat with old drivers
chadmed has joined #asahi-dev
<marcan>
it'd be easy to do on linux too but I just want to rip off this bandaid for us :) (since I'm not promising anything yet)
<marcan>
compat hacks like that will start happening after first release if we need them
<kettenis>
I think there is only one m1 pro/max user besides me ;)
<marcan>
:)
<kettenis>
a few more folks with m1
<mps>
I'm still to idea that if USB is plugged in on boot to use it as boot device
<mps>
if someone wants protected filesystem on nvme then FS should be encrypted
<marcan>
on modern machines you don't normally expect USB to take over boot unless you explicitly set it as such
<kettenis>
marcan: so basically what I did is that for AIC2 I use bus_space_map(9) to map the event register (since it is now separate) and for AIC1 I use bus_space_subregion(9) to carve out the event register
<jannau>
nothing prevents you to place an ESP with a specified uuid on a usb drive, the installer doesn't support that at the mement
<kettenis>
adding code for AIC2 to carve out the event register with bus_space_subregion(9) isn't a huge burden, so that's what I went with
<marcan>
or can get u-boot to read configs from the ESP and then you can override whatever there
<marcan>
kettenis: yeah, I just point two iomem pointers at different or same maps, and the error cleanup code unmaps the event one if they aren't equal
<marcan>
and then I already had an offset, that's just 0 for AIC2
<mps>
jannau: for me personally this is not preoblem, I can change and build m1n1 and u-boot but not sure for end users
<kettenis>
anyway, back to u-boot, there are several problems here:
<kettenis>
u-boot is really device-oriented; so distroboot iterates over devices trying to boot from them
<kettenis>
currently I don't enable persistent u-boot environment support, but when we do that the only really viable option is to store the u-boot environment in a file on "the" ESP
<marcan>
yeah
<kettenis>
although in this context ESP is probably the wrong term
<kettenis>
since this is code that doesn't know anything about EFI
<marcan>
we could enable persistent environment, and use that to allow users to override actual boot behavior from the ESP (where "the" has to be the /chosen-specified one)
<kettenis>
it is just "a" partition with a filesystem that u-boot understabds
<kettenis>
then there are the EFI variables, which are enabled and if you set one using bottime services, it will put them in a file on the ESP
<kettenis>
making that pick "the" ESP will require some actual code to recognize the /chosen-specified one
kov has joined #asahi-dev
<kettenis>
the code in u-boot that picks "the" ESP lives in lib/efi_loader/efi_disk.c:efi_disk_add_dev()
<kettenis>
currently that picks the first one
<kettenis>
but changing that to pick the first but override it if we find the one designated by /chosen shouldn't be too hard
<kettenis>
but I do expect some pushback on such a change
<kode54>
I use two unifi devices that use uboot
<kode54>
/offtopic
<marcan>
ok, I set up the devicetree repo but I don't think updating from a GH action is going to work, you really need the repos to already be fetched to have it finish in a reasonable time
<marcan>
so I'll have to set up some local builder or something at some point
<marcan>
I guess I'll update manually for now, at least it's all scripted
amarioguy has quit [Remote host closed the connection]
<tmlind>
for me macbook air m1 wlan stopped working with the rc7 kernel, got brcmf_pcie_init_ringbuffers: Allocating ring buffers failed
<j`ey>
tmlind: youre using a 4k kerel without the iommu patch?
<tmlind>
j`ey: ah that's probably it, i forgot to reapply after it produced some conflicts..
<chadmed>
ok change of plans for the IRs -- im going to sample just L and R, with the crossovers applied and use those samples to build an IR. trying to apply 6 at once explodes ALSA and pegs a whole core
<chadmed>
i'll do that tomorrow though, now that i have a flow that works its quick and easy to do stuff
<chadmed>
applying just two of the IRs makes a significant difference though, so we've made progress at least
<jannau>
notchless dcp display that was simpler than expected. not correcting the physical dimensions so technically non-square pixels but the physical dimensions are not reported in wl_output
<jannau>
fbcon doesn't work though
<tmlind>
j`ey: yup that was it, thanks
<tmlind>
seeing a m1n1 issue after update though with standalone kernel after updating from about a week ago
<tmlind>
looks like kernel cmdline is no longer getting passed? don't have debug cable to connect to a pc
<tmlind>
commit d76f3a66318f ("m1n1.hw.DART: coalesce continuos l2 ptes") works, have not bisected
<jannau>
tmlind: the format changed: use 'chosen.bootargs=...'
<j`ey>
tmlind: you need to use chosen.boo..
<tmlind>
heh ok :) thanks for the fast reply
<j`ey>
0a8a593cdc1aead31ad9e1cfb0e589610a218ef5
* tmlind
goes to hold the power button again
<j`ey>
tmlind: btw you can use a normal USB C-A cable with m1n1
<tmlind>
j`ey: ok great, don't seem to have one right now..
<kettenis>
jannau: I'm looking at fixing the u-boot dynamic addresses
<kettenis>
is there any reasoon you put scriptaddre and pxefile_addr_r near the top of the address space?
<jannau>
kettenis: not really, I looked at other board files and thought that way they are at least of the way
<marcan>
povik: so when lw1 borks, the overcurrent IRQ flag is set and the SAR ADC measurements are invalid
<kettenis>
my idea is to make it use the lmb stuff that's also used to do the allocation when you actually load stuff
<j`ey>
kettenis: thank you for fixing that
<povik>
marcan: are you sure the it's the overcurrent? i thought the IRQ flag was reserved
<marcan>
0x49 bit 2 is IR_OC
<povik>
let's see
<povik>
ah i was looking at something in the live registers
<povik>
didn't catch 0x49
<kettenis>
just need to pick some reasonable sizes for the generic load area (loadaddr) and the ramdisk area (ramdisk_addr_r)
<kettenis>
but maybe 1G for those is a reasonable number
<marcan>
povik: that bit is the only one that consistently predicts if it's broken or not
<povik>
ok
<povik>
check if apple configures OCE_RETRY, they don't
<povik>
*checked
<marcan>
honestly this datasheet kind of sucks
<kettenis>
we know we have at least the best part of 8G on these machines so as long as m1n1 doesn't carve it up in silly ways using 1G chunks for those should always fit
<marcan>
"Certain limitations applied. Contact TI if need to use this bit.
<marcan>
lol.
<marcan>
looking at a datasheet for a similar part, these errors are latching
<marcan>
and the retry timeout is 1.5 seconds which kind of sucks
<marcan>
so the question is when does the error happen
<kettenis>
if folks can give that a go it would be great
<j`ey>
kettenis: thanks I will try that in a bit
<povik>
marcan: could be i send some garbled samples at the start!
<povik>
you should be able to test it by adding a delay before the codecs are unmuted
<povik>
i think the DMA stream and all should be set up by that time
<povik>
there's a FIFO i tried to drain with mca_flush_adapter_fifo in mca.c
<povik>
but i can't claim to understand it (hence why it's disabled)
<povik>
although if it really was a case of garbled samples, then why does it happen even at low gain (if it does)
<marcan>
oh heh, this time I got some weird noise instead of death
<povik>
been there
<povik>
'clicks'
<marcan>
it was more like a buzz
<povik>
huh
<povik>
this is a mystery noise machin
<povik>
*machine
<j`ey>
kettenis: booted 3/3 times. I only booted about 1/10 before, so I'd say that's fixed
<jannau>
kettenis: thanks for taking care of this, maybe use a define for kernel_comp_addr_r / kernel_comp_size
<marcan>
povik: I'm adding debug and yeah, it seems sometimes when it first powers up it goes into overcurrent mode and auto shuts down, but only on that one channel. will keep probing...
smartmobili has joined #asahi-dev
smartmobili has left #asahi-dev [#asahi-dev]
nametable[m] has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
balrog has quit [Quit: Bye]
balrog has joined #asahi-dev
gabuscus has quit [Ping timeout: 480 seconds]
<Glanzmann>
About the u-boot discussion today, having a live system is really handy, but if someone screwes up the device tree, than you need to boot to u-boot. m1n1 probably never get keyboard support (or power button press detection supprt) in order to chainload from usb instead of nvme?
<Glanzmann>
s/to u-boot/macos or 1tr/
<tpw_rules>
i wonder if extlinux.conf support could be put in m1n1...
<sven>
I mean, you can always go to 1TR and go from there or just install a second “boot to usb stub”
<sven>
and end users really shouldn’t be messing with device trees anyway
<mps>
tpw_rules: this will need practically complete u-boot in m1n1
<mps>
maybe add fallback u-boot in ESP in m1n1
<Glanzmann>
sven: And hopefully the device tree is stable enough now that you get basic hardware support (screen, keyboard, nvme, wifi) to fix things
<mps>
so have one tested that work as fallback and one for testing
<mps>
but have no idea how to implement this
<sven>
no guarantees about dt stability before the release except for stuff that’s been upstreamed
<mps>
yes, for now go to 1TR and install m1n1+dtbs+u-boot which works in case of install messed u-boot in ESP
<marcan>
any chance that it *always* does 82 -> 80 -> 81 instead of 82 -> 81?
<marcan>
because I can fairly reliably repro the fail by looping unbind -> rebind -> fast speaker-test 4 times, and after making it always do ACTIVE before MUTE, it seems reliable
<marcan>
pushed, along with the other fixes, to audio/testing
<marcan>
also in today's "the kernel is a pile of race conditions and we should all switch to Rust some day", reading /sys/kernel/debug/regmap/*/registers while the regmap is being destroyed crashes the kernel
<kettenis>
well, exposing arbitrary hardware registers through a pseudo-filesystem like that is just dumb
<marcan>
it's debugfs, it's for debugging
<marcan>
and IIRC it's gated under a .config option
nepeat has quit [Remote host closed the connection]
nepeat has joined #asahi-dev
<marcan>
povik: oh yeah, thought: we should remove the fallback compatibles from the amps in the DT, as a gate for making sure whatever safety stuff we come up with is merged first and nothing comes up on kernels without it
<povik>
sounds reasonable
<povik>
though i don't know about tas2770 yet
<povik>
if we should drop that and start using tas5770
<kettenis>
as far as I can tell the chip is 100% compatible
<povik>
yeah, that's why i don't want to switch to a new compatible to gate on safeties there
<povik>
but they may not be as important as they are with the tas2764-like part
<Glanzmann>
Maybe I should add a script that lets you modify the live system and write it back to the initrd on the usb stick.
gladiac has quit [Quit: k thx bye]
___nick___ has quit [Ping timeout: 480 seconds]
snnw[m] has joined #asahi-dev
shenki has quit [Remote host closed the connection]
ChaosPrincess has quit [Remote host closed the connection]
axboe has quit [Remote host closed the connection]