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 <[email protected]> >>> Date: August 10, 2009 10:04:20 PM CDT >>> To: [email protected] >>> 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 > [email protected] > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist _______________________________________________ Cmdist mailing list [email protected] http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
