Trouble playing sequence of tones

Hi everyone,

I have a task where a sequence of tones is played consecutively in a specific order (see Oddball.m). It was working properly before I had to upgrade to W10, update the MATLAB version and upgraded ML_2.

What happens now is that only the very first tone is played when it corresponds. Then, a second one is played after aprox. 4 seconds

The sequence itself is running correctly because the eventcodes are sent. I tried all combinations of toggleobject ON-OFF, and does not seem to be the problem. I also have an idle time between tones that separated them.

Other tones in other tasks, separated in time, are played properly.

My guess is that there is some kind of trouble at hardware/driver level? I didn't change it along upgrades.
Has anyone ever struggle with sound playback? I would deeply appreciate your help in this regard.

Thanks in advance,

Jesus

Rewind the used sounds before turning them on again.
https://monkeylogic.nimh.nih.gov/docs_RuntimeFunctions.html#rewind_object

Sounds used to be rewound automatically when turned off, but they don't anymore. It is because now very long sounds can be streamed from files and rewinding them may take long while not everybody needs it.

Hi Jaewon,

That fixed it. I completely missed this change in how sounds and movies are used.

Thank you for your help and all your work around here!

Jesus

I have a little concern about the timing of your stimuli though.

You used idle() to leave short intervals between the tones, but idle() is not that accurate timingwise because it has to redraw the control screen from time to time during the wait. So, if the tones should be precisely at 150-ms intervals, I would use a userloop function, create a long wav sound there, in which 5 tones are combined, and play one long wav instead of repeating a short one 5 times.

I know you eventmark the timing of each tone, so, if it is good enough for you, that is fine. However, you should know that there is a ~40-ms delay between a sound and its eventmarker, when the sound is played through the sound card of Windows, as I wrote in my NIMH ML paper.

Thank you for pointing this out,

I will definitely double check our timing needs. Luckily, we have not used it in any experiment yet.

I very much appreciate your advise regarding the userloop solution and will give it a try anyways to compare performances.

Again, many thanks,

Hi Jaewon,

I've gone over the time-stamping and now I'm not sure if either I did not get correctly the concern about the sound-eventmarker delay, or if such delay does not happen in my specific conditions.

I ran the task (attached again) and measured the average time interval between tones in two ways:
- between consecutives eventmarkers sent at the time of playing the sound (events 31-35). Average = 154.1 ms
- same but with eventmarkers sent just before playing the tone (events 59). Average = 154.5 ms

I realized that the first measure wasn't real, because I would be measuring just the time between eventmarkers, no matter when the tone was actually being played. But the second measure should give me the real time between the start of tones, right? Perhaps this is what I am not getting right?

I have to say, I measured the timestamps as received by the acquisition system machine.

Please, let me know what I am missing if anything!

Thank you,

EDIT: (11/14)
I just realized that the delay may happen between the time when the tone actually starts and the eventmarker reaching the external machine.

So, if I eventmark just before the toggleobject and I measure the delay between those, that's the time when the tone necessarily needs to be played? If that is true, the time between those, in my case, is just 1.2 ms. I attach a couple files with the timestamps I obtained.

Or is the eventmarker in toggleobject sent before the object is turned on?

Thank you again.

What I meant was that the time when a sound comes out of the speaker is ~40 ms later than the time recorded by the eventmarker of toggleobject. It is because sounds have to go through the Windows audio stack when they are played via the sound card. The time that eventmarkers take to reach an external machine is just ~0.2 ms, so it can be ignored.

  % This loop plays 4 times the BASAL tone
  for j = 1:4                           
    tone = 30+j;                                % events for 1st (31) to forth (34) tones
    eventmarker(59);                            % Just time-check
    toggleobject(Basal, 'eventmarker', tone, 'status', 'on');
      if Basal == 1, eventmarker(36),           % Basal tone was an A
      else, eventmarker(37), end                % or B
    idle(146);                                  % Inter-tone interval
    toggleobject(Basal,'status', 'off'); % 'eventmarker', tone, 
    rewind_sound(Basal);
  end

In your code, eventcodes that may be meaningful to you are 31-35. They are the closest estimates of the onset time of the tones, in spite of the delay. You can assume that the first tone started ~40 ms after event 31, for example.

Event 59 is unnecessary. Events 36 and 37 are at least indicating whether the basal tone was A or B, but 59 does not have any information here.

Everything is absolutely clear now. And I get why a pre-recorded sequence vs separated tones will help.

Thank you!

You can use analogoutput of DAQ boards, if you need zero-latency sounds, but then you cannot mix multiple tones on the fly and may need an amplifier.

That's an interesting idea, actually.

We might have the hardware to try that but, why could I not mix tones? Couldn't I program two different STM objects through two different analog outputs, and shoot one or the other?

That is actually a well-known technique to avoid the Windows audio stack and accomplish zero latency.

It is the mixer in the Windows audio stack that combines individual sounds and plays them through one common output channel (speaker, headphone, etc.). DAQ devices do not have a mixer, so you cannot combine two sounds by playing one while the other is being played and should mix them yourself (i.e., multiplying MATLAB matrices each other) before sending them to DAQ devices.

If you have only one DAQ device, it is not possible to choose which tone to send out on the fly, even if you have two analog output channels and can create two STM objects. Analog outputs on the same device cannot be controlled independently. You can only play them together at the same time.

Loading a chosen waveform on the fly is not an option, either. To achieve zero latency, DAQ devices require to load waveforms into a memory buffer before generating them. Loading a new waveform on the fly or reloading another waveform when one is already loaded takes a significant amount of time and cannot guarantee zero latency.

I appreciate all the explanations. Hopefully, I can come back to them if we decide that zero-lag is critical for other auditory related tasks.

Right now, the ~40ms delay looks like something we can work around, mostly if we use the userloop alternative which will suffer the delay only once per sequence and not on every tone.

And I must say, I though our DAQ board had 2 AOs but turns out it has none (is a 6220 I inherited). The two AOs I saw in the ML2 list are actually the audiocard outputs.

Thanks Jaewon