Hi,
I've observed a scenario in ALSA that I would like some feedback on solving. On Linux, Chrome uses seq for WebMIDI. Eventually, there will be hotplug detection code in Chrome that looks like this:
1. Connect to announce port 2. Listen for any announcements for client/port start/end 3. Send MIDIConnectionEvent events to JavaScript clients ( http://webaudio.github.io/web-midi-api/#midiconnectionevent-interface)
Here is the scenario where this fails:
1. Cold boot a machine with no MIDI devices plugged in 2. Start client, subscribe on the seq announce port 3. Insert USB MIDI device 4. snd_rawmidi module is loaded, triggered by insertion of MIDI device 5. snd_seq_midi is NOT loaded, but marked for loading later
At this point, there is no client start event sent to the announce port. This is because of the deferred module loading, which won't trigger except for a handful of operations (snd_seq_client_info_get_client is an example).
This is easily replicated with looking at aseqdump -p 0:1.
My question is: how to solve this? There are a few options:
1. Periodically poll for new clients. This is fairly ugly, but will work to trigger module loading and won't result in latency once any device has been plugged in, since announce will again work.
2. Somehow trigger module loading if there are any clients listening on the announce port. This seems pretty tricky and requires keeping track of some new state.
3. Do away with deferred module loading in seq. This is pretty invasive and would increase the number of modules loaded, but would result in a lot of deleted code in the kernel and a clean fix.
Number 3 is my preferred solution, but I wanted to see if these sorts of patches would be acceptable, since it is invasive and would result in more modules loaded.
Thanks for any comments.
Adam