<jannau>
we alredy have mode parsing code in python but aren't using it
uniq has joined #asahi-dev
<jannau>
before trying to get it work for dcpext I would start with skipping the display initialization in m1n1 and see that dcp.py can bring up the display in that case
<jannau>
I probably have time over the weekend to look at if you don't beat me to it
<sven>
sounds good, i'll first have to figure out a few mmio pokes for this "dpphy" thing anyway
surge9n has joined #asahi-dev
dmmcf has joined #asahi-dev
isoriano has quit [Remote host closed the connection]
surge9n has quit [Ping timeout: 480 seconds]
pjakobsson has quit [Remote host closed the connection]
dmmcf has quit [Quit: dmmcf]
Race has joined #asahi-dev
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
surge9n has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
surge9n has quit [Ping timeout: 480 seconds]
uniq has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
surge9n has joined #asahi-dev
the_lanetly_052 has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
povik: I think my WirePlumber MR for supporting complex audio is now a PoC: https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/412 . It's still not reviewable for upstreaming as might integrate poorly with other policies, but I'd like to see some design review from you and chadmed as people who have came up with the concept.
<DmitrySharshakov[m]>
note 1: you might need git-compiled PipeWire, at least if you unload the DSP chain
<DmitrySharshakov[m]>
note 2: ping me when you check out amps HPF
<DmitrySharshakov[m]>
I want to get a review from usage in a real case. If necessary, I can help adapting existing configs to be loaded by my policy module
Ariadne has joined #asahi-dev
<povik>
DmitrySharshakov[m]: thanks! will check it out
<povik>
working on asahi sound today
<DmitrySharshakov[m]>
Great! Do you also have a mpb with 6-way sound (software crossover necessary)?
<povik>
yes
<povik>
(typing on it now)
surge9n has joined #asahi-dev
<DmitrySharshakov[m]>
awesome :) then it's suitable for testing, let's start with kernel amp settings for protection and then set something up. I could do a draft of config based on asahi-audio repo files and send to you to test. What's your laptop model?
<povik>
j314
<DmitrySharshakov[m]>
and I guess I'll also need pw-dump for it (can be done on any PW version)
<mps>
povik: j314 or j314s? I don't see j314 dts
<povik>
j314s i guess, not sure if the s matters
<DmitrySharshakov[m]>
unrelated question: why aren't there any Apple Silicon hardware info dumps on something like linux-hardware.org? I guess such things should get published for acknowledging people on how is all the stuff exposed to software
<DmitrySharshakov[m]>
Essentially I need pw-dump info for speakers and mics (are they supported with WIP drivers?) locations i.e. how are they labeled by PipeWire's ALSA plugin
<DmitrySharshakov[m]>
But whole paste of it could be decent as well
<povik>
sure, i can send you that
<dottedmag>
DmitrySharshakov[m]: probably because nobody bothered to submit this information? There are just over 150K entries in that DB, which is miniscule compared to the amount of installed Linux machines.
<DmitrySharshakov[m]>
povik: IIRC `s` suffix is M1 Pro and `c` suffix is M1 Max version
<povik>
as i see it it's still subject to change, but it will give you something to work with anyway
<povik>
(^ the exposition to userspace)
<mps>
povik: also I don't know why there is 's', but just wanted to confirm
<povik>
no integrated mic yet
<povik>
DmitrySharshakov[m]: ah okay
surge9n has quit [Ping timeout: 480 seconds]
<mps>
povik: also I have j314s, when you got something I'm ready to test
<DmitrySharshakov[m]>
povik: Yes, you can change those detection preferences later as the driver changes, it's just for me to prepare stuff for you to test
<povik>
great
<mps>
(without PW, ofc :) )
<povik>
haha
<povik>
DmitrySharshakov[m]: in a hour or two i should have linux booted up on the machine and i will send you the dump
<DmitrySharshakov[m]>
povik: Isn't `admac` driver for capturing from it as a part of its functions? What's the roadblocker for internal mic and how is it wired up inside?
<DmitrySharshakov[m]>
povik: That's alright, no need to hurry. Thanks!
<povik>
yes, ADMAC will be in the loop for the mic, but there's other pieces missing
<povik>
while for the speakers and jack you use ADMAC in conjunction with MCA, for the mic you need to involve some other peripherals, which are orchestrated by the AOP coprocessor, at least as macos does it
<povik>
so while we have a driver for ADMAC and MCA, we don't have the AOP stuff
<DmitrySharshakov[m]>
Ah, I've seen a piece of info about some secure disable FPGA which gates the mic access away from SoC. Is MCA something like an I2S port for passing sound data to codec?
<povik>
that's exactly what it is
surge9n has joined #asahi-dev
<chadmed>
DmitrySharshakov[m]: how does policy-dsp automatically attach itself to a "supported" sink, how does it know which devices are supported, and how does it know which filters to apply to which streams
<chadmed>
(sorry if this is meant to be obvious btw, reading lua gives me a splitting headache)
<DmitrySharshakov[m]>
see details under testing section
<chadmed>
yeah cool thats what i thought
<chadmed>
so my next question is do we have to hard code device names into lua scripts for every single supported device
<DmitrySharshakov[m]>
There're rules it uses to bind to nodes based on their and parent devices' properties. Then profile might be switched and filter chain loads (another rule added by such a config hides streams from user)
<DmitrySharshakov[m]>
chadmed: No. Those are not scripts but generic WirePlumber configs
<chadmed>
yeah but if im reading this correctly, it looks for a node specifically called alsa_output.pci-0000_03_00.6.analog-stereo then applies a specific filter chain to it
<DmitrySharshakov[m]>
So we just put a similar file in /usr/share/.../policy.lua.d/51-macaudio.lua and those rules get imported
<chadmed>
right so we go back to my initial question from a couple of days ago, how does this fix the problem long term
<DmitrySharshakov[m]>
chadmed: Precisely this. It can (optionally) also check props of device node belongs to, in case that's important. I'll write a testing j314 config when povik (or you) sends me pw-dump
<DmitrySharshakov[m]>
chadmed: That is a universal format of config, you can have a lot of them and they won't bind to unknown hardware. This should be upstreamable (you just store a ton of those configs in a special dir and WP takes care of loading them as they are needed)
<chadmed>
right yeah cool, im totally fine with doing it like this btw i think i just misunderstood what problem you were trying to solve
<DmitrySharshakov[m]>
What kind of a long-term problem exists? This solves both discovery issue and ones related to exposing nodes (this config can hide underlying ALSA devices as good that no app other than wireplumber could even think there's something special going on, just a stereo sink)
<DmitrySharshakov[m]>
I might have misunderstood the problem you need to solve - if so, I'd like to know and improve stuff :)
<chadmed>
the problem of doing it seamlessly without having to fall back on scripts like this. ideally, PW should just be able to go "this is an xyz device, i will load the DSP from this folder" completely automatically
<chadmed>
like i said i am totally cool with shipping a script since it solves our problem as it stands right now, but personally i think if we standardise on such an architecture it quickly becomes extremely inefficient
<chadmed>
i can just imagine a UCM2-like package, and WP having to recurse over hundreds of lua scripts every time it starts or a device is connected to find the right one
uniq has joined #asahi-dev
<DmitrySharshakov[m]>
And yes, I also added `"device.api":"dsp"` and `"node.virtual":false` props. They're necessary for node to look like a hardware node to PA clients, since some are quite picky like Plasma applet
<chadmed>
my ideal architecture would be a very well defined directory structure such that when PW detects a device, it can just look in one single place (e.g. /usr/share/pipewire/devices/${device_id}) and read only a single manifest that tells it what to do for that specific device
<chadmed>
rather than have wireplumber look through n scripts looking for one with the correct matches = {}
<povik>
but can there be a top script which will tell wireplumber where to look further?
<povik>
then it will be just like UCM
<chadmed>
well yeah, i think i even said in the original issue i imagine it being basically exactly like UCM but actually good
uniq has quit []
<DmitrySharshakov[m]>
<chadmed> "the problem of doing it seamless..." <- "scripts like this" - if you mean policy script, it should fly into upstream WP and just be a part of its code. To add a device you add a config like I described in testing section, which is essentially just a serialized object, not any program.
<DmitrySharshakov[m]>
`/usr/share/pipewire/devices/${device_id}` seems great, well essentially the same since you cannot easily have a simple device ID (it might be necessary to filter by address, nickname etc, not a VID/PID pair). So I guess it would be hard to avoid searching the config in memory
<povik>
not sure i understand the last part
<povik>
you mean there's different ways you identify cards?
<chadmed>
sure, but what i mean is that upstream, WP just has some very basic logic that goes "ah a new device that is called xyz. is there a folder called /usr/share/pipewire/devices/acmecorp/xyz? yes? read the script in that folder. no? expose the sink like normal"
<DmitrySharshakov[m]>
Well, for now I search for nodes by a custom interest descriptor. Config can bind to either node name, node nickname (aka user-readable name), node name + device path
<chadmed>
so i think this proposal is very close but to do it the sustainable and maintainable way will probably require some deeper changes to wireplumber
<povik>
why can't policy-dsp.lua do what you describe?
<DmitrySharshakov[m]>
chadmed: It could be great if we implement a way to serialize names like this. So yes, for higher efficiency we could create such a structure
<DmitrySharshakov[m]>
povik: It can with some extra C APIs
<chadmed>
if policy-dsp can be made to source a further script off a dynamically defined location on disk then yeah it absolutely could
<DmitrySharshakov[m]>
But I'm not sure if searching through, say, 1000 configurations for audio devices each time one is plugged in should be a real trouble.
<chadmed>
well it shouldnt be for these computers but the whole idea is to keep things upstreamable and maintainable
<chadmed>
PW and WP are used in the embedded space, and while you could say "but theyll rip out whatever they dont need anyway" you cant make assumptions like that about other peoples setups
<DmitrySharshakov[m]>
So maybe we'd be better with a more versatile and flexible selector mechanism, which will only improve maintainability
<chadmed>
yeah thats my only suggestion, we just need functionality that can make WP go to the correct place and load a policy from there without just guessing until it stumbles on the right one
<chadmed>
that way the upstream burden is greatly reduced and vendors can package up their own DSP suites and be sure that they can just dump them in a known location and it will work for the user
<chadmed>
ill get that pw-dump for you in just a second
<DmitrySharshakov[m]>
For a typical ALSA node these properties can be considered being important for identification: alsa.driver_name, alsa.id, alsa.long_card_name, alsa.name, alsa.subdevice_name, api.alsa.card.longname (especially if a specific device like laptop is being looked for), api.alsa.path, node.description, node.name, node.nick (the only truly identifying thing for HDMI audio devices)
<DmitrySharshakov[m]>
Won't you mind if we continue discussing selectors on PipeWire Matrix channel, as this is not directly related to Asahi Linux? Let's keep audio messages here to stuff like pw-dump and a config example I'll write on it
<chadmed>
is that bridged to the irc channel?
<DmitrySharshakov[m]>
I guess so
<DmitrySharshakov[m]>
Join us on IRC at #pipewire on OFTC. -- it is
<DmitrySharshakov[m]>
Awesome, will implement a new-style config for it
<chadmed>
brilliant
<DmitrySharshakov[m]>
povik: I think the kernel driver should fetch machine name and set device name to, say `MacBook J314 Internal Speakers` not J314/6 which doesn't help to detect whether we need J314 or J316 filters.
<povik>
ack
chadmed_ has quit [Quit: Konversation terminated!]
<DmitrySharshakov[m]>
povik: chadmed: https://tpaste.us/vyzo I guess this should work with MR 412 config style as of now. Put it somewhere for WP to find in the same order as `src/config/policy.lua.d/51-dsp-config.lua` (at least for in-tree). Keep in mind this is completely untested and I just reformatted the config with the best effort. Please be careful while testing
<chadmed>
also lmao i just remembered my initial proposal fixed the duplicate name problem anyway
<chadmed>
put device names underneath their driver in the directory structure
<povik>
so the same as UCM...
<chadmed>
yeah
<DmitrySharshakov[m]>
Well yes. Now we can do this if we're fine with only like 2 degrees of freedom for selectors
<chadmed>
ill test this at some point btw its getting late here now and ive got a massive stack of latex to write for next week over this weekend...
<DmitrySharshakov[m]>
Could I resend your message
<DmitrySharshakov[m]>
(`put device names underneath their driver in the directory structure`) to #pipewire:matrix.org &
<DmitrySharshakov[m]>
s/&/?/
<chadmed>
oh yeah thats fine
pg12_ has quit []
pg12 has joined #asahi-dev
leitao has joined #asahi-dev
amarioguy has joined #asahi-dev
benpokke[m] has joined #asahi-dev
isoriano has joined #asahi-dev
benpokke[m] has left #asahi-dev [#asahi-dev]
benpokke[m] has joined #asahi-dev
pjakobsson has joined #asahi-dev
off^ has quit [Remote host closed the connection]
<DmitrySharshakov[m]>
was there any success or my guesses were wrong and my config didn't work out?
<Foxboron>
How is asahi building packages atm?
<Foxboron>
Hm, or is it mostly just following most of the ALARM builds currently?
AdryzzOLEDEdition[m]1 is now known as AdryzzOLEDEdition[m]11
isoriano has quit [Remote host closed the connection]
isoriano has joined #asahi-dev
benpokke[m] is now known as renheris[m]
michael5050[m] has joined #asahi-dev
jeksskenis[m] has joined #asahi-dev
pjakobsson has quit [Remote host closed the connection]
Race has quit [Ping timeout: 480 seconds]
Glanzmann has joined #asahi-dev
princesszoey has joined #asahi-dev
isoriano has quit [Remote host closed the connection]
isoriano has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
mia_ has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
benpouls_ has joined #asahi-dev
benpoul__ has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
atteniemi[m] has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
benpouls_ has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
mia_ has quit [Remote host closed the connection]
mia_ has joined #asahi-dev
benpoul__ has quit [Ping timeout: 480 seconds]
surge9n has quit [Ping timeout: 480 seconds]
mia_ has quit [Ping timeout: 480 seconds]
benpoulson has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
mia_ has joined #asahi-dev
mia_ has quit [Remote host closed the connection]
mia_ has joined #asahi-dev
surge9n has joined #asahi-dev
bisko has quit [Ping timeout: 480 seconds]
balrog has quit [Quit: Bye]
surge9n has quit [Ping timeout: 480 seconds]
balrog has joined #asahi-dev
bisko has joined #asahi-dev
benpoulson has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
jackhill has joined #asahi-dev
jackhill has quit []
jackhill has joined #asahi-dev
surge9n has joined #asahi-dev
jackhill has quit []
jackhill has joined #asahi-dev
Phorous has quit [Remote host closed the connection]
surge9n has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
<amarioguy>
alright so i've made further changes to the i2c driver and while asahi linux boots according to the feedback i got last time, i get a kernel oops fairly early on and the boot process is *slow* like many minutes and i'm not even at login screen (i'm suspecting a major interrupt storm)
<amarioguy>
(the best part is that rcu-torture is casually reminding me that it's starting/ending an episode all the time lol)
<amarioguy>
yes it's a new branch because i didn't feel like rebasing my previous branch lol
<amarioguy>
prolly just gonna stick with this one moving forward btw but no guarantees
mia_ has quit []
<amarioguy>
also getting a call trace every so often
benpoulson has quit [Remote host closed the connection]
bronson has joined #asahi-dev
<sven>
what is the bus locked supposed to do inside waitready?
benpoulson has joined #asahi-dev
bronson has quit [Quit: Page closed]
<sven>
the irq mask Write inside the handler also looks off
<sven>
and you sure that 1 = interrupt disabled?
<sven>
i thought it was the other way around for that controller
* povik
looks into docs
<amarioguy>
ah lemme try the other way around - i assumed IMASK worked the same as SMSTA where 1 = masked/disabled and 0 = unmasked/enabled
<povik>
yeah, sven is right, 1 to enable
<amarioguy>
gotcha i think that's the major issue here
<sven>
the bus lock is also a major issue fwiw
<sven>
when you’re in waitready that lock should already be taken by the core
<amarioguy>
ahhhh so adding the lock wasn't necessary
<amarioguy>
alright removing that
<sven>
you need the lock in probe
<amarioguy>
the probe func in the platform file?
<sven>
you dont want any i2c transaction when switching to irq mode I think
<amarioguy>
alright noted lemme apply the changes now
<sven>
though I guess it doesn’t matter with the current code cause irqs are disabled
nicolas17 has quit [Ping timeout: 480 seconds]
<sven>
and just requesting the irq handler doesn’t do anything
<povik>
sven: hm? i don't understand that. how could any transaction occur before the controller's probed?
<sven>
the common probe function registers the adapter
<sven>
after that transactions can occur
<povik>
ah right
<povik>
thought it's i2c core calling the probe
<sven>
nope
<sven>
but I think the lock isn’t required here because no irq will be raised anyway before he sets use_irq to 1
<sven>
iirc the last iteration had a possible race there though
<amarioguy>
lemme try without the lock first
<amarioguy>
if the lock ends up being needed, i'll add it back in
<sven>
that’s not how to decide if a lock is required
<sven>
you have to figure out if there a race window
<sven>
if there is it’ll probably only work most of the time without the lock
<amarioguy>
alright
<amarioguy>
a bit to take in, and yea looked at the past comments, i mistakenly added the lock to the wrong place
<sven>
I think if you write 0 to the irq mask in common_probe there’s no need to lock the bus
<amarioguy>
alright lemme try that
<sven>
the irq wont fire before it hits the if (irq_enabled) path then such that you can safely request it
<sven>
and then just set use_irq to 1
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
Race has joined #asahi-dev
<amarioguy>
btw as a side note sometimes m1n1 won't be able to vector to the next stage when running run_guest_kernel.sh
<amarioguy>
it gets stuck on "vectoring to next stage" occasionally without actually jumping to the kernel
<povik>
same here
benpoulson has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<amarioguy>
hmm still encountering lockups (i had panics but that was solved by casting smbus to a void pointer in the request_irq call, i accidentally had a pointer to a pointer which caused issues)
<amarioguy>
one CPU seems to be deadlocked and i think there's a chance there's still a null pointer dereference somewhere
<amarioguy>
i can send a kernel log here if needed, i can also push my changes for further review)
<povik>
do that, worst thing that can happen is noone will inspect it
<amarioguy>
again apologies if i'm running into "trivial" issues
<j`ey>
'snd_mtpav_probe+0x2a0/0x3f', this looks odd
<povik>
whoa indeed
<povik>
that's a platform device
<amarioguy>
that's part of the sound code which is bizarre (note that i did enable maximum debugging due to the panic issues i was facing earlier, and i've been booting with the debug arg so idk if that's why that's coming up)
<amarioguy>
though fwiw the lockups were occurring with standard loglevels but still never touched the sound code
<povik>
i think looking at 'alsa_card_mtpav_init' it's just another of those things you find out kernel runs every time
<povik>
anyway... let's see the code
<povik>
amarioguy: it's best if you squash it for review
<amarioguy>
alright
surge9n has joined #asahi-dev
<amarioguy>
squashed and force pushed the commits, should be ready for review now
<amarioguy>
it's just the latest commit, same url as before
benpoulson has quit [Remote host closed the connection]
surge9n has quit [Ping timeout: 480 seconds]
akspecs has joined #asahi-dev
<povik>
(i meant squashing with the original changes)
<povik>
i don't see anything obvious to explain the lockups other then you may need to initialize the completion