I'm slowly working through the vulkan spec writing a compute-only vulkan program from scratch that doesn't render anything, and it's going pretty well because the spec is really well written and I already know more or less exactly what I want to do anyway, but I just want to say just how silly (fun) it feels to write a program like this because you get to just skip over large swaths of the API.
Like, I'm working from the spec because the tutorials all make it more complicated.
I think it's cute that practically every vulkan command has one or more optional args to let you enter Hard Mode
(sorry for the double post, I added this to the wrong thread)
I wonder how many people have actually managed to knuckle down and write a complete, useful vulkan program from scratch (no copy pasting from tutorials and stack overflow, no offloading significant parts to 3rd party libraries like VMA)
To think if I power through and get this thing working I could potentially be like the 20th person to bother
oh, update on my little vulkan compute project, last night I got as far as repeatedly dispatching an empty compute shader and allocating some memory 😎 I'm in the home stretch! I think I just need to figure out the resources / resource binding stuff and then I'll be able to start on my DSP experiment :3
which mostly means the next things are figuring out the least effort way of getting audio data into C++ (probably stb_vorbis?) and writing even more boilerplate for alsa...
I reworked it so the convolution shader processes the audio in tandem with playback, so I'm *very* close to getting this working with live audio streams.
But more importantly, I used this to convolve my song "strange birds" with a choir-ish fanfare sound effect from a game I used to play as a kid and the result is like the grand cosmos opened up before me and I'm awash in the radiant light of the universe. Absolutely incredible.
ok the problem I'm having with latency now is that the audio latency in the system grows over time and I'm not sure why. like it starts snappy and after running for a short while it gets super laggy :/
I'm guessing it's because SDL3 can and will resize buffers as it wants to, whereas I'd rather it just go crazy if it under runs.
What I want to do is have a fixed size buffer for input and output, enough that I can have the output double or tripple buffered to smooth over hitches caused by linux. if my program can't keep up I don't want it to quietly allocate more runway I want it to scream at me LOUDLY and HORRIBLY, but it wont do that because I'll rejigger my program until it is perfect.
What actually happens is (sdl? poopwire?) just infinitybuffers so it never hitches and I get a second of latency after a little bit
I'm like 30% sure SDL3 is not the problem or at least not the only problem because I tried resetting the streams every frame with SDL_ClearAudioStream and it still accumulates latency (in addition to also now sounding atrocious due to missing samples).
I've also seen this happen with pipewire before in other situations, and it was resolved by bypassing pipewire.
ok I did it. I've got a program that writes a pipewire stream of F64 audio samples where each sample is the total elapsed time since the first frame, expressed in mintues.
I've got a second program that reads that pipewire stream, and checks the offset against it's own elapsed time since the first sample processed. This program prints out the calculated drift ever second.
The results are interesting.
In the first version of this, both programs just measured the time using std::chrono::steady_clock::time_point. This resulted in an oscillating drift that was well under a millisecond at its peak and nothing to be concerned about.
This is good! That means there's no place what so ever within pipewire on my computer for this specific audio setup where any intermediary buffers might be growing and adding more latency as the programs run.
This is not the interesting case.
In the second version, I changed the first program to instead calculate elapsed time as the frame number * the sampling interval, and left the second program alone.
In this version, the calculated drift is essentially the difference between the progress through the stream vs the amount of time that actually passed from the perspective of the observer. In this version, the amount of drift rises gradually. It seems the stream is advancing just a touch faster than it should.
The samples in the stream are reporting that more time has elapsed in the "recording" than actually has transpired according to the clock. The amount of drift accumulated seems to be a millisecond every few minutes.
I'm honestly not sure what to make of that.
@shinmera this is what I found https://docs.pipewire.org/page_tutorial.html
maybe newbie friendly isn't the right term, but it's probably sufficient for my needs
@aeva @shinmera yeah I'm very frustrated by pipewire both their documentation and base API choices are not my favorite. The API is extremely flexible but in a weird way where without examples and norms that don't appear to be defined anywhere as standards you can't actually do anything.
Like the magic that makes pipewire actually glue itself to things besides just being a bus that routes stuff is mostly/all in its plugins which are barely documented and other programs just kind of have to know what SPA configs do what. Very very strange interface imo and not good when coupled with no standards. At least Wayland has explicitly defined protocols and such.
That being said it'd be pretty trivial to make this better so I hope that it does get there eventually.
@aeva Was surprised and horrified to learn the solution to latency in Resolve through pipewire is... ...to install pulse.
Like ffs, linux audio, disenfuck yourself.
@aeva 🤔 my impression is that, if the layers outside of your code are dynamically growing in order to deal with some latency deadline not being met, you'd hear at least one glitch in the audio each time it has to grow. otherwise, how would it know the application/usage layer failed to fill the output audio buffer in time?
maybe something else is happening? which audio API are you using? it looks like SDL has multiple.
@aeva that's insane and i don't have any suggestion except to use something else for audio. if that's true they have made the problem way more complicated than it actually is.
(i am a professional programmer who does audio, including having done commercial embedded projects using linux with custom audio stuff)
@cancel I believe SDL is using pipewire by default. If I set it to ALSA it prints an error but otherwise behaves the same, suggesting it falls back to pipewire. If I set it to jack it freezes.
FWIW I have also seen this behavior with pipewire.