Interfacing to MIDI (sequencer) devices via ALSA on Linux

[Jurassic Pork]

Hello,
finally the project LazarusRtMidi doesn't use the rtMidi library but the Alsa library. You can see how they manage the midi Input with a thread and a loop in the unit RtMidi:

Code: Pascal  [Select][+][-]

1. procedure TMidiIn.InputThread;
2. VAR r:integer;
3.     ev:psnd_seq_event_t;
4. VAR nBytes:integer;
5. begin
6.   ThreadTerminated:=false;
7.   r := snd_midi_event_new( 32, @data.coder );
8.   if ( r < 0 ) then exit;
9.   snd_midi_event_init( Data.coder );
10.   snd_midi_event_no_status( Data.coder, 1 ); // suppress running status messages
11.   while not ThreadTerminated do
12.   begin
13.     r:= snd_seq_event_input( Data.seq, @ev );
14.     if ( r <= 0 ) then
15.        continue;
16.     nBytes := snd_midi_event_decode( Data.coder, @data.buffer, 32, ev );
17.     if ( nBytes > 0 ) and assigned(OnMidiInput) then
18.       OnMidiInput(data.buffer,nBytes);
19.     snd_seq_free_event(ev);
20.   end;
21. end;

click to the attachment to see animation.

Friendly, J.P

[MarkMLl]

I will try one last time. I am not trying to do a demo of LazarusRtMidi. I am trying to do a demo to go with my own transcription of the ALSA headers, which I have done in such a way that they can be linked statically or dynamically without change to the caller.

As things are right now, I'm left feeling that it would be best if I deleted the work I'd done, deleted the stuff I put on Github a year or so ago, and walked away.

MarkMLl

[Fred vS]

Hello,
finally the project LazarusRtMidi doesn't use the rtMidi library but the Alsa library. You can see how they manage the midi Input with a thread and a loop in the unit RtMidi:

Hello JP.

Génial! 
Many thanks.
Fre;D

[Fred vS]

As things are right now, I'm left feeling that it would be best if I deleted the work I'd done, deleted the stuff I put on Github a year or so ago, and walked away.

MarkMLl

Hello Mark.
Why?
The game is not over yet, many things to complete before to have a real out-of-the-box ALSA midi sequencer.
Your work is useful.

Fre;D

[MarkMLl]

Your work is useful.

Thanks. Right now I'd settle for getting the demo for that specific library working, since once the declarations are believed to be adequate we'll have some credibility asking the ALSA developers how to do things.

My older code was much more verbose: I suspect /unnecessarily/ verbose with explicit handling of every incoming event. It also had a great deal of complex device selection stuff, vastly more than is needed in the current case where everything is driven from the command line, and I /really/ don't want to go back there if it's avoidable.

Still waiting for the correspondence to arrive that I should be working on...

MarkMLl

[Fred vS]

Hello Mark.

To have a "pure direct ALSA midi" package like you want, imho the idea of JP to take inspiration from RtMIDI is great.

There is a github project in C ( the original is in Perl ):

[EDIT] This is the official site:
https://github.com/thestk/rtmidi

In their code they use:

Code: C  [Select][+][-]

1. #if defined(__LINUX_ALSA__)

And then they call methods from alsa lib.

( And the C methods are easy to translate into Pascal  ).

[Fred vS]

Ha, ok, I think I get it, RtMidi is not a library but set of methods.

https://github.com/RuudErmers/LazarusRtMidi
Is the translation in Pascal of
https://github.com/thestk/rtmidi

Nice gem JP 
Imho, the project is great but should be completed with demos ( like you did ) and explanation how to deal, easily and out-of-the-box with MIDI devices and midi files.

[MarkMLl]

Some of the correspondence I was waiting for has arrived, so I have limited time for this at present: and as I've said, anything anybody can do to check my work is appreciated.

I'm currently looking at BeepDemo (supplied as one of the demo programs in the .zip I posted a couple of days ago) and notice that I can't use  aconnect -d  to disconnect it from the physical device. However when I do an  aconnect -l  I notice

Code: Text  [Select][+][-]

1. client 20: 'MD100' [type=kernel,card=1]
2.     0 'MD100 MIDI 1    '
3.         Connected From: 128:0, 130:0
4. ...
5. client 130: 'WatchXyz' [type=user,pid=197824]
6.     0 'WatchXyz        '
7.         Connecting To: 20:0
8.  

ps won't show that process (197824),  top -H  does. I'm not sure how the kernel handles this internally (and it might vary depending on configuration option), but there's a possibility that some of the aconnect problems are caused by resources being allocated by a thread rather than by the main process.

I'd be surprised though if this had any impact on my attempted use of event filtering, since the filter demo isn't threaded.

I've been looking at www.alsa-project.org but there's lots of 404s. There's issues for alsa-lib on Github, and a rather quiet mailing list on Sourceforge. However I think we all need to be confident in my function definitions before staring to ask any questions in public: being told to go away and use a supported language would be damaging for all concerned.

MarkMLl

[Fred vS]

...
I've been looking at www.alsa-project.org but there's lots of 404s. There's issues for alsa-lib on Github, and a rather quiet mailing list on Sourceforge. However I think we all need to be confident in my function definitions before staring to ask any questions in public: being told to go away and use a supported language would be damaging for all concerned.

Yes, indeed, alsa-lib is still highly used ( even essential for Linux audio ) but the alsa-guru-maintainers disappear...
I remember few years ago Martin (from MSEgui) and I found a bug in alsa-lib, created a issue and after a (long) time there was a answer: "Sorry but we dont find anybody who has the skill to check your patch"... 

[Fred vS]

... I notice that I can't use  aconnect -d  to disconnect it from the physical device.

Following https://www.geeksforgeeks.org/aconnect-command-in-linux-with-examples/

1) Connect using one terminal:

Code: Bash  [Select][+][-]

1. > aconnect  130:0 129:0

Ok, virtual keyboard connected, amidi terminal answer to keys of the virtual keyboard.

2) Disconnect using other terminal:

Code: Bash  [Select][+][-]

1. > aconnect -d 130:0 129:0

Virtual keyboard disconnected, no more answer to keys of the virtual keyboard on amidi but process in first terminal is still running 

3) Reconnect using terminal 2):

Code: Bash  [Select][+][-]

1. > aconnect  130:0 129:0

Ok, virtual keyboard connected, amidi terminal answer back to keys of the virtual keyboard.

So maybe if using TProcess in thread, one connect with aconnect  130:0 129:0, a other to disconnect with aconnect -d 130:0 129:0 + force terminate thread-process one.

(I did not find a command to terminate the aconnect  130:0 129:0 process, maybe there is no other option than kill it after disconnect.)

[MarkMLl]

Except that I'm not using TProcess anywhere, only direct API calls. I've tidied a few cosmetics inside BeepDemo and might have an opportunity to look at things a bit more, but as a working hypothesis ALSA predates the current Linux thread architecture and is getting badly confused if device ownership (one end of a subscription?) isn't associated with the foreground thread.

However, that shouldn't have any effect on the filter demo which is single-threaded.

Later: All ALSA MIDI (sequencer) calls in BeepDemo are handled in the context of the background thread. aconnect hence presumably the ALSA libraries are from somewhere getting a PID corresponding to this, which has no immediate relationship to the threadID as understood by FPC: it's apparently being plucked from within the kernel at a level below the normal POSIX thread (NPTL) handling.

BeepDemo is useful for its original purpose, which is testing which APIs result in a useful alert (on Debian 12 "Bookworm" with KDE, all four buttons work). However it looks as though I also need a simpler MIDI test which either doesn't use a background thread or makes its use optional, and that's definitely not going to happen for at least a few days.

If the inability to connect/disconnect connections made by BeepDemo etc. is a thread issue, your (Fred) previous experience suggests that it probably won't be fixed. Which will be a great pity, if it results in the community being driven towards something even more complex written by a dissident such as Sievers or Poettering.

Even later: I do note however that the .so is loaded by the main thread, while it is actually used by the background thread. I'd not /expect/ that to be a problem...

MarkMLl