I think ALSA would be better if it had actual documentation for more than like 10% of it.

[aeva@mastodon.gamedev.place]

@sixohsix @mcc this is probably fine in most cases since the events are expired as soon as they're created anyway. a midi packet is HOT HOT HOT and should be processed ASAP anyway. But WHERE is "now"? do you have a clock that if you sample it and then sample it again a second later will give you exactly a second of time between the two samples? no. you do not.

[aeva@mastodon.gamedev.place]

@sixohsix @mcc not in a random userland thread at any rate. time is stretchy. now, the audio thread as it happens is a lot more precisely timed than regular threads, and you can say ah, I'm currently processing ticks N through N + 1024, where a tick is exactly 1/48000 sound card seconds.

[aeva@mastodon.gamedev.place]

@sixohsix @mcc but ALSA insists that there is a "now", and that "now" is a thing that is real and exists, and has a clock and that clock moves forward in fixed increments, and never throttles, and so on. ALSA, despite also having this concept of batched time in its audio processing model i'm pretty sure, does not seem to believe that midi would ever be processed precisely, or need a be sieved in ~0.02 second chunks.

[aeva@mastodon.gamedev.place]

@sixohsix @mcc I would be shocked if RtMidi has a solution for this that isn't sweeping it under the rug and hoping nobody notices. MIDI is the old half-abandoned mall inside your computer.

[aeva@mastodon.gamedev.place]

@shinmera that's fine. all of the linux audio applications that will ever exist have already been written

[jens@social.finkhaeuser.de]

@aeva Did you see
https://stackoverflow.com/questions/76714223/alsa-midi-getting-precise-timestamps-on-input ?

It seems to explain this, I guess.

@sixohsix @mcc

[aeva@mastodon.gamedev.place]

@jens @sixohsix @mcc I hadn't, and while the poster notably has encountered the same problem, the answer given is bullshit

[jens@social.finkhaeuser.de]

@aeva @sixohsix @mcc How so, if I may ask?

[aeva@mastodon.gamedev.place]

@jens @sixohsix @mcc ok let's rephrase the question: "I have a set of packets that have time stamps. Half of them have a known interval, but have an arbitrary uncorrelated origin. The other half have an unknown interval, and an arbitrary uncorrelated origin. In both cases, the origin can randomly *change* while playing. How do I put all of these into one common reference frame?"

The answer of "ALSA uses one of your system's clocks internally!" does not answer this question.

[jens@social.finkhaeuser.de]

@aeva Yeah, that's not going to be solved by ALSA, however, if the origin *changes*.

@sixohsix @mcc

[aeva@mastodon.gamedev.place]

@jens @sixohsix @mcc personally, I think ALSA *should* solve the problem, because ALSA creates the problem.