Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Christian and all,

> > > > It needs to be debugged, for example by commenting out various synthesis
> > > > components to narrow down the source of this issue.
> > > 
> > > You can use me as your guinea pig - just give me a hint how and where I
> > > can
> > > comment/disable	them.
> > 
> > First of all, I would force a constant velocity value being used by the
> > sampler, as provided by the attached hack. That way you can forget about all
> > MIDI input issues for now and just concentrate on the actual bug.
> > 
> > Then your playground will be src/engines/common/AbstractVoice.cpp. You find
> > a method there called AbstractVoice::Synthesize(). That's actually the
> > heart of it all. Disable synthesis components there (i.e. EQ, EGs, filter,
> > etc.) until the issue disappears.
> 
> Any finding in the meantime Frank?

Hm...not a lot so far. Let me list:
- I hard-coded the velocity as per your suggestion, but that didn't change anything.
  I believe I can trust my sequencer software to produce stable velocity output :-).

- I disabled a couple of things in AbstraceVoice.cpp as you suggested (I have
  attached a diff against the current version of that file). Again, no change
  yet, this issue still appears.

- I noticed that - when comparing original sample playback against Linuxsampler's
  output - that LinuxSampler "gets it wrong most of the time" and only a minority
  of the events are playing back the sample correctly.
  The original sample has a pretty hard "click" at the beginning (I attached
  again a very close-up view of the first 50 or so frames of that sample as seen
  in Audacity, file "original_sample.png"), and it's this click I wanted to hear 
  reproduced by LinuxSampler. Most of the sounds it produces are a lot softer, 
  though, but I believe I stated that before.

- The only other interesting observation from today was to see what happens if
  I change the jackd buffer size. My standard buffer size here is 128 frames,
  and with that there is roughly one correctly played sample in about 10
  events.
  If I increase the buffer size to 1024 frames, the issue is a lot more rare -
  I have to wait up to a minute to hear one correctly played sample.
  One the other side, reducing the buffer size to 64 frames creates more correct
  playbacks - roughly 1 out of 4.
  Not sure if this brings us closer to the root cause, but still interesting.

- To make sure I am not fooled by some issue with my sound card (M-Audio
  Audiophile 2496), I set up playback of the same file with qtractor and 
  Rui's "drumkv1" LV2 plugin. That one delivers stable "correct" audio data,
  so the problem really appear to stem from LinuxSampler itself.

I'll continue fooling around with AbstraceVoice.cpp :-).

Greetings,
Frank