[CM] Fwd: Linux/Midi Test

[lieven moors]

I think I might know what the problem is with Juce. I had a look at the 
Juce code myself,
and it looks like sendMessageNow() is not calling the 
snd_seq_drain_output().
this is an excerpt from the ALSA API documentation:

    If the event is sent immediately without enqueued, the sender 
doesn't take care of queue and timestamp. As well as the case above, 
there     is a function to set the direct delivery, 
snd_seq_ev_set_direct() 
<http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gdda452e0b4ea3b5f722795d015159388>. 
The program can be more simplified as follows:

	void direct_delivery(snd_seq_t <http://www.alsa-project.org/alsa-doc/alsa-lib/group___sequencer.html#g527eff2e3b3c7dd45cac6fdd2ceee964> *seq)
	{
        snd_seq_event_t <http://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__event.html> ev;

        snd_seq_ev_clear <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#g6ed1a615ac4c8f02832198ab04fa8f55>(&ev);
        snd_seq_ev_set_source <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gabdd5b232c8f306b4ced5eb7edf12844>(&ev, port);
        snd_seq_ev_set_subs <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gd61b73ca763e011b23df35dc746ad760>(&ev);
        snd_seq_ev_set_direct <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gdda452e0b4ea3b5f722795d015159388>(&ev);
        ... // set event type, data, so on..

        snd_seq_event_output <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_event.html#g8b955646b0cc007f6435f9ab8f1b7228>(seq, &ev);
        snd_seq_drain_output <http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_event.html#g841a0cc485b82fd0b80c92274dfe36c0>(seq);
	}

    You should flush event soon after output event. Otherwise, the event 
is enqueued on output queue of ALSA library (not in the kernel!), and 
    will be never processed until this queue becomes full.


I sounds like this might be excactly what happens....
I wonder what you or Andrew think about this, because I'm not too sure 
about it.
It seems almost too simple to be true.





Heinrich Taube wrote:
> andrew thank you soooo much for your effort. maybe i could post your 
> code to the juce linux group to see if they have any ideas?
>
> Begin forwarded message:
>
>> From: William Andrew Burnson <burnson2 at illinois.edu>
>> Date: August 10, 2009 10:04:20 PM CDT
>> To: taube at illinois.edu
>> Subject: Linux/Midi Test
>>
>> I wrote a simple JUCE console program to just spit out midi messages 
>> to Timidity in a single thread. I got the same results as we saw 
>> earlier today. I didn't even put the thread to sleep--I just had it 
>> spin through the hi-res timer until the right time and then used 
>> sendMessageNow to fire the MIDI messages. It was just as jerky.
>>
>> This means there is nothing you can do about this without going to a 
>> deeper level such as writing your own interface to ALSA. Whatever 
>> JUCE is doing doesn't seem to be sufficient for any kind of time 
>> precision.
>>
>> I suppose there are two types of uses of MIDI:
>> MIDI -> Soundfont -> Audio
>> In this case, there should be no reason why somewhere you couldn't 
>> specify "future" midi messages into the ALSA/Timidity bridge and it 
>> would render them precisely where they needed to be in terms of 
>> sampled audio.
>>
>> MIDI -> External device
>> In this case, you would want access to a SMTPE clock.
>>
>> I am not sure if the kernel will make a difference. In any case, we 
>> could try my test program on different kernels to see, but I'm 
>> guessing it's a JUCE issue.
>
>