Open ningma97 opened 8 years ago
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.
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 https://github.com/TWOEARS/blackboard-system/issues/16#issuecomment-192265093 .
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)
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 https://github.com/TWOEARS/blackboard-system/issues/16#issuecomment-192292929 .
Neither sim.Init
nor sim.ReInit
do 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.
What is the command we should execute if we want to reset the buffer to the first sample?
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.
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.
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.
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.
block_testing
branch in bothblackboard-system
andexamples
reposlocalisation_GMMs
folderlocalise_run1
,localise_run2
, andlocalise_run3
one by onelocalise_run1
will plot 2 blocks of signals with stimulation length of 1 second and a single localisation run (Figure 1)localise_run2
is same aslocalise_run1
but has an additional localisation run beforelocalise_run1
(Figure 2)localise_run3
is same aslocalise_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.