00:01 <chadmed> i should check in on the pipewire situation re auto-selecting appropriate configurations

00:01 <chadmed> otherwise its going to be a nightmare to package up all the userspace audio stuff

00:11 <chadmed> ok so theres been zero real progress excellent

00:11 <chadmed> time to hack up a concept

05:34 <dsharshakov> IDENTIFY

05:34 <dsharshakov> sorry

05:34 <dsharshakov> Hello chadmed! Yes, I've submitted a draft for permissions refactor, but it's utterly broken and WirePlumber masters don't have time to fix that

05:35 <chadmed> yeah i noticed that, i think thats the least important thing in the scheme of things

05:35 <dsharshakov> However, I'm thinking of doing a simple "Load and route chain once device is discovered"

05:35 <chadmed> i was going to test the rest of your patches today but i went down a config parsing rabbit hole that led nowhere instead :P

05:35 <dsharshakov> Yeah, now we have lower layers as an idiot protection, thus ones picking wrong sink wont make machine go boom boom

05:36 <dsharshakov> Well, we want it for WP 0.4 probably, yea? Not waiting for 0.5

05:37 <dsharshakov> Let me open g.fd.o, I have a draft branch I can remove permissions stuff (racy) from and rebase to some commit fresher than 1yr ago

05:37 <dsharshakov> https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/412

05:37 <dsharshakov> will rebase and push to a sideways branch

05:37 <chadmed> i dont think theres any particular rush (at least not on my end) so if upstream needs more time then thats no big deal

05:38 <chadmed> we have the benefit of being able to simply not release anything until its actually ready

05:38 <dsharshakov> WP people tell me to do that for 0.5 but unsure when is that released

05:38 <dsharshakov> It should be loading fine once I toss out permissions

05:39 <chadmed> if it comes to it we carry some trivial patches downstream until 0.5 is released

05:39 <dsharshakov> But I'm mainly developing on PipeWire (DSP libs, modules etc), WirePlumber is a bit hard to me

05:39 <chadmed> but like i said we can simply not release speaker support until all this stuff is in a healthy place

05:39 <chadmed> yeah i was trying to avoid WP today but it seems like thats where they really want this stuff to go

05:39 <dsharshakov> we can start with !412 rebased since it should be safe to mess with PW in any way, yes?

05:40 <dsharshakov> Yes, we shouldn't hack a filter into ALSA plugin (the thing PW uses to output to ALSA). No other way other than module-filter-chain

05:41 <chadmed> oh no i dont mean to do that

05:41 <chadmed> my idea today was to try load a config fragment when the node is registered, using alsa.driver_name and alsa.card_name as the keys to find the right config file

05:42 <chadmed> but it doesnt like loading configs before all nodes have been registered and the context loaded

05:42 <chadmed> and i have no desire to try and rearchitect the entire startup process :P

05:43 <dsharshakov> Well, my WIP does the same I believe?

05:43 <dsharshakov> ah, I load the config at startup anyway, yes

05:43 <dsharshakov> We can't read files from Lua, at least in 0.4

05:44 <dsharshakov> Maybe you or m_arcan can contact gkiagia (at Collabora, doing most WirePlumber work) to review and help with my permissions WIP to make a proper solution move forward

05:44 <chadmed> yeah but from WP, i was trying to do this in pw_impl_node_register

05:45 <chadmed> which is evidently not the right place to do it

05:45 <dsharshakov> oh, no way. session manager exists for that)

05:45 <chadmed> yeah i just wanted to see what would happen

05:45 <dsharshakov> yes, PW is just a framework session manager assembles into the desired config

05:46 <chadmed> i think for now we just progress without the permissions stuff since we have the daemon set up in a way that should make all safety concerns go away

05:47 <chadmed> so if the user wants to select the wrong sink then at least its not going to explode the machine

05:47 <dsharshakov> yes

05:47 <chadmed> its a nice UX thing tho so we should absolutely revisit it at some point

05:47 <dsharshakov> yes, please do. I know they're busy, but 0.5 work is being really slow...

05:48 <chadmed> everything's been slow lately on most fronts everywhere

05:48 <chadmed> ill ping upstream at some point this week maybe and see whats going on

05:52 <dsharshakov> `everything's been slow lately on most fronts everywhere` <-- why so? Seems everyone in Asahi is also busy

05:53 <dsharshakov> chadmed: here you are https://gitlab.freedesktop.org/d3dx12.xx/wireplumber/-/commits/dsp-monitor-may-23

05:53 <dsharshakov> not tested at all, busy rn

05:53 <dsharshakov> Use description from https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/412 to get started on configs. I'm unsure whether all of that is up to date enough...

05:54 <chadmed> so when i install i just take that policy lua and copy the filter chain into it and fix the match statement?

05:54 <dsharshakov> I suppose I gave you an appropriately formatted config for J314, but that probably changed

05:55 <dsharshakov> paste example from descr

05:55 <dsharshakov> yes, then change matchers and insert an inlined FC description

05:55 <chadmed> beautiful

05:56 <dsharshakov> Drop `-- Used to hide streams` section, however, shouldn't do anything bad

05:56 <dsharshakov> leave this essentially: table.insert (dsp_policy.policy.rules, { matches = { { { "media.class", "matches", "*/Sink" }, { "node.name", "=", "alsa_output.pci-0000_03_00.6.analog-stereo" } }, }, device_matches = { { { "device.name", "=", "alsa_card.pci-0000_03_00.6" } }, }, filter_chain = '{"media.name":"My DSP Speakers 2", "capture.props":{"node.virtual":false, "audio.channels":2,

05:57 <dsharshakov> err, https://tpaste.us/a16o

05:58 <dsharshakov> Ping me if you need help with PW/WP, I am watching the IRC logs. May be busy, but will try to help as I can

06:11 <chadmed> ack, just wrangling the filter chain into json right now

06:18 <dsharshakov> SPA JSON (the permissive type PW uses)s is fine, just remove newlines

06:45 <chadmed> [string "99-asahi.lua"]:1: attempt to index a nil value (global 'dsp_policy')

06:45 <chadmed> have i built wp wrong or something?

06:53 <dsharshakov> Yes, and I wasn't able to deduce the reason for filter chain rate switch bug (#2969 iirc) However, there's a reliable reproducer at the issue now. Please don't add more allowed rates or make the speaker output only support 48000 using PW props for now.

06:54 <dsharshakov> Wim said that didn't reproduce for him, but described method leads to clicks (audio interleaved with 0s) in almost 100% for me

06:55 <chadmed> i have no intention to add more rates so thats fine

06:55 <dsharshakov> In some weeks I might be able to dedicate time to that

06:55 <chadmed> anyway what do i need to do to get this to install correctly? the only options i added were -Dlibdir and -Dprefix because gentoo

06:55 <dsharshakov> What did you ask multirate convolver for?

06:55 <dsharshakov> I build WP together with PW

06:56 <dsharshakov> But you can probably use your ordinary opts as you install WP on Gentoo, but give my branch as a source

06:56 <chadmed> we have multiple rates because the resampling produced low quality, i have no intention to add more rates than we currently have (44, 48, 96, 192) because nothing else matters for desktop audio

06:57 <dsharshakov> For dev setup I checkout PW, run meson and it pulls WP and builds it. Then I can change wireplumber subproject (e.g. roll its git rev) and re-run ninja in PW dir

06:58 <dsharshakov> `44, 48, 96, 192` <-- switching from 48k to 96k is affected in some cases. Let's stick to 48000 as a balanced option for non-pro tasks and then attempt to squash the bug. It lies somewhere in the graph management

06:59 <chadmed> fwiw i have not noticed that ever on this machine

06:59 <dsharshakov> well, weird. my system is a typical AMD laptop, no hardware specifics (Bluetooth also seems to be affected)

07:00 <dsharshakov> Even if you try to pause, wait and play a 96k track in Elisa?

07:00 <dsharshakov> That (as described) is a solid reproducer

07:00 <chadmed> yeah its all fine, going between 48k firefox and 96k other media

07:02 <dsharshakov> that didn't repro for me. Anyway, better keep that topic in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2969 since that's not hw specific

07:02 <dsharshakov> We can switch to oftc-pipewire if you'd like, since we're pretty far from hw specials anyway

07:03 <dsharshakov> PW is available on matrix as well

10:19 <marcan> peer-pipe-cfg

10:19 <marcan> dispext%d: peer pipe dispext%d, max pixel width %d, max pixel rate %d

10:19 <marcan> Got peer ID %d

10:19 <marcan> sven, jannau: from latest DCP firmware ^^

10:19 <marcan> that wasn't there before... DisplayPort MST support ganging up two dispexts (at a layer above the crossbar)?

10:20 <marcan> it would make sense that dispext is in charge of the DP protocol so MST is implemented with a side channel with another dispext, while the dual pipe thing is for Thunderbolt only which uses discrete DP tunneled SST streams for multimonitor use cases.

10:21 <marcan> wild guess though, it could also just be a tiling thing (but I thought we decided that was done with a single dispext)

11:23 <jannau> what do you mean by latest firmware? 13.3 or 13.4? I suspect based on strings in the 13.3 kext (and on how apple advertises the feature) that 8k hdmi mode might need 2 dcp(ext)s

11:25 <jannau> search for mainUFP / peerUFP

11:25 <marcan> 13.2 actually, but yeah that also makes sense

11:26 <jannau> no 8k or hdmi 2.1 display here so I haven't tried

11:31 <marcan> jannau: strings suggest the peering stuff is for atc, HDMI should be on lpdp no?

11:32 <marcan> ah not on the MBPs at least, but then I wonder how that works over a single ATC...

11:38 <jannau> I think I say it in some messages mentioned with HDMI

11:39 <jannau> thinking of it it could be simply some cleanup of how they handle dual displays over thunderbolt and/or thunderbolt+dp-altmode

11:40 <marcan> yeah, could be

11:40 <marcan> is tb+altmode a thing? like 2 lanes for TB 2 for DP?

11:41 <jannau> I'm not sure

11:45 <jannau> probably not what I was seeing with my thunderbolt hub. 2 displays only worked when one of them was a downstream thunderbolt display. for any combination of 2 hdmi/dp/usb-c downstream displays it always used DP MST

11:45 <jannau> but thinking of it the hub shouldn't use dp-altmode towards the mac

11:45 <marcan> yeah

12:54 <sven> tb altmode with two lanes tb and two lanes DP isn’t a thing afaik

12:54 <sven> if you enter tb altmode or usb4 mode you have to tunnel everything else

12:55 <sven> that string could also “just” be a more generic multi stream display handling across multiple dcpext. That would be very weird though

12:56 <sven> *multi stream tiling displays

12:57 <sven> At which layer is MST done in DP? Atcphy has some very low level PHY setting for DP but I think most of the protocol is handled inside DCP

13:16 <marcan> it's higher layer, yeah

13:16 <marcan> some packet thing

13:44 <sven> yeah, then I guess they could implement it all inside dcpext

13:44 <sven> I think atc just passes through whatever dcpext spits out

13:45 <sven> either through the actual PHY or through one of the two DPIN tbt tunnels

13:46 <sven> Iirc atcphy is just setting up the lane mode and clocks and stuff like that