I think ALSA would be better if it had actual documentation for more than like 10% of it.
Uncategorized
25
Posts
5
Posters
6
Views
-
I think ALSA would be better if it had actual documentation for more than like 10% of it.
today I learned that if you use snd_seq_create_simple_port to create a MIDI input port, it will just use the direct queue by default, which means there's no buffering of input events. If you don't process them continuously they just drop, which results in fun things like stuck notes.
-
today I learned that if you use snd_seq_create_simple_port to create a MIDI input port, it will just use the direct queue by default, which means there's no buffering of input events. If you don't process them continuously they just drop, which results in fun things like stuck notes.
that's one cursed ALSA MIDI mystery down. the remaining one is "why does the midi sequencer speed sometimes speedup significantly"
-
that's one cursed ALSA MIDI mystery down. the remaining one is "why does the midi sequencer speed sometimes speedup significantly"
@aeva super worried about when I have to actually work with this thing
-
@aeva super worried about when I have to actually work with this thing
@mcc so, I'm not totally sure this isn't just my imagination, but I think switching my laptop's power mode from "balanced" to "performance" while running on battery causes the problem to get worse, which is how I arrived that at my current theory which is that ALSA is not using a stable clock for the MIDI sequencer.
-
@mcc so, I'm not totally sure this isn't just my imagination, but I think switching my laptop's power mode from "balanced" to "performance" while running on battery causes the problem to get worse, which is how I arrived that at my current theory which is that ALSA is not using a stable clock for the MIDI sequencer.
@mcc My other theory is that this might be a consequence of having the jack audio thread crank the synthesizer, which in turn reads events off the ALSA input port, which means an intermittent batched processing thing is periodically polling a real time event source. However, I am under the impression that the audio thread wakes at a fixed cadence, and this wouldn't ever cause the song to get faster just compressed in weird ways, which is not what it sounds like.
-
@mcc My other theory is that this might be a consequence of having the jack audio thread crank the synthesizer, which in turn reads events off the ALSA input port, which means an intermittent batched processing thing is periodically polling a real time event source. However, I am under the impression that the audio thread wakes at a fixed cadence, and this wouldn't ever cause the song to get faster just compressed in weird ways, which is not what it sounds like.
@mcc my best guess on how to solve this is to turn off timestamps on the input port's queue (which preserves the timestamps written by sequencer applications, and then figure out how to translate the two different disjoint timestamp formats into relative time offsets so I can use the audio thread's cadence to regulate playback.
Or see if there's some way for me to tell ALSA when to advance the input queue and by how much (so far as I can tell there is no such mechanism)
-
@mcc my best guess on how to solve this is to turn off timestamps on the input port's queue (which preserves the timestamps written by sequencer applications, and then figure out how to translate the two different disjoint timestamp formats into relative time offsets so I can use the audio thread's cadence to regulate playback.
Or see if there's some way for me to tell ALSA when to advance the input queue and by how much (so far as I can tell there is no such mechanism)
@mcc a third option is I don't use ALSA for playing MIDI files and instead build that functionality into mollytime directly, and just treat ALSA as a means of connecting to MIDI hardware.
This is probably the best option, for also being the most portable :/
-
undefined oblomov@sociale.network shared this topic
-
@mcc my best guess on how to solve this is to turn off timestamps on the input port's queue (which preserves the timestamps written by sequencer applications, and then figure out how to translate the two different disjoint timestamp formats into relative time offsets so I can use the audio thread's cadence to regulate playback.
Or see if there's some way for me to tell ALSA when to advance the input queue and by how much (so far as I can tell there is no such mechanism)
@aeva @mcc I don't know the details of ALSA, but I don't think you want your realtime audio thread processing MIDI events. Ideally, process the events in another thread (via a callback, if there's an API for that) and put them in a data structure that the realtime thread can read later. Don't trust the OS queue for anything. I don't know why ALSA drops messages, but I remember that MacOS had other forms of brittle weirdness in its MIDI queue.
-
@aeva @mcc I don't know the details of ALSA, but I don't think you want your realtime audio thread processing MIDI events. Ideally, process the events in another thread (via a callback, if there's an API for that) and put them in a data structure that the realtime thread can read later. Don't trust the OS queue for anything. I don't know why ALSA drops messages, but I remember that MacOS had other forms of brittle weirdness in its MIDI queue.
@aeva @mcc okay, I attempted to read the ALSA documentation, and there is indeed a facility to queue MIDI messages. But I don't understand it. It seems to be oriented towards playing back MIDI files.
Writing your own event list structure avoids all this stuff, but then you have to maintain it yourself. So I dunno.
Mostly I just use RtMidi in C++, which wraps everything in a simple, but limited, cross-platform API.
-
I think ALSA would be better if it had actual documentation for more than like 10% of it.
@aeva Thankfully Pipewire is here to save us with less than 1% documentation.
Wait
-
@aeva @mcc okay, I attempted to read the ALSA documentation, and there is indeed a facility to queue MIDI messages. But I don't understand it. It seems to be oriented towards playing back MIDI files.
Writing your own event list structure avoids all this stuff, but then you have to maintain it yourself. So I dunno.
Mostly I just use RtMidi in C++, which wraps everything in a simple, but limited, cross-platform API.
@sixohsix @mcc I have the message queueing set up, but the problem is you seem to have two choices:
option 1: you tell alsa you care about time stamps: the sequencer takes care of reconciling everything into a compatible time point, and your application only receives events with a unitary time point: the only time is "now".
-
@sixohsix @mcc I have the message queueing set up, but the problem is you seem to have two choices:
option 1: you tell alsa you care about time stamps: the sequencer takes care of reconciling everything into a compatible time point, and your application only receives events with a unitary time point: the only time is "now".
@sixohsix @mcc option 2: you tell alsa you do not care about time stamps: alsa leaves the time stamps in messages as they were recorded if they have them. god help you if you have multiple MIDI streams feeding the same port, because they will either have "realtime stamps" which are time points relative to that the output queue that event was written to, or they will be in "ticks" which is the same thing except the duration is variable
-
@sixohsix @mcc option 2: you tell alsa you do not care about time stamps: alsa leaves the time stamps in messages as they were recorded if they have them. god help you if you have multiple MIDI streams feeding the same port, because they will either have "realtime stamps" which are time points relative to that the output queue that event was written to, or they will be in "ticks" which is the same thing except the duration is variable
@sixohsix @mcc in theory you could build a sequencer that does the same thing as what alsalib does under the hood in the first scenario, but as far as I can tell you can't actually read a common reference point for a given event's time offset, so for all intensive porpoises you only have one time point for everything in both cases: "now".
-
@sixohsix @mcc in theory you could build a sequencer that does the same thing as what alsalib does under the hood in the first scenario, but as far as I can tell you can't actually read a common reference point for a given event's time offset, so for all intensive porpoises you only have one time point for everything in both cases: "now".
@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.
-
@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.
-
@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.
-
@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 Thankfully Pipewire is here to save us with less than 1% documentation.
Wait
@shinmera that's fine. all of the linux audio applications that will ever exist have already been written
-
@aeva Did you see
https://stackoverflow.com/questions/76714223/alsa-midi-getting-precise-timestamps-on-input ?It seems to explain this, I guess.
-
@aeva Did you see
https://stackoverflow.com/questions/76714223/alsa-midi-getting-precise-timestamps-on-input ?It seems to explain this, I guess.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@bri7 wow
-
@oloturia non credo che ci sia niente che impedisca ai buoni pasto di essere fatti in quel modo :D
e se serve per rompere l'impero di edelred e quegli altri stronzi…
-
@ahchay @gilesgoat @Mafalda @llamasoft_ox i hate it but very occasionally I use deepseek. When I'm just struggling with regular search. Engines, I use it as a search engine.
It's very interesting because it shows you its background 'thinking' where it says things like, 'i must validate the users point of view'
And i always think, "why must you? I might be an idiot "
If search engines still worked, and there was actual information at the end of them instead of ai articles, I probably wouldn't need to use ai at all
-
@budfox
Mi sento molto: "yankees go home. Let's go Vikings"
#fucktrump
-
@ten700 @infinity999 voto NO nordio
-
@tofugolem @Rojertb why not send the king the and leave it there for good?
-
@infinity999 Nordio ragiona da mafioso.
-
@stefano Maybe someone is pinging you using IPoAC (RFC 1149)? But your firewall/window is dropping the packet.
