Re: [Jack-Devel] Call for testing of MIDI Drivers in JACK 2
On Wed, Apr 6, 2011 at 6:32 PM, Paul Davis <[hidden]> wrote:
> On Wed, Apr 6, 2011 at 9:24 PM, Devin Anderson <[hidden]> wrote:
>
>> I did occasionally reference the ALSA raw driver when I was writing
>> the 'alsarawmidi' driver; however, the code design is somewhat
>> different, and the driver doesn't have the same problems with scaling
>> and MIDI jitter that the ALSA raw and seq drivers have (with my
>> hardware, MIDI jitter would become more and more apparent as more
>> ports were used), or the problems with very low latencies and jitter
>> that the ALSA seq driver has. Of course, I've only tested the driver
>> on my own hardware so far, which is one of the reasons I sent out this
>> message in the first place.
>
> the key thing is to have your own thread that does the i/o. and maybe
> uses poll(2). most importantly is timestamping, which it sounds if you
> are doing if you're handling jitter.
This is exactly what's happening. I'm using 'ppoll' to handle polling.
When I first did research for writing this driver, I was looking
through the ALSA kernel code, and noticed that the default behavior
for the 'drain' method (when a driver doesn't set its own rawmidi
'drain' method) is to sleep for 50 milliseconds, and then return,
regardless of whether blocking I/O is used or not. So, one of the
things I did with the 'alsarawmidi' driver is to call:
snd_rawmidi_params_set_avail_min(rawmidi, params, 1);
... to make the driver wake up when any bytes are written to a port,
and to avoid calling `snd_rawmidi_drain` completely.
That might be a quick way to improve the 'raw' driver. IDK.
--
Devin Anderson
devin (at) charityfinders (dot) com
CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/
1302141387.3226_0.ltw:2,a <BANLkTin=4Z0Xj-K96dnnTebzo+Deut2WNw at mail dot gmail dot com>