Re: New FreeBSD port ALSA to JACK MIDI, a2jmidid

Hi,

On 2/20/22 16:54, Florian Walpen wrote:
> Sorry for the delay.
> 
> On Saturday, February 12, 2022 2:07:03 PM CET Hans Petter Selasky wrote:
>> On 2/12/22 12:52, Florian Walpen wrote:
>>> Does it have an impact on usability or latency (or latency correction)?
>>
>> No, jack is already slow, so no implications here.
> 
> That's probably due to jack processing in cycles, but I'd have to verify.
> Unfortunately I can't measure MIDI latency right now, have to get some cables
> from the practice room next week.

Cool!

> 
> I suppose MIDI messages are sent out-of-band for USB devices? Thus not being
> subject to the OSS queuing delays? I'm not sure yet how jack and clients deal
> with the different latency.
> 
>> My idea is to have one MIDI server (ALSA based) to allow the same MIDI
>> device to be shared by multiple devices. Also applications can create
>> virtual ports. Yeah, MIDI is a bit complicated. Too many APIs.
> 
> I gave it a test run, and both bridging and device detection seem to be fine.
> Nice work there!
> 
> One thing I noticed was that our hardware MIDI ports are detected as software
> ports by a2jmidid. Or at least they were bridged, even though a2jmidid
> excludes hardware ports by default. Intentional?
> This may confuse some client applications, if they rely on this distinction.

You can change that easily. See:

https://github.com/hselasky/alsa-seq-server/blob/8dc8bae3900b5c6332be723308d8033423d9e66c/alsa-seq-server.c#L1709

	port->type = SNDRV_SEQ_PORT_TYPE_MIDI_GENERIC;

> 
> On a side note, there's also an ALSA sequencer MIDI backend in jack, but it's
> tied to the ALSA driver and not available when choosing the OSS driver. So we
> can't use that instead of a2jmidid. BTW the ALSA option of our jack port is
> off by default.

Yes, I tried to look at that too, but a2jmidid was easier.

> 
> But all in all this looks like a promising approach.
> 

Thank you!

--HPS