libera/#shirakumo - IRC Chatlog
Search
13:59:21
hayley
Be strategic - note down the easy gains for later when someone wants it to run faster. Then you can look really clever when you implement said gains quickly.
14:00:38
Colleen
<shinmera> I mean, the biggest gain would be from implementing a renderer that isn't just a primitive forward.
14:59:23
Colleen
<shinmera> gingerale: mood: |3b|: once again https://github.com/Shirakumo/trial/pull/41
15:10:39
karlosz
i suppose since it's more difficult to run stuff on the nx the best course of action is to try to make stuff on linux as restrictive as possible to simulate the nx environent
15:11:08
karlosz
for example the way things work with elfinated cores right now is that linux actually unprotects the text section making it writable
15:11:27
karlosz
of course it has to do this because code and data were not truly segregated and the garbage collector needs to fixup code constants and stuff
15:12:28
karlosz
i changed it to not remove the protection and found some other places where the garbage collector tries to write into the text space
15:13:33
karlosz
anyway once we have a build of sbcl on linux which is able to randomize the position of all spaces and also keep the text section read-only, only then will stuff run smoothly on NX
15:13:53
karlosz
just discovered that the sub-4GB restriction on immobile space is purely artificial and only serves x86-64, so removing that now
20:26:35
Colleen
<Grolter> I think I found the source of delay in harmony: mixed:mix sometimes blocks for too long (~50 ms) when called on mixed.pulse:drain. It seems to be pulseaudio related bug, though I'm not sure
20:36:35
Colleen
<shinmera> Pulse and most other shared audio systems will do their own buffering. If the buffers are full, their synchronous apis will block. I think that's what you're seeing there.
20:40:26
Colleen
<shinmera> I think what we would need is some way to trace latencies of individual samples. Meaning: change the mixed_bip_buffer to keep two arrays, one of the actual sample, and one of sample timestamps. When producing samples, use the current utime for the sample. When transferring, just copy it over. When mixing, pick the older. Then we can measure the in-pipeline latency from source to any point in the pipeline
20:40:40
Colleen
<Grolter> However, it is probably a bug. There is a problem with playing voices simultaneously, there is a noticeable delay. It disappears when I switch to alsa
20:42:01
Colleen
<shinmera> It may also not be a bug and simply be an artefact of using pulse's "simple" api. They have a more complex API that might not have the buffering behaviour
20:50:43
Colleen
<shinmera> Yeah, I was just wondering if other stuff like SDL2, OpenAL, Jack, PipeWire, would also reproduce the delay or not.
20:52:21
Colleen
<shinmera> It's odd, because when you use Alsa with Pulse active, it'll actually route through Pulse anyway.
20:53:15
Colleen
<shinmera> yes, but any program that connects to alsa with pulse active will pipe through pulse instead
20:53:29
Colleen
<shinmera> because alsa only supports one output program per device, it doesn't do any mixing.
20:57:07
Colleen
<shinmera> it looks like we currently pass NULL as the pa_buffer_attr to pa_simple_new
20:57:34
Colleen
<shinmera> so we should construct a pa_buffer_attr struct and fill it with the data corresponding to the pack's size
21:24:57
Colleen
<shinmera> though you'll probably need to convert that, since for packs the size is number of bytes, not samples/frames.
21:27:41
Colleen
<shinmera> Anyway, I'll leave you to it. This gal here is too tired and needs some beauty sleep