jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi
the_lanetly_052___ has joined #asahi
<marcan>
povik: what's the story with the mux-based switching? is this for a single stream going to speakers or to headphones, or for muting multiple streams?
<marcan>
if single stream, I wouldn't bother. can't do the EQ properly in that case without a sound server, so I have no interest in supporting it (mps: you want features like jack hotplug with modern hardware, use a sound server. that's what the hardware design + kernel design requires.)
<marcan>
if it's just muting multiple streams I guess you could have software always send the plain jack version + EQ/crossover'd speaker version at once with an ALSA plugin...
<marcan>
it would of course be a waste of CPU power when headphones are in use though, in that case
Chainfire has quit [Remote host closed the connection]
Ry_Darcy has joined #asahi
Ry_Darcy has quit [Remote host closed the connection]
<povik>
it's single stream *and* running without a sound server that was questioned as a use case on the list
<povik>
i know it's dimishing returns but i saw a way to implement it and so i did
<povik>
(all the while not compromising on the other use cases)
<povik>
tbh i kind of like if it could do that e.g. on mac mini where the lack of speaker dsp wouldn't seem that much of an issue
dviola has joined #asahi
dviola has left #asahi [WeeChat 3.5]
<chadmed>
one useful edge case would be using the mini as a very very barebones media client
<povik>
there may be a way to implement it with little cost that i will try for the next iteration
<povik>
if that doesn't work i guess i will have to drop it
<chadmed>
i used to use a mini as an airplay mirror, the thing i used just rendered video directly to the framebuffer and used plain ALSA for audio
<chadmed>
though even in that use case, 99% of the time youd have it hooked up to a stereo or AV receiver
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
llanhmod has joined #asahi
<Sobek[m]>
Well asahi just saved my day after the Live USB key that contains my PGP master key decided it wouldn’t boot anymore.
<Sobek[m]>
Btw, taking the time to update my system, there have been some updates to the Asahi kernel since the initial Asahi release, am I right ?
<j`ey>
Sobek[m]: yup
<j`ey>
Sobek[m]: mostly a rebase
Ry_Darcy has joined #asahi
<mps>
marcan: povik: first, I don't know how this work on modern sound subsystems so it is not so much important to me
<mps>
just prefer if it can work without userspace server
<mps>
but again, however you make it it fine for me
<mps>
it is*
<mps>
iiuc equalizer is implemented in hardware and managed by userspace software. or I'm wrong?
<chadmed>
the EQ and DSP is implemented in software
<mps>
hmm, then I don't see reason to use soundserver
<marcan>
povik: single stream + no sound server is not a supported use case in practice, IMO, due to the EQ issue
<marcan>
I mean with auto-switching
<marcan>
chadmed: for that use case you wouldn't need headphone jack switching anyway
<marcan>
since presumably you'd always be using some sort of output
<marcan>
povik: so basically if you can do it trivially, sure why not, but otherwise I would absolutely not try to spend any effort putting together some mechanism to make it work
<mps>
userspace jack switching is quite ok imo
<marcan>
it is the case on many modern systems that you cannot switch a single stream between headphones jack and speakers anyway
<marcan>
mps: you need a sound server for that to work mid-stream without application support
<marcan>
since alsalib does not help you there
<mps>
marcan: input event layer can send signal to userspace, and use it to switch jack?
<marcan>
and how does your app know to close one device, open the other device, and change EQ profiles?
<marcan>
that's what we have sound servers for
<mps>
sound stream I mean
<marcan>
the point is, not using a sound server means you don't have a layer between apps and hardware, which means apps see the hardware directly, which means you don't have a place to put the logic required for things like EQ and jack switching to work properly
<mps>
marcan: aha, I think to beginning to understand what you want to say
<mps>
yes, this is understanble
<marcan>
nobody's going to force anyone to use a sound server, but if you don't you have to accept that your apps are going to be outputting to one stream, and only one stream, and without any ability to EQ except for what you can do with ALSA plugins, and changing the setup will require a restart of the app or at least stopping/restarting audio
<mps>
that's true and it is how I use it now
<marcan>
by the way, this has been broken for *decades*, it's just more obvious with modern systems
<mps>
this mux switching is in input and not in output
eroux has joined #asahi
<marcan>
my first laptop, a core2duo, had "5.1" speakers, and needed sound server support for upmixing, and I had to hack up the ALSA driver (that patch did get merged though lol) to allow opening the device in different channel modes because you could have things like the jacks in 2.0 mode or 5.1 mode, and that would mismatch with the speakers
<marcan>
at the time this was all a mess
<marcan>
especially with hardware that tried, and failed, to share streams between speakers and HP jacks
<marcan>
hence the trend has been towards just doing it all in software
<marcan>
everything is a separate stream, implement policy in userspace
<marcan>
which works quite well in modern systems
<marcan>
muxing is a problem in general, because it creates race conditions
<marcan>
consider that software has to coordinate software volume scaling with codec volume scaling
<mps>
marcan: now I understand better, thank you
<marcan>
if you're switching codecs for a single stream, how do you align the software volume change with the mux switch? you'd have to soft mute, switch, soft unmute, and time it all properly
<marcan>
what a mess
<marcan>
everything's a lot simpler if we just keep all this out of the kernel and let userspace deal with multiple streams and whatever timing it wants to use
<marcan>
though of course that means you need a sound server for proper functionality
<mps>
I just had fear that software layer can add latency
<marcan>
that is completely up to the software layer, and I personally care deeply about latency and want to work on improving that in PipeWire too
<marcan>
but, on the other hand, if you really care about latency to the millisecond level, you'd probably be using JACK with zero jack switching smarts anyway, everything managed manually
<mps>
and I'm using sound in some real-time systems where small latency can be a problem, though not on M1
<marcan>
yes, I do music production on Linux and I think I can make M1s some of the best systems to use for that
<marcan>
but jack auto switching without a sound server is definitely not needed for that :p
<chadmed>
pipewire is already a decent improvement over pulse by itself, pretty much good enough for daily driving a desktop if your requirements are just a web browser and video games
<marcan>
yup, only reason I don't use pipewire on my main machine is the firewire audio driver issue
<mps>
I'm using in radio amateur (HAM) sound processing
<marcan>
and only reason I didn't ship it for the first alpha is I didn't have time to do any userland work at all
<chadmed>
mps: just buy a tecsun s2000 :P
<mps>
chadmed: what is it
<marcan>
the only thing that I need to dig deeper into pipewire for is I want to learn how it handles sample alignment and resampling, because I'm a bit worried about the automagic resampling stuff and would like some guarantees that e.g. it will never happen on certain audio paths as long as certain conditions are met
<marcan>
(for latency and quality and CPU usage reasons; for audio production you really don't want magic resampling behind your back)
<chadmed>
hardware multiband receiver, does LW, SW, AM/FM broadcast bands and ATC band
<marcan>
and for firewire specifically I have an issue with multiple streams getting aligned I need to look into
<marcan>
but I'm sure that can all be worked out
<mps>
chadmed: aha, thanks. but I need sound to be processed in software
<chadmed>
mps: yeah i was just kidding, ofc something like pulse or even pipewire is probably no bueno if you need the lowest possible latency
<mps>
yes, sure it will be better to write driver with DSP but I don't have DSP in simple and small SBCs
<marcan>
pipewire should be fine for low latency under the right conditions
<marcan>
in principle it should be designed to equal JACK
<marcan>
and JACK, in practice, works better than using plain ALSA, simply because *correctly* implementing a low latency ALSA client is actually really hard
<marcan>
and JACK has all that mess built in
<marcan>
and writing a JACK app is stupidly simple
stefan has joined #asahi
the_lanetly_052__ has joined #asahi
<marcan>
getting latency low means implemeting DLLs to chase the hardware buffer pointer and things like that
<marcan>
it is not trivial at all
<mps>
I know, because that I didn't tried :)
<marcan>
pulseaudio is no good for low latency because it isn't designed for that and basically does all the wrong things for that use case
<mps>
newer liked pulseaudio and one of strong reason to switch from debian to alpine
<mps>
s/and/and that was/
<marcan>
pulseaudio is excellent for all the normal use cases
<marcan>
which is why my current audio setup is pulseaudio on top of JACK
<marcan>
music production / processing hits JACK directly
<marcan>
pulseaudio handles all the "desktopy" stuff on top
<marcan>
and I just create whatever source/sink ports to bridge between them that I need
<marcan>
works great
<mps>
for me it was problematic always
<chadmed>
literally the one cool thing pulse makes easy that i had trouble replicating properly with pipewire is transparently tunnelling audio over the network (i like to demonstrate to people a 1:1 linux replacement for the typical enterprise windows+terminal services setup)
<marcan>
yes, I use that too, it's pretty cool
<marcan>
and IIRC pipewire lost that
<marcan>
though I don't know if any replacement has showed up since
<marcan>
but also, pulse just makes all the bluetooth/hdmi/jack/etc switching work properly, which never worked before it
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
<chadmed>
i might be misremembering but i feel like i got it working through pipewire's pulse implementation but i was also switching between pa and pipewire at the time
<marcan>
being able to switch apps between different hardware devices is extremely powerful
<Lucy[m]>
Yeah, pipewire has support for `module-native-protocol-tcp` so it can definitely tunnel the audio over network
<mps>
btw, does openbsd uses sound server? sndio maybe?
<marcan>
is that new? it wasn't a thing a year ago or so IIRC
<Lucy[m]>
It's been a thing for at least 11 months
<marcan>
cool, so now that's in too
<mps>
don't know, some time ago I tried it on linux
<marcan>
back when I first tried PW it wasn't there yet
<mps>
ah sorry, you talking about pipewire
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nepeat has quit [Ping timeout: 480 seconds]
linuxgemini956 has quit [Ping timeout: 480 seconds]
ave363 has quit [Ping timeout: 480 seconds]
nepeat has joined #asahi
linuxgemini956 has joined #asahi
ave363 has joined #asahi
ave3630 has joined #asahi
ave363 has quit [Read error: Connection reset by peer]
ave3630 is now known as ave363
ryancheddar[m] has joined #asahi
llanhmod has quit [Quit: leaving]
eroux has joined #asahi
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eroux has joined #asahi
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kode54>
I had to switch back to PulseAudio
dianshi has left #asahi [WeeChat 1.9.1]
<kode54>
Sunshine doesn't work so hot with PipeWire, especially on a VM
<kode54>
VM: glitchy audio
<kode54>
other issue: it doesn't bind the recording device correctly, so it is able to create the sinks for capture, but leaves the recording device set to the system default device
derzahl has quit [Remote host closed the connection]
wCPO62 has quit []
wCPO62 has joined #asahi
wCPO62 has quit []
MichaelRose[m] has quit [Quit: Client limit exceeded: 20000]
wCPO62 has joined #asahi
kov has joined #asahi
wCPO62 has quit []
wCPO62 has joined #asahi
opticron has quit [Ping timeout: 480 seconds]
bakkl has joined #asahi
<bakkl>
has there been any progress on system sleep lately
Illya has joined #asahi
opticron has joined #asahi
<Ry_Darcy>
Does anyone have a howto/cookbook on running qemu-system-x86_64 from the command line from an M1 Mini running Asahi Linux (Linux debian 5.18.0-asahi)?
<Ry_Darcy>
Have tried all sorts of things, but I am only getting as far as the QEMU shell.
<kettenis>
mps: yes sndiod(8)
bakkl has quit [Quit: Connection closed]
bakkl has joined #asahi
<mps>
kettenis: aha, yes. I made some fixes for it on alpine year or two ago and moved to stable release. should look again on it if it could work on linux
<mps>
Ry_Darcy: I don't have for x86_64 but have some examples for riscv64, armv7 and aarch64 here https://arvanta.net/alpine/
<Ry_Darcy>
Thanks. I am tring to get a win 10 .iso to fly.
<mps>
I had win10 few years ago in qemu, maybe I saved scripts and drivers somewhere
<mps>
Ry_Darcy: yes, this works fine. when daughter come back home I will look at her computer for win 10 script (I made it for her because it is needed for her university)
___nick___ has joined #asahi
___nick___ has quit []
<Ry_Darcy>
Great. Thank you. As long as it runs on the M1 Mini using Asahi Linux.
___nick___ has joined #asahi
<mps>
don't see any reason why it wouldn't
<Ry_Darcy>
Let us wait and see. Thanks.
bakkl has quit [Ping timeout: 480 seconds]
Ry_Darcy has quit [Remote host closed the connection]
<mps>
this is how I started it on x86_64, on aaarch64 kvm can't be used but something else to get acceptable performance
<mps>
ryan_nupp[m]: oh sorry, it was intended for Ry_Darcy
<povik>
10:47 < marcan> yes, I do music production on Linux and I think I can make M1s some of the best systems to use for that
Guest1499 is now known as Skirmisher[m]
<povik>
i wonder if the counter values from ADMAC reports is something we should make us of later on to make timing on point
<povik>
not sure how better it is than querying the dma controller for residue which is done now
<marcan>
quite possibly, yeah, you want DMA feedback for downstream consumers most likely. That rings a very vague bell. I don't know about the details though.
<marcan>
right
<marcan>
fwiw I'm more personally interested in the CPU side (getting good realtime latency so you can actually use tiny buffer sizes, fixing realtime breaks in the kernel) since we have a much better chance at that than on the mess that is the intel world
<povik>
*thumbs up*
<marcan>
so I won't be bugging you too much about the audio hardware side unless you ask me to :)
<marcan>
(or unless I find a problem :p)
<povik>
feel free to actually
<povik>
i will be happy if we make it as good as it can be
<marcan>
excellent :)
eroux has joined #asahi
<marcan>
good time to be working on linux realtime stuff too, with PREEMPT_RT almost there
* povik
is not in the loop on that
<marcan>
-rt has been an out of tree patchset for *ages* and it was sort of rotting for a while, but last year the big core part of the patchset was merged (just not usable yet)
<povik>
ah
<ComradeMisato[m]>
one of these days audio will work on my end
<mps>
and in 5.19-rc are added some more
<marcan>
I've been personally running -rt for a long time and I'm quite happy with what it does, but it's limited by cpu/hardware being terrible at this point
<marcan>
e.g. on intel I have to just outright disable almost all CPU idle states for it not to suck
<marcan>
... but then the damn thing overheats and throttles and it goes terribad again
<povik>
:(
<marcan>
and this is an iMac so SMC is under control, but on a lot of other intel platforms that'll steal your CPU for milliseconds at a time too
<marcan>
*SMM, not SMC
<marcan>
anyway intel bought the company that was sponsoring linux-rt or something, so hopefully they'll move the core kernel stuff forward (I have no high hopes for it actually being any good on their CPUs though :p)
<marcan>
but I want it to work nicely on M1s :)
<marcan>
my guess is intel will only ever care about this on industrial boards with very controlled hardware, and we'll be the only ones putting out a solid RT experience on consumer machines :p
<marcan>
but if I can start setting my audio buffers to 64 samples and have it work at all, that will be a lot of fun
eroux has quit [Remote host closed the connection]
___nick___ has quit []
___nick___ has joined #asahi
___nick___ has quit []
the_lanetly_052___ has joined #asahi
___nick___ has joined #asahi
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
qeeg_ has joined #asahi
qeeg has quit [Ping timeout: 480 seconds]
ciggi has quit [Read error: Connection reset by peer]