[LAD] [Fwd: Re: No nagging, a serious question]

[Ralf Mardorf]

On Sun, 2010-07-04 at 23:16 -0400, Paul Davis wrote:
> On Sun, Jul 4, 2010 at 5:16 PM, Dan Mills <dmills at exponent.myzen.co.uk> wrote:
> > This sort of issue is what the ALSA midi sequencer is really intended to
> > fix, by making midi timing a kernel problem rather then a user space
> > one.
> 
> the mistake there is that it makes the once-reasonable assumption that
> the required timing could only be accomplished in the kernel. this was
> once true, but its not anymore.
> 
> >It sort of solves HALF the problem, in that it makes getting midi
> > messages out on time more or less possible (at least on paper), but it
> > does nothing for reliably timestamping incoming midi using a clock that
> > can be related simply to the audio sample clock and which would thus be
> > useful when building software synths.
> 
> IIRC, you can set the clock source on an ALSA sequence queue to be the
> clock based on a PCM device.

Is it possible to make the ALSA MIDI latency test use the PCM playback
and PCM capture as clock source?

spinymouse11.2 at suse11-2:~> alsa-midi-latency-test --help
Usage: alsa-midi-latency-test -o client:port -i client:port ...

  -o, --output=client:port   port to send events to
  -i, --input=client:port    port to receive events from
  -l, --list                 list available midi input/output ports

  -R, --realtime             use realtime scheduling (default: no)
  -P, --priority=int         scheduling priority, use with -R
                             (default: maximum)

  -S, --samples=# of samples to take for the measurement (default:
10000)
  -s, --skip=# of samples    to skip at the beginning (default: 0)
  -w, --wait=ms              time interval between measurements
  -r, --random-wait          use random interval between wait and 2*wait

  -h, --help                 this help
  -V, --version              print current version