[CM] Fwd: Linux/Midi Test

lieven moors lievenmoors at gmail.com
Tue Aug 11 05:30:44 PDT 2009


I just did, but it doesn't seem to help. I'll have to do some more 
testing...

Heinrich Taube wrote:
> you might try adding that line to  sendMessageNow()   in 
> cm/src/juce_Amalgamated.cpp  then remake grace and test your example 
> again (audio on my linux emulator doesnt work at all so i cant test it 
> myself today)
>
> On Aug 11, 2009, at 6:57 AM, lieven moors wrote:
>
>> 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.
>>>
>>>
>>
>> _______________________________________________
>> Cmdist mailing list
>> Cmdist at ccrma.stanford.edu
>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
>
>



More information about the Cmdist mailing list