Re: [Jack-Devel] Jack2 alsarawmidi slave: Pluggable device registration problem?

On Thu, Oct 2, 2014 at 3:56 PM, Tim E. Real <[hidden]> wrote:

> As Dan mentions, we are keen to finish this driver because it,
> along with the corresponding alsamidi Jack1 driver, is being touted
> as the replacement for the raw and seq drivers.

Corresponding?  I thought JACK 1's 'alsamidi' driver was based on
Nedko's work.  Is there a port of 'alsarawmidi' to JACK 1?  I think I
heard at some point that this might be done, but I haven't heard
anything beyond that.

> Devin, the old raw driver seems to detect and remove devices just fine.
> Is there something that would not be right, some ugliness, in using that
> existing code?

One of the reasons I didn't port over that code is because it was a
hacked up way of trying to do what the ALSA seq MIDI driver did.  I
was hoping to find a more elegant solution.  If there *really* isn't a
better solution, then I suppose it's okay, but it should really be
documented as being hacked-up code that should be replaced if and when
a more elegant solution is available.

I wonder if it's possible to use the ALSA seq notification solution to
trigger a device refresh in the 'alsarawmidi' driver.  The idea also
feels hacky, but at least there wouldn't be a thread endlessly polling
for new devices every two seconds.

> I looked at the code in the old raw driver and this newer one.
> I /think/ I might be able to try it, no stranger to alsa here, but the two
> code bases are quite different, I'm not sure where to 'put' any new stuff.

The complex part, I think, is going to be interfacing with the poll
thread and the JACK thread.  You need to push a new set of file
descriptors to the poll loop each time a device is added or removed
without interrupting the poll loop for too long, and you need to
attach new ports that JACK knows about.

I haven't looked at the code in a while, but I'd either create a new
class to handle device polling, or put the code in the main driver
class, depending upon how much the code needed to know about the
private data in the main device class, and how much would need to be
added to the main driver class' public interface to make things work
with a separate class.  Maybe I'd revamp the whole thing.  IDK.

I'll try to refamiliarize myself with the code at some point in the
near future so that I can help out to whatever extent I'm able, given
the amount of free time I have.

Thanks,

-- 
Devin Anderson
surfacepatterns (at) gmail (dot) com

blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/

1412324606.29159_0.ltw:2, <CAG7zqTqTrCrnw8Dvozt1vL792=ouCWjhiq5DziwQTVt1ksdW6Q at mail dot gmail dot com>