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

[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.

[mcc@mastodon.social]

@aeva @jens @sixohsix I think RtMidi's solution to this is "each MIDI source/sink has a different, internally consistent but uncorrelated timescale, and you figure this out yourself" and it's been a real long time but I *think* CoreMidi uses the Darwin kernel's monotonic clock but they had some of the best audio programming engineers ever work on keeping it consistent…? Frankly I'm not sure there's a better solution than RtMidi's because the API doesn't know your program requirements

[mcc@mastodon.social]

@aeva @jens @sixohsix In a sense *MIDI itself* is supposed to be the solution to this problem, you're supposed to connect all your equipment via MIDI cable and *the MIDI protocol* is what puts everything on a single clock with a single origin moment. And then we replaced MIDI transport with USB which not only unsolves the problem but probably adds additional timing uncertainty.

Maybe MIDI-2 solves this, but I don't see anyone using it and I'm concerned about the requirement to register devices.