Block-based processing in blackboard

[ningma97]

Hi Ivo,

As requested I added a little example to show you what I meant by getting different block signals with multiple localisation runs and various stimulation lengths. Perhaps @hagenw @fietew could also have a look.

1. Checkout the block_testing branch in both blackboard-system and examples repos
2. Go to the localisation_GMMs folder
3. Run localise_run1, localise_run2, and localise_run3 one by one

• localise_run1 will plot 2 blocks of signals with stimulation length of 1 second and a single localisation run (Figure 1)
• localise_run2 is same as localise_run1 but has an additional localisation run before localise_run1 (Figure 2)
• localise_run3 is same as localise_run2 but the stimulation length is 1.1 second (Figure 3)

You will find the 3 figures all look different (slightly shifted), but they should be identical.

[hagenw]

My first guess is that the signals in the binaural simulator gets not reseted by doing a sim.ReInit = true;. I don't know if this is meant as a feature or it is a bug. @fietew ?
Does this behavior is different if you have a ring or a fifo buffer?

If I see it correctly you are using the following wav file as audio material: 'sound_databases/grid_subset/s1/bbaf2n.wav'. If you read this with Matlab and check the size you get the following:

>> sig = audioread('sound_databases/grid_subset/s1/bbaf2n.wav');
>> length(sig)/44100

ans =

    0.6746

>> length(sig)-44100/2

ans =

        7701

As it turns out those 7701 correspond quite well with your additional signal at the beginning of Figure 2.

In order to avoid confusions I would suggest that a reset of the simulator should empty the buffer as default setting. If this is not wanted we could provide a setting that allows to don't clean the buffer.

[ningma97]

Note if you read the signal directly with audio read, the sampling rate is
25 kHz not 44.1 kHz. sim.Sources{1}.AudioBuffer.loadFile() would resample
the signal to 44.1 kHz I think.

On 4 March 2016 at 12:41, Hagen Wierstorf notifications@github.com wrote:

My first guess is that the signals in the binaural simulator gets not
reseted by doing a sim.ReInit = true;. I don't know if this is meant as a
feature or it is a bug. @fietew https://github.com/fietew ?
Does this behavior is different if you have a ring or a fifo buffer?

If I see it correctly you are using the following wav file as audio
material: 'sound_databases/grid_subset/s1/bbaf2n.wav'. If you read this
with Matlab and check the size you get the following:

sig = audioread('sound_databases/grid_subset/s1/bbaf2n.wav');
length(sig)/44100
ans =

0.6746

length(sig)-44100/2
ans =

    7701

As it turns out those 7701 correspond quite well with your additional
signal at the beginning of Figure 2.

In order to avoid confusions I would suggest that a reset of the simulator
should empty the buffer as default setting. If this is not wanted we could
provide a setting that allows to don't clean the buffer.

—
Reply to this email directly or view it on GitHub
#16 (comment)
.

[hagenw]

Yes you are right, but it doesn't change much on my points as I thought the signal length in your figure is 0.5s and not 1s :o)

[ningma97]

Yes the signal (block) length is 0.5s in each panel. The second block is
plotted underneath the first one, giving the total signal length of 1s.

On 4 March 2016 at 13:57, Hagen Wierstorf notifications@github.com wrote:

Yes you are right, but it doesn't change much on my points as I thought
the signal length in your figure is 0.5s and not 1s :o)

—
Reply to this email directly or view it on GitHub
#16 (comment)
.

[fietew]

Neither sim.Init nor sim.ReInitdo manipulate the buffers of the sound source, i.e. resetting them to the first sample or something like this. I will add a note in the documentation http://twoears.aipa.tu-berlin.de/doc/latest/binsim/usage/#simulate-ear-signals before the next release.

[hagenw]

What is the command we should execute if we want to reset the buffer to the first sample?

[fietew]

The ring buffer class has an private Attribute called DataPointer, which specifies the current position in the loop. I could remove the private and then you could call it by sim.Sources{id}.AudioBuffer.DataPointer = [1], while the length of the vector has to match the number of channels of the source, which is in most cases just one channel.

[hagenw]

That sounds way to complicated to me. Something similar to sim.ReInit would be nice, maybe sim.Buffer.ReInit.

You say sim.Init has no influence on the buffer. If I do a sim.ShutDown and then a sim.Init I have still no empty buffers?

In addition, I think for most of our applications it is not a good idea to have the behavior of the buffer separated from the sim.Init, sim.ReInit stuff.

[fietew]

Emptying the buffers with the call of sim.Init will lead to buffers, which are always empty, when you try get a signal, as you specify everything including source signals before the initialisation.