[linux-audio-user] Python & ALSA --- documentation

[Rob Fell]

Peter Brinkmann wrote:

> Let's see whether I got this right: You have two producers of events,
> your MIDI hardware and your GUI. You want to have one consumer of events
> that favors hardware events and only processes GUI events when no hardware
> events are available.

Correct.

> If this interpretation is correct, then my first idea is to set up
> your threads to reflect this structure: Take two queues, q1 and q2,
> (in the sense of thread-safe FIFO from the Python package Queue, not
> ALSA queues). The MIDI thread of pyseq writes to q1 (and doesn't do
> anything else), and the GUI thread writes to q2.
> 
> Now you take a third thread that consumes events from q1 as long as
> q1 isn't empty, and consumes events from q2 only after exhausting q1.
> 
> Is this closer to what you have in mind?

Functionally that would produce the desired result.

Perhaps I've misunderstood the ALSA implementation, but a sequencer 
client can't rely on the persistence of the event (snd_seq_free is 
deprecated) - so it would have to be deep copied for queuing.  The 
embedded s/w eng. in me shies away from copying data unnecessarily.

> You say you want to stall GUI interaction while real events are available,
> but I don't see how this would work in practice. Since the computer can
> process events at a much higher rate than the MIDI hardware protocol can
> deliver them, there should always be time for the GUI to squeeze in an
> event or two.

Enumerating large dictionaries containing patch data and song groups for 
the GUI seems to be the most troublesome case, but probably as a 
side-effect of my data structure design.

I think my app. needs a redesign.

cheers
Rob