marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | "Does XXX work yet?": https://alx.sh/fs | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-alt #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
frek has quit [Read error: Connection reset by peer]
frek has joined #asahi
tertu2 has joined #asahi
<frek>
PaulFertser: let me know, when i can help out with anything to get a closer look. interestingly i was working with blender and youtube last night, even when i dragged the youtube video on the ext. monitor and continued modeling in the m1 monitor. and there was an episode, when everything was running smoothly.
<PaulFertser>
frek: does it affect not only the integrated sound card but also audio via bluetooth?
<frek>
yes
<frek>
also bt
tertu has quit [Ping timeout: 480 seconds]
<PaulFertser>
frek: I guess that means that the kernel evdi out of tree driver increases the latency of the whole system beyond what's normally seen on these boards. Are you using wireplumber for audio?
<PaulFertser>
Pipewire
<PaulFertser>
Or pulseaudio?
<frek>
pipewire is running
<PaulFertser>
frek: do you have any underflows mentioned in "journalctl -u pipewire-pulse.service" ?
<frek>
right now it says -- No entries --
pb17 has quit [Ping timeout: 480 seconds]
<PaulFertser>
frek: I suggest you try running pipewire with PIPEWIRE_LATENCY=200/1000 to see if it makes any difference. I do not know how exactly to do that on your distro but it should be easy.
<PaulFertser>
You can try setting that env variable prior to running an app that plays music, it's per-stream/per-app essentially.
<PaulFertser>
Or you can do this to change defaults temporarily: pw-metadata -n settings 0 clock.force-rate <samplerate>; w-metadata -n settings 0 clock.force-quantum <buffersize>
<frek>
i will try, but right now (and also before) i have difficulties connecting or better recognizing the ext. monitor. it is more like a roulette, i have to unplug, switch monitor off>on again and then plug the docking station back in, and sometimes, it then recognizes it, but right now i'm already without success for some minutes..
<frek>
ok, now i got it.. :D
pb17 has joined #asahi
Brainium has joined #asahi
johey has joined #asahi
frek has quit [Remote host closed the connection]
johey- has joined #asahi
frek has joined #asahi
johey_ has quit [Ping timeout: 480 seconds]
johey has quit [Ping timeout: 480 seconds]
vx has quit [Ping timeout: 480 seconds]
<frek>
ok, tested some more usage scenarios and it seems to be performance, as soon as i run multiple programs with high visual performance the jerks start, like when watching a yt video, starting inkscape and kdenlive parallel. and blender and yt seems to be enough already. otherwise i can open several other programs parallel as thunderbird, inkscape, vlc and switch between monitors without problems.
<frek>
while yt is running e.g.
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi
<PaulFertser>
frek: so try asking pipewire to use more buffering the way I suggested
millefy5 has joined #asahi
<frek>
jop, as env variable it doesn't seem to work with elisa
<frek>
i'll now change it systemwide
<PaulFertser>
I'm not sure what exactly sound stack you're using and how, what's the actual path the sound goes through userspace before enters the kernel. It depends on your distro and settings.
jeisom has joined #asahi
<PaulFertser>
But in general my idea is to increase buffering (and hence decrease requirements for low latency scheduling). And it seems to be somewhere in the sound daemon you use, the one that mixes the sounds from different apps.
<PaulFertser>
frek: you can also try playing audio with plain mpv and different values for --pipewire-buffer (make sure it uses pipewire ao, not pulseaudio or alsa).
<PaulFertser>
frek: that env variable doesn't affect systemd units obviously :)
<PaulFertser>
frek: it's supposed to be set before a playback app, but some apps will overwrite anyway.
<PaulFertser>
frek: try with mpv
millefy9 has joined #asahi
jamesd_ has joined #asahi
<frek>
i do, but the thing is that watching videos on yt or streaming sc is more the realistic use case scenario.. :)
millefy has quit [Ping timeout: 480 seconds]
millefy9 is now known as millefy
<jamesd_>
Hey! Are there any plans for 4K kernels to be released by the Asahi project? Very curious about the legal status of running Rosetta on Asahi... I have some X86 Linux applications i'd love to run on my M1 machine but currently looks like VNC/RDP into a Linux X86 machine is the way
<j`ey>
jamesd_: nope
<j`ey>
the plan is to use a VM to run 4K kernels
<j`ey>
(and people are doing that to run steam etc)
<bluetail>
but will it run x86
<j`ey>
through FEX
<bluetail>
of course
<j`ey>
jamesd_: and even if they did, they wouldn't do the changes required to make rosetta work (it needs some IOCTL thing)
<jamesd_>
Understood, got it. Very curious if that would give 'near-native' performance? The application is quite heavy. I should probably just try it :-)
<bluetail>
no
<j`ey>
FEX emu is always improving, but it is still a trasnlation layer etc
<jamesd_>
Also vaguely interested in contributing to the project - I was hoping IRC would load message history in the -re and -dev channels
<j`ey>
IRC doesn't have that currently (maybe once v3 is out)
<j`ey>
the log site has history though
vx has joined #asahi
<jamesd_>
Perfect. Are the channels quite active?
<bluetail>
no
<j`ey>
not currently
<j`ey>
if you ask questions, they will be answered though
<bluetail>
to be honest I prefer if not everybody joins dev channels
<jamesd_>
Understood. Thanks both! Are most project dev's lone-wolfing their contributions as such in that case?
<j`ey>
kinda
<j`ey>
bluetail: well there's no harm in joining
KxCORP589 has quit [Ping timeout: 480 seconds]
<jamesd_>
For sure! Would it be a case of checking git issues and starting from there?
<j`ey>
jamesd_: for VMs, the current related projects are: FEX (x86 emu), mesa (a fork of a fork which can do something a bit like passthrough), virgl and sommelier
<PaulFertser>
frek: mpv shows videos from youtube nicely
<jamesd_>
Thank you!
<j`ey>
jamesd_: hopefully soon the VM stuff will be integrated, right now you have to build a bunch of software manualy
<bluetail>
j`ey no, but from people who have a timespan of less than nothing. They'd end up flooding chans by asking without making research or any intelligible action
<j`ey>
bluetail: luckily that doesn't really happen here, but yes I agree in general
<PaulFertser>
frek: and also mpv allows to easily control that buffering we're interested in testing to find possible workarounds for your issue.
KxCORP589 has joined #asahi
<frek>
ah, ok, so playing audio with 1. export PIPEWIRE_LATENCY=200/1000 and then starting mpv results still in same behaviour.
<chadmed>
jamesd_: aiui it is against the apple eula to run linux rosetta outside of a hypervisor.framework VM
<PaulFertser>
frek: playing audio _with mpv_ only
<chadmed>
so please do not discuss it here
<jamesd_>
Ah, I hadn't realised that. I was under the understanding that most of the licensing was tied to the HW rather than SW. My apologies.
<frek>
PaulFertser: jap, mp3
<j`ey>
jamesd_: yeah, apart from that it is mostly
<j`ey>
(which is why we can use the fw etc I guess?)
<PaulFertser>
frek: and what --pipewire-buffer have you tried? And do you see in mpv output that it's using pipewire directly?
<chadmed>
but yeah as has already been said krun/fex will give you mostly the same experience its just a bit of a pain to get working at the moment. there are plans afoot to get everything upstreamed though
<frek>
(+) Audio --aid=1 (mp3 2ch 44100Hz)
<frek>
AO: [pipewire] 44100Hz stereo 2ch floatp
<jamesd_>
Got it, thanks all!
rvalue has quit [Read error: Connection reset by peer]
<PaulFertser>
frek: right, and do you get no difference at all no matter what --pipewire-buffer value you use?
rvalue has joined #asahi
<frek>
PaulFertser: checking different values now, sorry, no cli wizard here, more a lizard.. :D
<frek>
should i try in steps of hundred starting with 100?
<PaulFertser>
Good thing we have _online manuals_ available just one "man anything" command away.
<PaulFertser>
frek: just 100 and 2000 should be enough.
johey has joined #asahi
<frek>
PaulFertser: still present with both parameters..
johey_ has joined #asahi
<PaulFertser>
frek: damn :/ unfortunately I have no more guesses. My current theory is that evdi doesn't let latency requirements of your sound server to be met because it affects bluetooth and integrated sound card all alike.
<frek>
in this case there was no prior export PIPEWIRE_LATENCY=200/1000 necessary right
<PaulFertser>
Right
<frek>
PaulFertser: that's sad..
<bluetail>
wouldn't that something wtay can answer?
johey- has quit [Ping timeout: 480 seconds]
<frek>
i guess we have to wait until dp works??
<bluetail>
ic
<PaulFertser>
frek: probably I have just too little clue about pipewire. If I had such an issue I'd stop pipewire and would start testing with alsa directly to isolate the problematic part.
<frek>
i am also just an enthusiastic open source user, no dev.. :)
johey has quit [Ping timeout: 480 seconds]
<PaulFertser>
frek: alt dp isn't really a replacement because it only supports one external display. While with displaylink you have few more.
<PaulFertser>
frek: I am not suggesting you start chasing latency bottlenecks in evdi kernel code :)
<frek>
PaulFertser: that's what i tought.. so there might be a chance that at some point people will have a closer look..
<PaulFertser>
Try to play sound directly via alsa is a user level thing.
<j`ey>
alsa directly without pipewire isnt "supported" on these machines, I think doing that would probably just be a step in the wrong direction
<PaulFertser>
j`ey: how is it not supported? Yes, you get no sound profile for smart DSP but so what?
<bluetail>
PaulFertser DisplayLink is proprietary software
<bluetail>
DisplayPort is a hardware standard
<j`ey>
I suppose if it's just for testing
<PaulFertser>
bluetail: really? I thought the evdi kernel driver is fully proper GPLv2?
<PaulFertser>
j`ey: for testing indeed, I'm suggesting to do that to tell if the issue affects alsa or just the sound server.
<bluetail>
My mistake.
<PaulFertser>
bluetail: yes, and Apple doesn't have hardware to allow DP chaining so you're limited to just one device. While with DisplayLink USB SS you can have few external displays.
pb17 has quit [Ping timeout: 480 seconds]
<PaulFertser>
So the kernel part is GPLv2, the rest is MIT, looks like proper Free Software to me.
<j`ey>
I think M3 onwards allows 2 screens, if youre in clamshell mode. cant remember the exact details
<chadmed>
you _could_ have multiple displays out if you had a tbt dock that didnt use MST
<chadmed>
but they basically all use MST now...
<chadmed>
j`ey: the pro/max/ultra machines all support multiple dp out, the annoying part is you need to consume multiple ports and have multiple dongles because no MST
<bluetail>
but you need a device that supports DisplayLink technology to use it, correct?
<chadmed>
no...
<PaulFertser>
Yes, yes. I mean there still is some advantage of the newer DisplayLink devices for certain usecases with macs.
<j`ey>
chadmed: ok, so I guess that clamshell was just about M3 Air
<PaulFertser>
bluetail: DisplayLink is like a USB-attached video card.
<bluetail>
That sounds better than 'makes use of uvcvideo'
<chadmed>
j`ey: yeah thats something to do with the firmware allowing it, should be possible on m2 with a fw update too since there is no hardwired "internal" dcp and theyre all crossbared
<j`ey>
chadmed: which they probably wont do D:
<bluetail>
on my x86 pc I ended up requiring a dkms enabled capture card from magewell cause everything else was not reliable or buggy.
<chadmed>
of course they wont :p
<chadmed>
the funny thing is that the bumass intel macbooks all supported MST because they had intel display controllers so apple silicon is genuinely an extreme regression in that regard
<j`ey>
chadmed: Ill buy an M3 air, dump the fw, and then get a refund >:D
<chadmed>
of course macos never exposed MST support but throwing linux at them got you there. i used a 13" macbook pro as a desktop replacement for a few years
<PaulFertser>
For the reference, DP chaining also requires MST because for chaining the display itself includes an MST "switch" with two downstream ports (one internal for the display itself, one external to chain to the next).
<frek>
thanks all!!! please let me know, if i can contribute anyhow to this issue, cause i'd love to have 1 or more external screen and smooth audio.. i'll dive back into my geometry nodes in blender.. :) but i'm still on in case i should test something out..