jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
surge9n has joined #asahi-dev
uniq has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
uniq has joined #asahi-dev
uniq is now known as sortIuniq
sortIuniq is now known as uniq
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
PyroPeter has joined #asahi-dev
pyropeter3 has quit [Ping timeout: 480 seconds]
uniq has quit [Ping timeout: 480 seconds]
uniq has joined #asahi-dev
dmmcf has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
dmmcf has quit [Ping timeout: 480 seconds]
<marcan>
heh, CONFIG_TRACE_MMIO_ACCESS showed up on 6.0, cute
<marcan>
somewhat moot with the hypervisor though :)
<marcan>
povik: I really don't know what commits I should be using for 6.0; the macaudio driver in both branches differs quite a bit and neither is quite right.
<marcan>
I just pushed something that compiles at least, but it's probably wrong :)
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
duban has quit [Quit: I'm out]
duban has joined #asahi-dev
uniq has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
isoriano has joined #asahi-dev
uniq has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
isoriano has quit [Remote host closed the connection]
Ry_Darcy has joined #asahi-dev
<maz>
marcan: that's a QC debugging special.
<arnd>
marcan: I'm also not sure if the CONFIG_TRACE_MMIO_ACCESS implementation is generally that useful. This has been going for a while, and as I understand, the authors mainly need it as a debugging tool for qcom chips that completely hang when a broken driver accesses an MMIO location that is owned by EL3. We'll see if someone can make it work for anything else
<arnd>
Unfortunately the ideas that I had for making it more general tended to also break their use case.
<pjakobsson>
arnd, I've been hacking on a driver for decklink capture cards and found that it's also very useful to have a stack dump on each trace. It's pretty heavy but provides lots of useful information when interacting with binary blobs.
<arnd>
pjakobsson: so does the code we merged work for this usecase?
<pjakobsson>
arnd, I haven't looked at it yet. Give me a minute.
<arnd>
if you have any ideas for improvements, I'm sure others can benefit from that as well
surge9n has joined #asahi-dev
<pjakobsson>
In my specific case I have access to a shim where I can catch all os specific calls that the driver does. That is probably more powerful.
<pjakobsson>
But I'll have a look to see if any of my ideas can be used for mmio trace
uniq has joined #asahi-dev
<arnd>
pjakobsson: I think the idea to use tracepoints on each mmio access is generally useful, if you can filter the results in a useful way to get the trace you want. What I don't know is whether the implementation we have is good enough for that. My hope would be that one can use bpf (https://lwn.net/Articles/683504/) for filtering the results to get just the right ones
<arnd>
but I have no experience actually doing that
<pjakobsson>
arnd, where is the code you merged? I assumed you meant it got merged into mainline but can't find any recent changes.
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<povik>
marcan: yeah, i don't have anything prepared you should be using for 6.0, really; as you saw, asahi-sound-wip, which is roughly my working latest and is in step with upstreaming, has diverged a lot from the old stuff merged in asahi
<povik>
(as there were no new features until recently, i didn't push for syncing)
uniq has joined #asahi-dev
<DmitrySharshakov[m]>
povik: could you please elaborate how do volume caps work in the WIP driver?
<povik>
anyway, i am away at the moment, but on friday i can flesh out the new branch for merging
<povik>
this time we may push it with UCM userspace config, which i suppose should be easy to do it with the reference distro
<povik>
just another package to overlay...
<DmitrySharshakov[m]>
Are they just preventing setting volume above 70% or make 100% set 70% in software (i.e. scaling the volume). So, if userspace wants to set max, should it be 100 or 70?'
<DmitrySharshakov[m]>
* Are they just preventing setting volume above 70% or make 100% set 70% in software (i.e. scaling the volume). So, if userspace wants to set max, should it be 100 or 70?
<povik>
DmitrySharshakov[m]: userspace sees 100% as the max, which is translated to the capped level
<DmitrySharshakov[m]>
Oh, alright
<DmitrySharshakov[m]>
Thanks
<DmitrySharshakov[m]>
Did you have an opportunity to test whether 800 Hz HPF does work alright?
<povik>
not yet, i didn't get to the hardware since i wrote that patch i linked
<povik>
on friday i will
<DmitrySharshakov[m]>
I'm now doing stuff for PipeWire/WirePlumber (PW issue #2210), and of course main target audience for this feature is Asahi
<povik>
ah, i was wondering if you are the same dmitry i get all that eam
<povik>
* emails from :)
<DmitrySharshakov[m]>
Alright, sorry for disturbance
<povik>
not at all
<DmitrySharshakov[m]>
povik: Hmm, what's the email?
<povik>
i am subscribed to the thread...
<DmitrySharshakov[m]>
I'm the same Dmitry as who wrote some concepts in PW issue, I'm also sh7dm on GH and Reddit
<DmitrySharshakov[m]>
povik: PW issue 2210? Yes, I has wrote a bit there, now implementing DSP profile probing inside WirePlumber
<DmitrySharshakov[m]>
With those Lua scripts Pro audio is set automatically
<DmitrySharshakov[m]>
Also, is id like `alsa_output.pci-0000_03_00.6.pro-output-0` (but of course name of Mac audio card) sufficient to tell the difference?
<DmitrySharshakov[m]>
We need some way for autodetection of that, so ALSA device should have an appropriate metadata like `alsa_output.j314` for WirePlumber to load the correct profile
<DmitrySharshakov[m]>
That is the only way to get it upstreamable, like just push those configs in Arch Linux ARM or any other repos and let software load it only when required. AFAIK now a Python script installs correct profiles according to DT it reads from sysfs. However, it'd look weird if PipeWire reads DT to find this out. Maybe kernel driver should have those labels to be properly identifiable?
surge9n has quit [Ping timeout: 480 seconds]
pjakobsson has quit [Ping timeout: 480 seconds]
<chadmed>
yeah this is why it really needs to be new functionality inside pw itself with autoconfig based on a directory structure
<chadmed>
we really cannot ship janky ass lua scripts, its seriously no better than what we're doing now
<DmitrySharshakov[m]>
chadmed: Yes, that's what I'm trying to accomplish
<chadmed>
actually its worse because youre moving from a well defined config format to lua
<DmitrySharshakov[m]>
Lua scripts are used to configure WirePlumber
<chadmed>
yeah im aware, what im saying is that its simply not a good enough solution in the long term
<chadmed>
and if we were satisfied with shipping lua scripts we would just keep doing what we're doing now because it achieves the exact same thing
<chadmed>
except maybe the "dont load if the hardware isnt there" bit
<DmitrySharshakov[m]>
It's a no-go to just set into configuration of PW. Session manager should have a new config which it handles by its Lua engine. Not really shipping those in Asahi, but WP having such code and using it to discover DSP-enabled hardware
<DmitrySharshakov[m]>
So my question was about finding out model from within ALSA API
<chadmed>
yeah but what im saying is we still have to ship and install some sort of script and the DSP, which is exactly what we're doing now
<chadmed>
moving that into WP and lua scripts just kicks the can down the road
uniq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<povik>
yes, the card has id to recognize it as, say, j314
<povik>
and userspace should discover that to apply dsp
<povik>
chadmed's current scripts are proof of concept, not a long term solution
<povik>
that's understood
<chadmed>
ideally for the long term, WP/PW would just automatically check some standardised directory structure for DSPs matching some standardised naming scheme, much like linux-firmware, without the need for having to ship lua scripts on a per device basis
<DmitrySharshakov[m]>
povik: Precisely this. DSP configs can then be shipped in generic distro packages without problems of them working where they shouldn't
<chadmed>
which is why my script installs the DSP to /usr/share/pipewire/devices/apple/*, to demonstrate how such a directory structure might look. the actual config fragment is just to mask the fact that PW cannot yet do this automatically without user intervention
<DmitrySharshakov[m]>
chadmed: Yes, so how are `macaudio` ALSA devices labeled currently
pjakobsson has joined #asahi-dev
<chadmed>
the driver exposes a human readable device name to the userspace api
Ry_Darcy has left #asahi-dev [#asahi-dev]
<DmitrySharshakov[m]>
chadmed: Well, yes. I'm implementing a core WirePlumber logic and then a formatted config file is placed into `/usr/share/wireplumber/dsp.d/apple/j314x.lua` as a file containing a call to a function like `registerDSP({...filter-chain props...}, { "node.nick", "=", "J314" }) (which catches the device name from ALSA), and maybe some more configs like whether or not Pro Audio mode should be enabled.
<DmitrySharshakov[m]>
Also that custom config might (later, when I do design this) provide a function which takes 2 numbers and returns 6 of them to implement volume passthrough. So if user sets volume to the virtual sink, WirePlumber receives the evant, it's passed to a configured function which tells us how is L/R volume mapped to all of the 6 channels configured and then sent to ALSA node for the driver to feed volume into hardware, which should be
<DmitrySharshakov[m]>
beneficial compared to software sound attenuation or earlier stages
uniq has joined #asahi-dev
<DmitrySharshakov[m]>
<chadmed> "the driver exposes a human..." <- Thanks, that means we can find the node by an object manager interest with a constraint like `Constraint { "node.nick", "=", "J314" }`! That's great
<povik>
with the volume passthrough, i think you need to map to volume to particular controls by name, not to the 6 channels
<povik>
because there's no implicit association of the controls to channels that alsa would provide
<povik>
so you have a bag of controls, then a 6-channel pcm device
<povik>
and the relation between the two comes from hardware-specific userspace configuration
<povik>
s/to map to/to map the/
<DmitrySharshakov[m]>
povik: Hmm, I mean passing it to ALSA node in PipeWire
<DmitrySharshakov[m]>
AFAIK in case of current macaudio setup it's a Pro Audio with 6 channels
<DmitrySharshakov[m]>
WirePlumber never works with ALSA libraries, so I'm talking about PipeWire abstraction of hardware volume. However I might need to dig deeper
<DmitrySharshakov[m]>
Today I might be ready with sort of `dsp-monitor` which discovers nodes that require DSP and applies rules. Also that'd be the start for the config file structure and format
<DmitrySharshakov[m]>
Volume optimization stuff will come later as it's even less noticeable for users (if noticeable at all). I only have some assumptions that efficiency, dynamic range and quality might have some improvements when volume changes are being sent to the amp hardware. So, for now task #1 for me is to do convenience + config things and only after that experiment with HW volume
<povik>
right, sounds good to me
<povik>
so it's at another abstraction layer that the mapping to hw controls happens
<povik>
you just supply the piece at your layer
josh has joined #asahi-dev
josh has quit []
josh has joined #asahi-dev
josh is now known as josh02
benpoulson has joined #asahi-dev
josh02 has quit []
josh has joined #asahi-dev
josh has quit []
pjakobsson has joined #asahi-dev
Ry_Darcy_ has joined #asahi-dev
tdsrts^ has joined #asahi-dev
josh has joined #asahi-dev
josh has quit []
dmmcf has joined #asahi-dev
Chainfire has joined #asahi-dev
tdsrts^ has quit [Ping timeout: 480 seconds]
dmmcf has quit [Ping timeout: 480 seconds]
cynthia has quit [Remote host closed the connection]
cynthia has joined #asahi-dev
dmmcf has joined #asahi-dev
isoriano has joined #asahi-dev
isoriano has quit [Remote host closed the connection]
dmmcf has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
isoriano has joined #asahi-dev
<amarioguy>
btw a bit confused on something, since i'm placing the completion in the smbus struct how would i be able to complete the action inside the irq handler (i'm not sure if i can pass the smbus struct to the irq handler)
<sven>
you can
<sven>
you pass a void pointer when you request the irq and that one will be passed along to your irq handler
<amarioguy>
ah perfect
Race has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
benpouls_ has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
benpouls_ is now known as benpoulson
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
Michael[m]123 has joined #asahi-dev
Votes78 has quit [Killed (NickServ (Too many failed password attempts.))]
Votes78 has joined #asahi-dev
isoriano has quit [Quit: Leaving]
isoriano has joined #asahi-dev
isoriano has quit []
ckb has joined #asahi-dev
isoriano has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
thinkalex[m] has joined #asahi-dev
ckb has quit [Quit: leaving]
ckb has joined #asahi-dev
pi2 has quit [Remote host closed the connection]
pi2 has joined #asahi-dev
isoriano has quit [Quit: Leaving]
ckb has quit [Quit: leaving]
ckb has joined #asahi-dev
isoriano has joined #asahi-dev
isoriano has quit [Quit: Leaving]
isoriano has joined #asahi-dev
isoriano has quit [Quit: Leaving]
isoriano has joined #asahi-dev
isoriano has quit []
isoriano has joined #asahi-dev
isoriano has quit [Quit: Leaving]
isoriano has joined #asahi-dev
clararussell[m] has joined #asahi-dev
isoriano has quit [Remote host closed the connection]
isoriano has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
carlosstive[m] has joined #asahi-dev
isoriano has quit [Quit: Leaving]
kazukih[m] has joined #asahi-dev
isoriano has joined #asahi-dev
isoriano has quit [Quit: Leaving]
isoriano has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
isoriano has quit [Remote host closed the connection]
isoriano has joined #asahi-dev
isoriano has quit [Remote host closed the connection]
isoriano has joined #asahi-dev
Race has joined #asahi-dev
isoriano has quit [Remote host closed the connection]
surge9n has joined #asahi-dev
RoelAlejandroPerezCandanoza[m] has joined #asahi-dev
isoriano has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
isoriano has quit [Quit: Leaving]
Donaldbtc[m] has joined #asahi-dev
hutchinson70[m] has joined #asahi-dev
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
ptrc has quit [Remote host closed the connection]
ptrc has joined #asahi-dev
surge9n has joined #asahi-dev
Donaldbtc[m] has quit [autokilled: This host violated network policy. Mail support@oftc.net if you feel this is in error. (2022-08-16 23:51:39)]