Re: [LAD] on the soft synth midi jitters ...

On 05/10/10 18:51, Arnout Engelen wrote:
> On Tue, Oct 05, 2010 at 03:12:12PM +1100, cal wrote:
>> [ ... ]
>> latency in a soft synth (possibly yoshimi) ...
>
> Latency? Or jitter?

Not sure - possibly the main reason for the post was to seek help in resolving
fallacies in my thinking. With a jack period of 128, a midi event associated
with frame 129 won't actually get applied to audio generation until the
generation of frames 257-384. On the other hand an event against frame 128 will
make it into the generation of frames 128-256. I figure that variability of
effective midi latency according to where the event sits in the period probably
qualifies asjitter?
  
[ ... ]
>
>> What seemed most promising was to break the audio generation into smaller
>> blocks, applying pending midi events between blocks.
>
> Isn't this what JACK does by choosing a period size? Splitting up the
> processing withing a period like this seems odd.

I'm often all too comfortable with odd experimentations.
  
> I'm assuming you're talking about ALSA MIDI, here not JACK MIDI - is that
> correct?

No, same applies to both.
  
>> Sadly, that drags the creation and destruction of note objects into the
>> realtime jack process callback path. (...) Even with a pool of pre-allocated
>> note objects, it seems the amount of initialization code per note is still a
>> real limiting factor on how busy things can get before it all falls apart.
>
> Of course allocation is forbidden in the process() callback, so that's off
> limits anyway. Using pre-allocated notes, it sounds kind of unlikely to me
> that initializing your note objects is the bottleneck. It seems more likely
> to me that your way of getting the notes from the MIDI device (again - is this
> ALSA midi? Can you share code/patches?) is not RT-safe. Have you tried running
> it with http://repo.or.cz/w/jack_interposer.git ?

Never heard of it but will investigate, thanks.
  
> To 'solve' ALSA MIDI jitter for JACK, you'll have to receive ALSA MIDI messages
> in a seperate thread, and make sure you apply them at the right position in the
> process buffer based on a timestamp telling you when exactly the note event was
> recorded.

A dedicated thread for alsa midi is what I've been using along. At the moment I'm
exploring using an alsa timer callback, and I quite like that.
  
> With JACK MIDI, JACK takes care of the recording MIDI events and timestamping
> them in a sample-accurate way - all you'll have to do is make sure you do take
> into account the timestamp to correctly place them in the process buffer.

I wish that that was "all you have to do". I think the crux of the biscuit is that
given the way zyn/yoshimi does its magic, you simply can't have a midi event
changing note or controller parameters during the generation of a given period of
audio. Hence it's impossible to accurately honor the frame/time stamp of a midi
event. That's what drove drove the experimentation with splitting the audio
generation down to tighter blocks.
  
> This will only 'solve' jitter though: a latency proportional to the period size
> is inherent to the way JACK works I'm afraid. Hence the desirability of tuning
> your system to allow for low period sizes.

Precisely. I think the bottom line is that I've tried real hard, but the best you
can expect from zyn/yoshimi is determined by how tight you can get your jack period
with reliability - short of a radical re-engineering of the zyn internals, in which
case it'll be a whole new synth :-).

cheers.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Oct 5 16:15:01 2010