Discussion:
[Linuxsampler-devel] Identical MIDI events cause sound variations?
Frank Neumann
2017-01-09 22:32:01 UTC
Permalink
Hi list,

I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
found a little oddity (two, actually): I have loaded a .sfz with a couple of
synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31)
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64 (output
device from LinuxSampler is JACK).

Though the events are identical with regard to velocity etc, I can clearly
hear that the samples produced by LinuxSampler are varying slight every now and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.

This is the corresponding line from the .sfz mapping this kick drum:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616 pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997 ampeg_release=200.199997 pitchlfo_freq=5.000919

That original .wav file is also attached.

I grabbed a short recording via jack_capture and looked at the resulting .wav
in a wave editor; here I clearly see why the sounds really sound different
(see attached pictures: orig_wave.png is the original .wav file, "soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there any
AMP envelope applied to every sample at playback?) and "hard_wave.png" is one
of the (more rare) sample playbacks with stronger reproduction of the original
sample's attack phase.

So, there are really two questions in this:
- Why is the playback not giving constantly the same audio output? Could this
actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each and
every sample playback (perhaps to avoid the "onset clicks"?), how can I disable
it to be sure my original sample's playback is authentically reproduced?

Thanks,
Frank
Alby M.
2017-01-10 04:49:40 UTC
Permalink
Hi Frank,

Is that the whole SFZ file? I can see two possible causes in that snippet,
but there could be others if the file has other sections. The snippet sets
a rate for an LFO controlling pitch; while the depth of that modulation
should be zero, it's possible that it defaults to something else and that
that processing is responsible for the differences you hear. Another
possibility is that the amplitude envelope has a non-zero attack time. That
can be fixed by adding `ampeg_attack=0`.

Are all your input notes the same velocity?

Do you get the same results using this?:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616

Best,
A.

On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <***@web.de> wrote:


Hi list,

I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
found a little oddity (two, actually): I have loaded a .sfz with a couple of
synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31)
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
(output
device from LinuxSampler is JACK).

Though the events are identical with regard to velocity etc, I can clearly
hear that the samples produced by LinuxSampler are varying slight every now
and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick
drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.

This is the corresponding line from the .sfz mapping this kick drum:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919

That original .wav file is also attached.

I grabbed a short recording via jack_capture and looked at the resulting
.wav
in a wave editor; here I clearly see why the sounds really sound different
(see attached pictures: orig_wave.png is the original .wav file,
"soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there any
AMP envelope applied to every sample at playback?) and "hard_wave.png" is
one
of the (more rare) sample playbacks with stronger reproduction of the
original
sample's attack phase.

So, there are really two questions in this:
- Why is the playback not giving constantly the same audio output? Could
this
actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each and
every sample playback (perhaps to avoid the "onset clicks"?), how can I
disable
it to be sure my original sample's playback is authentically reproduced?

Thanks,
Frank
Frank Neumann
2017-01-10 18:20:44 UTC
Permalink
Hi Alby,

thanks for your suggestions.
Post by Alby M.
Is that the whole SFZ file? I can see two possible causes in that snippet,
The file is really a bit longer, but it contains just key assignments for 17
more samples, on different keys. No LFO definitions or some such, if you were
thinking of that. I now trimmed it down to really just that one line, same
results.
Post by Alby M.
but there could be others if the file has other sections. The snippet sets
a rate for an LFO controlling pitch; while the depth of that modulation
should be zero, it's possible that it defaults to something else and that
that processing is responsible for the differences you hear. Another
possibility is that the amplitude envelope has a non-zero attack time. That
can be fixed by adding `ampeg_attack=0`.
I tried adding ampeg_attack=0 to that line in the .sfz, no effect.
Post by Alby M.
Are all your input notes the same velocity?
Yes; I was trusting my sequencer software, but now I also checked with
aseqdump. It's constant velocity across all events, in this case 64.
Post by Alby M.
<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
Compared to my original .sfz file entry, you are also removing the
"pitch_keycenter" variable which of course affects the sample playback
(I assume it's now played back 3 octaves deeper), but I guess you didn't
really want me to test that. I removed all other statements from that
.sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
still no difference.

Greetings,
Frank
Post by Alby M.
Hi list,
I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
found a little oddity (two, actually): I have loaded a .sfz with a couple of
synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31)
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64 (output
device from LinuxSampler is JACK).
Though the events are identical with regard to velocity etc, I can clearly
hear that the samples produced by LinuxSampler are varying slight every now and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.
<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919
That original .wav file is also attached.
I grabbed a short recording via jack_capture and looked at the resulting .wav
in a wave editor; here I clearly see why the sounds really sound different
(see attached pictures: orig_wave.png is the original .wav file, "soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there any
AMP envelope applied to every sample at playback?) and "hard_wave.png" is one
of the (more rare) sample playbacks with stronger reproduction of the original
sample's attack phase.
- Why is the playback not giving constantly the same audio output? Could this
actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each and
every sample playback (perhaps to avoid the "onset clicks"?), how can I disable
it to be sure my original sample's playback is authentically reproduced?
Thanks,
Frank
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
Alby M.
2017-01-10 18:46:52 UTC
Permalink
Hi Frank,

That's strange. I'm not one of the LinuxSampler devs, so I can't say if
there's an obvious cause for this in LinuxSampler itself, but those tests
certainly remove any causes I can see in the SFZ file.

Your file doesn't contain any <group>s, <master>s, or <global>s, does it?

- A.
Post by Frank Neumann
Hi Alby,
thanks for your suggestions.
Post by Alby M.
Is that the whole SFZ file? I can see two possible causes in that
snippet,
The file is really a bit longer, but it contains just key assignments for 17
more samples, on different keys. No LFO definitions or some such, if you were
thinking of that. I now trimmed it down to really just that one line, same
results.
Post by Alby M.
but there could be others if the file has other sections. The snippet
sets
Post by Alby M.
a rate for an LFO controlling pitch; while the depth of that modulation
should be zero, it's possible that it defaults to something else and that
that processing is responsible for the differences you hear. Another
possibility is that the amplitude envelope has a non-zero attack time.
That
Post by Alby M.
can be fixed by adding `ampeg_attack=0`.
I tried adding ampeg_attack=0 to that line in the .sfz, no effect.
Post by Alby M.
Are all your input notes the same velocity?
Yes; I was trusting my sequencer software, but now I also checked with
aseqdump. It's constant velocity across all events, in this case 64.
Post by Alby M.
<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
Compared to my original .sfz file entry, you are also removing the
"pitch_keycenter" variable which of course affects the sample playback
(I assume it's now played back 3 octaves deeper), but I guess you didn't
really want me to test that. I removed all other statements from that
.sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
still no difference.
Greetings,
Frank
Post by Alby M.
Hi list,
I was experimenting a bit with Linuxsampler and sequencer64 yesterday,
and
Post by Alby M.
found a little oddity (two, actually): I have loaded a .sfz with a
couple of
Post by Alby M.
synthetic drum samples into LinuxSampler (version LinuxSampler
2.0.0.svn31)
Post by Alby M.
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64 (output
device from LinuxSampler is JACK).
Though the events are identical with regard to velocity etc, I can
clearly
Post by Alby M.
hear that the samples produced by LinuxSampler are varying slight every
now
Post by Alby M.
and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.
<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919
That original .wav file is also attached.
I grabbed a short recording via jack_capture and looked at the resulting .wav
in a wave editor; here I clearly see why the sounds really sound
different
Post by Alby M.
(see attached pictures: orig_wave.png is the original .wav file, "soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there
any
Post by Alby M.
AMP envelope applied to every sample at playback?) and "hard_wave.png" is one
of the (more rare) sample playbacks with stronger reproduction of the original
sample's attack phase.
- Why is the playback not giving constantly the same audio output? Could this
actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each
and
Post by Alby M.
every sample playback (perhaps to avoid the "onset clicks"?), how can I disable
it to be sure my original sample's playback is authentically
reproduced?
Post by Alby M.
Thanks,
Frank
------------------------------------------------------------------------------
Post by Alby M.
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
Frank Neumann
2017-01-11 18:40:49 UTC
Permalink
Hi Alby and all,
Post by Alby M.
That's strange. I'm not one of the LinuxSampler devs, so I can't say if
there's an obvious cause for this in LinuxSampler itself, but those tests
certainly remove any causes I can see in the SFZ file.
Your file doesn't contain any <group>s, <master>s, or <global>s, does it?
No, it's really just straight mappings.

What I am interested in - has anyone been able to reproduce this?

That is: Create a one-liner .sfz from the line I stated below, correct the
path to the .wav I had attached to an earlier mail of this thread, start up
Linuxsampler and arm a track with this .sfz, feed a constant (looped)
sequence of, say, quarter notes to it (10 beats should be enough), record
the audio output with e.g. jack_capture and inspect the .wav file in a wave
editor. The difference in the onset of the notes should become apparent pretty
soon as you zoom into the individual beats.

I want to make sure it's not me doing something stupid here - that has
happened before :-).

Thanks,
Frank
Post by Alby M.
Post by Frank Neumann
Hi Alby,
thanks for your suggestions.
Post by Alby M.
Is that the whole SFZ file? I can see two possible causes in that
snippet,
The file is really a bit longer, but it contains just key assignments for 17
more samples, on different keys. No LFO definitions or some such, if you were
thinking of that. I now trimmed it down to really just that one line, same
results.
Post by Alby M.
but there could be others if the file has other sections. The snippet
sets
Post by Alby M.
a rate for an LFO controlling pitch; while the depth of that modulation
should be zero, it's possible that it defaults to something else and that
that processing is responsible for the differences you hear. Another
possibility is that the amplitude envelope has a non-zero attack time.
That
Post by Alby M.
can be fixed by adding `ampeg_attack=0`.
I tried adding ampeg_attack=0 to that line in the .sfz, no effect.
Post by Alby M.
Are all your input notes the same velocity?
Yes; I was trusting my sequencer software, but now I also checked with
aseqdump. It's constant velocity across all events, in this case 64.
Post by Alby M.
<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
Compared to my original .sfz file entry, you are also removing the
"pitch_keycenter" variable which of course affects the sample playback
(I assume it's now played back 3 octaves deeper), but I guess you didn't
really want me to test that. I removed all other statements from that
.sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
still no difference.
Greetings,
Frank
Post by Alby M.
Hi list,
I was experimenting a bit with Linuxsampler and sequencer64 yesterday,
and
Post by Alby M.
found a little oddity (two, actually): I have loaded a .sfz with a
couple of
Post by Alby M.
synthetic drum samples into LinuxSampler (version LinuxSampler
2.0.0.svn31)
Post by Alby M.
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64 (output
device from LinuxSampler is JACK).
Though the events are identical with regard to velocity etc, I can
clearly
Post by Alby M.
hear that the samples produced by LinuxSampler are varying slight every
now
Post by Alby M.
and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.
<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919
That original .wav file is also attached.
I grabbed a short recording via jack_capture and looked at the resulting .wav
in a wave editor; here I clearly see why the sounds really sound
different
Post by Alby M.
(see attached pictures: orig_wave.png is the original .wav file, "soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there
any
Post by Alby M.
AMP envelope applied to every sample at playback?) and "hard_wave.png" is one
of the (more rare) sample playbacks with stronger reproduction of the original
sample's attack phase.
- Why is the playback not giving constantly the same audio output? Could this
actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each
and
Post by Alby M.
every sample playback (perhaps to avoid the "onset clicks"?), how can I disable
it to be sure my original sample's playback is authentically
reproduced?
Post by Alby M.
Thanks,
Frank
------------------------------------------------------------------------------
Post by Alby M.
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
Christian Schoenebeck
2017-01-11 14:08:58 UTC
Permalink
Post by Frank Neumann
- Why is the playback not giving constantly the same audio output? Could
this actually be a bug?
Yes, it seems to be a bug in the SFZ engine.
Post by Frank Neumann
- If there is some kind of AMP envelope automatically applied upon each and
every sample playback (perhaps to avoid the "onset clicks"?), how can I
disable it to be sure my original sample's playback is authentically
reproduced?
It needs to be debugged, for example by commenting out various synthesis
components to narrow down the source of this issue.

CU
Christian
Frank Neumann
2017-01-11 18:42:56 UTC
Permalink
Hi Christian,
Post by Christian Schoenebeck
Post by Frank Neumann
- Why is the playback not giving constantly the same audio output? Could
this actually be a bug?
Yes, it seems to be a bug in the SFZ engine.
Post by Frank Neumann
- If there is some kind of AMP envelope automatically applied upon each and
every sample playback (perhaps to avoid the "onset clicks"?), how can I
disable it to be sure my original sample's playback is authentically
reproduced?
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.

Thanks,
Frank
Alby M.
2017-01-11 19:00:48 UTC
Permalink
Hi all,

I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler 2.0.0
(built from source). Using the attached SFZ file I get no audible or
visible differences. I've attached an image of three hits from the
recording.

Frank, could you be using a different version of LinuxSampler?

- A
Post by Frank Neumann
Hi Christian,
Post by Christian Schoenebeck
Post by Frank Neumann
- Why is the playback not giving constantly the same audio output?
Could
Post by Christian Schoenebeck
Post by Frank Neumann
this actually be a bug?
Yes, it seems to be a bug in the SFZ engine.
Post by Frank Neumann
- If there is some kind of AMP envelope automatically applied upon
each and
Post by Christian Schoenebeck
Post by Frank Neumann
every sample playback (perhaps to avoid the "onset clicks"?), how
can I
Post by Christian Schoenebeck
Post by Frank Neumann
disable it to be sure my original sample's playback is authentically
reproduced?
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.
Thanks,
Frank
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
Frank Neumann
2017-01-11 19:49:35 UTC
Permalink
Hi Alby,
Post by Alby M.
I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler 2.0.0
(built from source). Using the attached SFZ file I get no audible or
visible differences. I've attached an image of three hits from the
recording.
Hm..interesting. Could you zoom in onto the onset (roughly the first 50ms) of
each beat? The "big picture" doesn't really show the effect I am seeing, you
have to look a lot closer.
Post by Alby M.
Frank, could you be using a different version of LinuxSampler?
Mine says 2.0.0.svn31; I don't know how to retrieve the Subversion version
from the binary, though.

Greetings,
Frank
Post by Alby M.
Post by Frank Neumann
Hi Christian,
Post by Christian Schoenebeck
Post by Frank Neumann
- Why is the playback not giving constantly the same audio output?
Could
Post by Christian Schoenebeck
Post by Frank Neumann
this actually be a bug?
Yes, it seems to be a bug in the SFZ engine.
Post by Frank Neumann
- If there is some kind of AMP envelope automatically applied upon
each and
Post by Christian Schoenebeck
Post by Frank Neumann
every sample playback (perhaps to avoid the "onset clicks"?), how
can I
Post by Christian Schoenebeck
Post by Frank Neumann
disable it to be sure my original sample's playback is authentically
reproduced?
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.
Thanks,
Frank
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
Alby M.
2017-01-11 19:56:10 UTC
Permalink
Hi Frank,

I've attached zoomed-in images of the transients of the first and fifth
hits. I still don't see any difference.

- A
Post by Frank Neumann
Hi Alby,
Post by Alby M.
I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler
2.0.0
Post by Alby M.
(built from source). Using the attached SFZ file I get no audible or
visible differences. I've attached an image of three hits from the
recording.
Hm..interesting. Could you zoom in onto the onset (roughly the first 50ms) of
each beat? The "big picture" doesn't really show the effect I am seeing, you
have to look a lot closer.
Post by Alby M.
Frank, could you be using a different version of LinuxSampler?
Mine says 2.0.0.svn31; I don't know how to retrieve the Subversion version
from the binary, though.
Greetings,
Frank
Post by Alby M.
Post by Frank Neumann
Hi Christian,
Post by Christian Schoenebeck
Post by Frank Neumann
- Why is the playback not giving constantly the same audio output?
Could
Post by Christian Schoenebeck
Post by Frank Neumann
this actually be a bug?
Yes, it seems to be a bug in the SFZ engine.
Post by Frank Neumann
- If there is some kind of AMP envelope automatically applied upon
each and
Post by Christian Schoenebeck
Post by Frank Neumann
every sample playback (perhaps to avoid the "onset clicks"?), how
can I
Post by Christian Schoenebeck
Post by Frank Neumann
disable it to be sure my original sample's playback is
authentically
Post by Alby M.
Post by Frank Neumann
Post by Christian Schoenebeck
Post by Frank Neumann
reproduced?
It needs to be debugged, for example by commenting out various
synthesis
Post by Alby M.
Post by Frank Neumann
Post by Christian Schoenebeck
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
Post by Alby M.
Post by Frank Neumann
comment/disable them.
Thanks,
Frank
------------------------------------------------------------------------------
Post by Alby M.
Post by Frank Neumann
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
Christian Schoenebeck
2017-01-11 19:59:10 UTC
Permalink
Post by Frank Neumann
Post by Christian Schoenebeck
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.

CU
Christian
Christian Schoenebeck
2017-01-18 17:12:32 UTC
Permalink
Post by Christian Schoenebeck
Post by Frank Neumann
Post by Christian Schoenebeck
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?

CU
Christian
Frank Neumann
2017-01-19 23:27:08 UTC
Permalink
Hi Christian and all,
Post by Christian Schoenebeck
Post by Christian Schoenebeck
Post by Frank Neumann
Post by Christian Schoenebeck
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
Christian Schoenebeck
2017-01-20 07:55:03 UTC
Permalink
Post by Frank Neumann
- 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.
Good to know.
Post by Frank Neumann
- 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.
No doubt about that. As I said before, it seems to be a bug on LS side.

Since Alby M. said he was unable to reproduce that issue with the official
tarball release LS 2.0.0, maybe you give that version a short try, just to see
if that bug had been accidentally introduced in the meantime:

svn update -r2789

CU
Christian
Frank Neumann
2017-01-21 09:08:23 UTC
Permalink
Hi Christian,
Post by Christian Schoenebeck
Post by Frank Neumann
- 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.
No doubt about that. As I said before, it seems to be a bug on LS side.
Since Alby M. said he was unable to reproduce that issue with the official
tarball release LS 2.0.0, maybe you give that version a short try, just to see
svn update -r2789
I tried that revision, but the issue appears with that one as well for me (original
source code, none of my changes applied).

"I'll be back" when I have news :-).

Greetings,
Frank
Christian Schoenebeck
2017-01-21 12:56:21 UTC
Permalink
Post by Frank Neumann
I tried that revision, but the issue appears with that one as well for me
(original source code, none of my changes applied).
Ok, so the bug existed already before the last tarball release.
Post by Frank Neumann
"I'll be back" when I have news :-).
I probably have some suspicion. Which audio driver are you using? JACK? ALSA?
CoreAudio?

CU
Christian
Frank Neumann
2017-01-21 20:01:35 UTC
Permalink
Hi Christian,
Post by Christian Schoenebeck
Post by Frank Neumann
I tried that revision, but the issue appears with that one as well for me
(original source code, none of my changes applied).
Ok, so the bug existed already before the last tarball release.
Post by Frank Neumann
"I'll be back" when I have news :-).
I probably have some suspicion. Which audio driver are you using? JACK? ALSA?
CoreAudio?
I have conducted all tests so far with the JACK driver; I tested just now with
the ALSA audio driver, but the problem is the same.

I'll next see if an older laptop I have here (running a 32bit LinuxMint
distribution) also shows the issue - maybe I have a 64bit problem.

Greetimgs,
Frank
Frank Neumann
2017-01-22 23:05:26 UTC
Permalink
Hi again,
Post by Frank Neumann
Post by Christian Schoenebeck
Ok, so the bug existed already before the last tarball release.
Post by Frank Neumann
"I'll be back" when I have news :-).
I probably have some suspicion. Which audio driver are you using? JACK? ALSA?
CoreAudio?
I have conducted all tests so far with the JACK driver; I tested just now with
the ALSA audio driver, but the problem is the same.
I'll next see if an older laptop I have here (running a 32bit LinuxMint
distribution) also shows the issue - maybe I have a 64bit problem.
That test again showed no difference from the behaviour on a 64-Bit LinuxMint
system (my regular desktop PC).

However - finally *some* good news for the weekend :-). When I disable the
whole CONFIG_INTERPOLATE_VOLUME block in AbstractVoice.cpp (I simply replaced
line 231,

#ifdef CONFIG_INTERPOLATE_VOLUME

with

#if 0
)

THEN, the issue is gone and the kick sound comes through correctly each time
(listened for some 2 minutes now).

Furthermore, if I reduce the "if(pSignalUnitRack...)" code in there a little,
the issue also remains gone:

242c242,244
< finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
---
Post by Frank Neumann
finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
// finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
244c246,248
< finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
---
Post by Frank Neumann
finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
// finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
So then, it's somewhere in the pEG1 or pSignalUnitRack handling. A small step ahead :-).

Greetings,
Frank
Frank Neumann
2017-01-22 23:32:40 UTC
Permalink
Hi once more,
Post by Frank Neumann
However - finally *some* good news for the weekend :-). When I disable the
whole CONFIG_INTERPOLATE_VOLUME block in AbstractVoice.cpp (I simply replaced
line 231,
#ifdef CONFIG_INTERPOLATE_VOLUME
with
#if 0
)
THEN, the issue is gone and the kick sound comes through correctly each time
(listened for some 2 minutes now).
Furthermore, if I reduce the "if(pSignalUnitRack...)" code in there a little,
242c242,244
< finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
---
Post by Frank Neumann
finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
// finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
244c246,248
< finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
---
Post by Frank Neumann
finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
// finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
So then, it's somewhere in the pEG1 or pSignalUnitRack handling. A small step ahead :-).
Just summarizing, for clarity sake: With these 2 changes applied, the issue
is gone (of course this is not a fix yet):

--- src/engines/common/AbstractVoice.cpp.orig 2017-01-15 13:08:46.174155350 +0100
+++ src/engines/common/AbstractVoice.cpp 2017-01-23 00:31:28.283565968 +0100
@@ -241,7 +241,8 @@
if (pSignalUnitRack == NULL) {
finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
} else {
- finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
+ finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
+// finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
}

finalSynthesisParameters.fFinalVolumeLeft = finalVolume * VolumeLeft * PanLeftSmoother.render();
@@ -526,9 +527,9 @@
}*/
// TODO: ^^^

- fFinalVolume *= pSignalUnitRack->GetEndpointUnit()->GetVolume();
- fFinalCutoff = pSignalUnitRack->GetEndpointUnit()->CalculateFilterCutoff(fFinalCutoff);
- fFinalResonance = pSignalUnitRack->GetEndpointUnit()->CalculateResonance(fFinalResonance);
+// fFinalVolume *= pSignalUnitRack->GetEndpointUnit()->GetVolume();
+// fFinalCutoff = pSignalUnitRack->GetEndpointUnit()->CalculateFilterCutoff(fFinalCutoff);
+// fFinalResonance = pSignalUnitRack->GetEndpointUnit()->CalculateResonance(fFinalResonance);

finalSynthesisParameters.fFinalPitch =
pSignalUnitRack->GetEndpointUnit()->CalculatePitch(finalSynthesisParameters.fFinalPitch);

Greetings,
Frank
Christian Schoenebeck
2017-01-23 16:04:34 UTC
Permalink
Post by Frank Neumann
Just summarizing, for clarity sake: With these 2 changes applied, the issue
@Grigor, @Andreas: are you still around on this list? Maybe you can comment as
well, because I am not very familiar with the SignalUnitRack stuff of the SFZ
engine.

I had a look at this issue described by Frank. It is a bug in the
SignalUnitRack handling. In very short, the following would fix the issue
Frank encountered with his SFZ file:


Index: src/engines/common/SignalUnit.cpp
===================================================================
--- src/engines/common/SignalUnit.cpp (revision 3099)
+++ src/engines/common/SignalUnit.cpp (working copy)
@@ -25,6 +25,6 @@

namespace LinuxSampler {
bool SignalUnit::DelayStage() {
- return (DelayTrigger() >= pRack->GetCurrentStep());
+ return (DelayTrigger() > pRack->GetCurrentStep());
}
} // namespace LinuxSampler


But, and there is a big "but", that short patch would just cure the symptom in
Frank's particular case, as far as I can see it, the bug would still be
triggered in other scenarios (more complex SFZ files) though. So here is a
more detailed description about this issue:

The SFZ engine is calling:

pSignalUnitRack->GetEndpointUnit()->GetVolume()

inside of method AbstractVoice::Synthesize() to get the current volume factor
to be applied for the voice in the current audio (sub)fragment. Since Frank's
sfz file is very simple (no volume modulators), that GetVolume() call would
always return 1.0f (neutral volume factor), except of one case: at the very
beginning of the life time of each voice (that is when pVoice->Pos == 0.0)
that GetVolume() call returns 0.0f instead. And that is wrong.

GetVolume() does return 0.0f at the very beginning of a voice's life time,
because EndPointUnit::GetVolume() calls
suVolEG.GetLevel() [SfzSignalUnitRack.cpp, line 617], which is implemented
like this [SfzSignalUnitRack.h, line 165]:

virtual float GetLevel() { return DelayStage() ? 0 : EG.getLevel(); }

Now in Frank's case, it is simply a bug to assume that it would be in a delay
stage at the beginning of the voice's life time and the short patch above
would fix it. But apart from Frank's case, simply returning 0 here looks odd
to me.

As I said, I am not familiar with the SignalUnitRack code base, but
intuitively I would rather expect the GetLevel() implementation either

a) to always return EG.getLevel() (even in delay stage) or

b) to return an "identity element" in delay stage instead, which depends on
whether that result is going to be used in a mathematical add operation (in
which case the identity element is 0) or rather in a mathematical multiply
operation (in which case the identity element is 1).

Thoughts? Am I missing something?

CU
Christian
Christian Schoenebeck
2017-02-04 17:56:53 UTC
Permalink
Post by Christian Schoenebeck
Index: src/engines/common/SignalUnit.cpp
===================================================================
--- src/engines/common/SignalUnit.cpp (revision 3099)
+++ src/engines/common/SignalUnit.cpp (working copy)
@@ -25,6 +25,6 @@
namespace LinuxSampler {
bool SignalUnit::DelayStage() {
- return (DelayTrigger() >= pRack->GetCurrentStep());
+ return (DelayTrigger() > pRack->GetCurrentStep());
}
} // namespace LinuxSampler
Frank, I just committed this little patch to SVN which should fix this issue
for you.

I got no response from Grigor or Andreas about this issue, so I will probably
address the other potential cases (where this misbehavior might occur as well)
of the SFZ format in some way in the next couple days. Requires a bunch of
changes in the SFZ engine.

CU
Christian
Frank Neumann
2017-02-05 10:29:04 UTC
Permalink
Hi Christian and all,
Post by Christian Schoenebeck
Post by Christian Schoenebeck
Index: src/engines/common/SignalUnit.cpp
===================================================================
--- src/engines/common/SignalUnit.cpp (revision 3099)
+++ src/engines/common/SignalUnit.cpp (working copy)
@@ -25,6 +25,6 @@
namespace LinuxSampler {
bool SignalUnit::DelayStage() {
- return (DelayTrigger() >= pRack->GetCurrentStep());
+ return (DelayTrigger() > pRack->GetCurrentStep());
}
} // namespace LinuxSampler
Frank, I just committed this little patch to SVN which should fix this issue
for you.
Confirmed! Tried it just now, clean playback of that kick drum sample for
several minutes now. I'm happy, thank you so much! :-)
Post by Christian Schoenebeck
I got no response from Grigor or Andreas about this issue, so I will probably
address the other potential cases (where this misbehavior might occur as well)
of the SFZ format in some way in the next couple days. Requires a bunch of
changes in the SFZ engine.
Thanks, very much appreciated. I have not noticed any other places with
similar issues, but then again my test scenario (including the .sfz files
themselves) was very limited and simple until now.

Greetings,
Frank
Christian Schoenebeck
2017-02-05 13:58:00 UTC
Permalink
Post by Frank Neumann
Post by Christian Schoenebeck
Frank, I just committed this little patch to SVN which should fix this
issue for you.
Confirmed! Tried it just now, clean playback of that kick drum sample for
several minutes now. I'm happy, thank you so much! :-)
No problem!
Post by Frank Neumann
Post by Christian Schoenebeck
I got no response from Grigor or Andreas about this issue, so I will
probably address the other potential cases (where this misbehavior might
occur as well) of the SFZ format in some way in the next couple days.
Requires a bunch of changes in the SFZ engine.
Thanks, very much appreciated. I have not noticed any other places with
similar issues, but then again my test scenario (including the .sfz files
themselves) was very limited and simple until now.
Right, it works for you now because your sfz files seem to be very simple. The
other cases where one can still encounter this issue, occur when defining some
modulators in the sfz file which shall become active with a delay after a
certain amount of time. But I'm on those issues as well, so they should be
fixed soon.

CU
Christian

Loading...