<chadmed>
povik: do you know how apple handles crossover frequencies and EQing of the speaker arrays in these machines? is it DSP in CoreAudio or is there some magic sauce somewhere at a lower level?
bisko has quit [Read error: Connection reset by peer]
user982492 has joined #asahi-dev
jnn has joined #asahi-dev
jn has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
amw has joined #asahi-dev
<marcan>
< kettenis> what I would like to do in OpenBSD is have a single stereo sample stream and be able for the amplifier codecs to pick the right channel out of that stream
<marcan>
the different speakers need different sample streams though
<marcan>
since EQ/filtering will be involved
<marcan>
we could do that as a stopgap if the hardware can do it, but it definitely wouldn't be the long-term solution
<marcan>
long-term on Linux I expect userland will have to deal with this
<chadmed>
it would be nice to expose those things to userland. i find the j314s speakers just a teeny bit too boomy under whatever macos does so id like to drop out 100-200hz and 4k-6k a little bit to clear them up
<chadmed>
(without adding extra DSP into the audio chain)
<marcan>
it pretty much has to be userland; EQ in the kernel would never fly
<marcan>
I'm thinking we need a way of specifying a matrix of FIR impulses or IIR/biquad chains
<marcan>
probably in ALSA, done with profiles in such a way that downstream software just sees it as a stereo device
<marcan>
ideally it should be transparent to PA/JACK/whatever you put in front, though of course nothing stops you from bypassing it and hitting the hardware directly, or writing your own custom profile
shenki has quit [Quit: leaving]
<marcan>
do you know about ALSA UCM2 and card profiles?
<marcan>
look in /usr/share/alsa for that stuff
<marcan>
we can have e.g. card/device profiles that insert a filter to generate the streams for the individual speakers
<marcan>
and UCM2 is used for things like jack plug/unplug and switching routing
<marcan>
chances are with that and existing ALSA infra we can make all this work without too much fuss
<marcan>
but we'd want to get such a plug-in upstreamed of course
<marcan>
as far as the kernel goes, its only job is to provide a multichannel output device with one channel per speaker
<chadmed>
yeah, i was just thinking about hooking in to something like alsaequal or this
<chadmed>
my one thing was just that you cant guarantee itll be present on whatever distro a user picks, but that doesnt really matter too much imo. we could just put a "hey if you want your speakers to not sound crap, install this plugin" line on the wiki somewhere. plus whatever we choose to do will ship with Asahi
gladiac has joined #asahi-dev
<marcan>
this is all part of "distros have to care"
<marcan>
it's not our job to make everything magically work on every distro
<chadmed>
yeah exactly
<marcan>
but the core distro-agnostic things we can do are 1) getting the kernel/DT stuff done, 2) try to upstream such an EQ plugin so distros pick it up, and 3) upstream the profiles/impulses
<marcan>
alternatively, provide a packageable repo with 3) and distros can package 2) and have it depend on that
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
in the end there is always going to be some level of tweaks that distros will have to do to make things smooth on these (or any) machines; our job is to make that *possible* and relatively painless, not magically happen for every distro :-)
user982492 has joined #asahi-dev
<marcan>
but that's why we have the Asahi reference distro stuff, to show people how to do it
<marcan>
povik: what's the DT situation, btw? think we can ship something forward-looking for speaker support on most of the laptops at least, even if the kernel is in flux?
<marcan>
either way today I'm going to work on the installer again, I want to add an "upgrade my m1n1/u-boot" option so users can at least do that easily in the future
<marcan>
I'm also getting the feeling working on chainloading sooner than I intended might be a good idea; punt on the signatures for now (not like ALARM does secureboot anyway yet), if I can just have it chainload from FAT that's already a big win
<marcan>
you know, might just do that today, kinda feel like it
<marcan>
might be a better use of the day than m1n1 upgrades since it supersedes that
<marcan>
(even if we still want that option eventually)
<marcan>
I really like the idea that our first release will let us improve hardware support with only a `pacman -Syu`
<chadmed>
itll be a necessity for end users at some point regardless i think. all the messages kmutil throws at you about it being able to blow your computer up and irradiate your house are scary
<marcan>
yeah, of course
<marcan>
was just thinking of doing it later originally but.... eh, it's going to help me get a release out by agonizing less about what makes the first cut
<povik>
marcan: we can ship something forward-looking but not 100% guaranteed it won't need to change
<povik>
hm, the 'model' string maybe needs to be more specific for UCM to match against
<povik>
also the MCA binding changed when i added proper power domain support (needs audio_p also passed in)
<povik>
so if we are shipping new DT we need to ship at least a bit of new kernel drivers
<povik>
(audio-wise)
povik has quit [Read error: Connection reset by peer]
povik has joined #asahi-dev
<chadmed>
if UCM needs to match the model string, i would just add the actual model ID, so like "MacBook Pro J314/6 Integrated Audio"
<povik>
yeah
<povik>
we need to confirm UCM does that
tanty has quit []
<povik>
i am inclided to ship all of the new audio stuff. in the evening if i find time i should do a pass over it, get in shape and let people test it
<kettenis>
marcan: IIRC the speaker amplifiers have some sort of programmable filter
<povik>
really?!
<povik>
i now they get a separate sample stream at least on j314/6
<povik>
s/now/know
<povik>
(meaning that's how macos uses them)
<chadmed>
UCM uses the card name as referenced by aplay -l, so on OF platforms that should be the model string. spaces are replaced with hyphens
<kettenis>
anyway, I think sending a 4-channel (or even 6-channel) stream down to MCA should be fine as well in cases where a software equalizer is preferred
<kettenis>
but I think it should be done as a single DMA channel; not 4 independent DMA channels
<kettenis>
otherwise properly synchronizing the channels becomes an issue I fear
<povik>
of course, would be insane to do independent channels
<povik>
i see there's some DC-blocking filter at least on the tas2764 (which i reference for speakers on j314)
<povik>
it's configurable, would be surprised if we can use that sensibly though
clrwf0x80 has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
<clrwf0x80>
Hi everybody! May I have bootable image for asahi linux for m1?
<j`ey>
ChaosPrincess: oh right, I thought it must be you, would e strange if another person did it too :P
<ChaosPrincess>
i am at the point where it reads files from disk and checks signatures
subject38[m] has joined #asahi-dev
<kettenis>
povik: looks like I misremembered it's the cs42l83 that includes an equalizer
<povik>
yeah, that makes sense
<chadmed>
povik: ucm2 actually uses the alsa/kernel driver name from sysfs to pick a config profile, not the model string from the DT
<povik>
ah, good to know
<povik>
chadmed: but here we would have multiple models covered by the same driver
<povik>
what then?
<povik>
each should have a different profile, at least different crossover configuration
<povik>
don't know if that will tie into ucm
<chadmed>
seems like ucm is able to probe the alsa driver for the actual card's name, which im guessing is what comes from the dt model string?
<chadmed>
but it seems like it wants device major:minor type strings to match against
<povik>
ret = snd_soc_of_parse_card_name(card, "model");
<povik>
from macaudio.c ^^
<povik>
:)
<povik>
uh, major:minor
<chadmed>
yeah that particular way of doing it seems to rely on usb stuff so disregard
<chadmed>
theres a function to register a long name for the card. the docs make reference to using it to grab DMI information on systems with intel hda, but the actual function seems to just take a pointer to a char, so we could just feed snd_soc_of_parse_card_name to it and see if that works i guess
<chadmed>
the docs say it specifically exists to let UCM differentiate between devices that all use the same driver
<povik>
> In computing, Direct Media Interface (DMI) is Intel's proprietary link between the northbridge and southbridge on a computer motherboard.
<povik>
okay
<chadmed>
an intel interconnect
<chadmed>
yeah
<povik>
i can't believe intel got their own function like that, instead of some generic approach to this very generic problem
<chadmed>
but the function just takes a const char * as the long name
<povik>
right, i am all for just using that
<povik>
as you suggest
<povik>
how is the dmi name exposed to userspace?
<kettenis>
in this case DMI means Desktop Management Interface
<povik>
ah
<kettenis>
better known as SMBIOS
<chadmed>
the first argument to the function is the pointer to snd_soc_card so i guess it just attaches itself to the device in the driver
<kettenis>
(strictly speaking SMBIOS is one of the standards released by the DMI consortium)
<povik>
chadmed: yeah, but where does userspace find the dmi name?
<povik>
if you see that in the ucm code
<povik>
Possible card long names may be: DellInc.-XPS139343-01-0310JH ASUSTeKCOMPUTERINC.-T100TA-1.0-T100TA Circuitco-MinnowboardMaxD0PLATFORM-D0-MinnowBoardMAX
<povik>
:D
<kettenis>
given the software development quality control in the PC world, the DMI model should be seen as a random string that might bear a relationship to the actual hardware you're running on ;)
<povik>
"some degree of correlation"
<kettenis>
in other words, only use it as a last resort
<kettenis>
I currently disable the SMBIOS support in U-Boot since it assumes there is memory below the 4GB mark
<povik>
argh, i have been putting off writing ucm configuration, now it seems we might even need to touch ucm code
<chadmed>
seems to just get the long name magically
<povik>
whoa, we are balancing on the code/configuration barrier here
<chadmed>
yeah so im saying that if it turns out the dmi name function behaves as we think it does, all we need to do is name the ucm config file the same thing as the model string in the dt
<chadmed>
and we get ucm support for free
<chadmed>
with no changes to ucm or alsa
<povik>
understood, although it's kind of a hack
<chadmed>
well i guess the "proper" way they want you to do it is have a separate ASoC driver for each device. this dmi name function seems to have been added as a hack to get around that in the first place
<povik>
no, having separate drivers is also a hack
<povik>
changing the alsa/ucm mess, if there's indeed no other way, is the proper way
<povik>
but i feel we don't understand it fully yet
<chadmed>
this is why its 2022 and still no one takes audio on linux seriously
<povik>
what about having an driver-specific configuration file, which then looks up a model-specific file based on ${CardName} ?
<chadmed>
yeah thats the way id do it if we can pass the name of the device to userspace
<chadmed>
which should just be in ${CardName}
<povik>
yeah
King_InuYasha has joined #asahi-dev
WindowPain has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
riker77 has quit [Ping timeout: 480 seconds]
riker77 has joined #asahi-dev
yuyichao has joined #asahi-dev
<maz>
marcan: perf stuff now queued. feel free to also merge my irq/aic-pmu branch in your tree if you need to resolve conflicts.
klaus has joined #asahi-dev
amarioguy has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
Gaelan_ is now known as Gaelan
amarioguy has quit [Ping timeout: 480 seconds]
<marcan>
maz: cool, think AICv2 can go in if I respin it tomorrow? (just changing that reg entry thing)
<marcan>
(+rebase)
<maz>
marcan: ideally, I'd like an ack from robher on the binding. if he can rubber stamp that, I'll take the series in.
<maz>
please base it on -rc3 though. I'll take care of conflicts.
<marcan>
gotcha
<maz>
thanks
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
Method has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]
Method has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
* povik
has a 6-channel ALSA device on MBP
<povik>
i am going to make it you can open it as 2-channel or 6-channel device
<kettenis>
that was my idea for openbsd as well
<povik>
at first i thought it would be too involved because ASoC doesn't let the machine driver selectively disable codecs
<povik>
but then i realized i can let them be enabled, just send null samples their way
<povik>
not optimal, but i expect most people will drive all 6 speakers anyway
<kettenis>
what happens if you send the same sample stream to all three speakers for a single stereo channel?
<povik>
you mean how bad it sounds? :p
<povik>
can't be told with speaker-test, let's see
<povik>
i think maybe the 4 channel masks can help do that
<povik>
why is my music sped up?!
<povik>
kettenis: i played around with it for a bit (by overlapping the TDM slots as you would probably do)
<povik>
it doesn't sound nearly as good as when apple does its thing, i would say
<ah-[m]>
wow you're getting sound via the speakers? is this m1 or m1 pro/max?
<povik>
there's the question of gain for the individual speakers
<povik>
ah-[m]: m1 pro
<ah-[m]>
awesome!
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has quit [Ping timeout: 480 seconds]
<kettenis>
povik: does it sound better than with just 2 speakers is the question though
<povik>
it sounds kind of weird when you naively combine the speakers, as if it is off somehow
<povik>
i like it best going all in on woofer 1
<povik>
yeah, i will be interested to hear how you or someone else would describe, kettenis
<povik>
but for me woofer 1 is the way to go, out of the simple approaches
<povik>
s/would describe/would describe it/
<kettenis>
I've parked the audio driver stuff for OpenBSD for now since I've been working on getting the m1 pro/max working and improving the OpenBSD installer a bit
<jannau>
sigh, chainloading m1n1 breaks dcp. it crashes immediately after starting it
<jannau>
linux crash is a different problem
user982492 has joined #asahi-dev
will[m]12 has joined #asahi-dev
will1[m] has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alyssa has joined #asahi-dev
<alyssa>
jannau: re dcp breaking with t6000 m1n1 stuff
<alyssa>
at risk of asking the obvious, is m1n1 doing its own dcp init code?