Re: [Lmuse-developer] whoa! muse 0.8.1 is damn fast

[Tim E. R. <ter...@ro...>]

On May 4, 2011 05:45:01 pm Tim E. Real wrote:
> On May 4, 2011 03:45:02 pm Robert Jonsson wrote:
> > 2011/5/4 Florian Jung <flo...@we...>:
> > > wtf? the ipc thread uses a timer?? why?
> > > why not simply using select(), poll() or epoll() on the communication
> > > pipes? or is communication done completely different? (never had a look
> > > to that)
> >
> > The reason it is IPC in the first place is that we have syncronisation
> > issues that somehow must be solved, otherwise we could just manipulate
> > the data directly. In this case we do the processing in the audio
> > thread context, the audio thread is callback driven and hence
> > periodically called.
> > I think it may be that the ipc was called from the midi thread
> > previously which has a much faster tick rate.
>
> Correct. MusE used to use the MS_PROCESS midi thread message, sent
>  from Audio::process1(), which then called Audio::processMidi(), for
>  processing midi, but somewhere along the way it was changed so that
>  Audio::processMidi() is called directly now from the audio thread.
I should elaborated a bit. 
Audio::processMidi() is where notes are 'gathered' to be played by
 both ALSA and Jack midi devices, and it is where Jack midi is processed
 and sent to Jack midi devices. But MidiSeq::processTimerTick(), in the
 midi thread, is where ALSA midi is actually processed and delivered to ALSA.

Tim.