Cannot fix large onset delay

[julia campbell]

Hello all,

I have a simple audio experiment set up on E Prime.  It is a gating experiment, with paired tones.
For some reason, when E Prime prints the advisor report, it shows a large onset delay for only the first tone.

The errors listed in the report also don't make sense, as I have used Codec Config and identified the audio player for the experiment.

I have attached the experiment and the advisor report.  I would really appreciate any advice on how to get rid of this delay for the first tone (stm1).

Julia

[Ines Anton-Mendez]

Maybe using ‘prerelease’?

 

    Inés

--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com.
To post to this group, send email to e-p...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/f8feae26-cd75-40b3-8be1-6a18f6f0abfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David McFarlane]

Julia,

Please first work through the "Critical Timing" chapter in the User's
Guide that came with E-Prime.

Aside from the OnsetDelay, note that you will likely have an additional
delay from the onset of the object in E-Prime until the sound actually
starts to play. I have tested this myself with a Black Box Toolkit, and
get latencies anywhere from 7.25 ms to 53.25 ms, depending on the
machine, version of E-Prime, version of Windows, sound API, etc. This
could be critical if you use E-Prime to control the time between tones
-- instead, you should put your paired tones into single sound files.

The new Chronos device from PST promises object-to-sound latencies of
under 1 ms, and I hope to test this myself soon.

---------------
David McFarlane
E-Prime training online:
http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)

[Julia Campbell]

I've used prerelease for all stimuli, and I'm not certain that I want to group both tones in a single sound file as I need to tag both events separately to send to an external EEG amplifier.

I'm just confused as to why only the first tone is showing a consistent delay. I'll look through the critical timing chapter again. Thank you both for your suggestions!

David, I'm curious about the Chronos device--I'll take a look at that as well.

Thank you,
Julia






Best,
Julia Campbell
303.517.0395

> --
> You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/zPbRADktp5k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.

> To post to this group, send email to e-p...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/56E1AC0B.2060504%40msu.edu.

[David McFarlane]

Julia,

Well ... Is the first tone also the first E-Object in the Procedure?
And are you using EP2.0.10.x? Note that, with Generate PreRun set to
the default value of TopOfProcedure, E-Prime will load *all* the stimuli
for the entire Procedure just before running the first E-Object of the
Procedure. You might try setting Generate PreRun to BeforeObject, that
would then spread out the stimulus loading throughout the Procedure.

Also, what is the Duration of the last object in your Procedure? Is it
long enough and does it have enough PreRelease to allow all of your
stimuli to load at the top of the Procedure? And do you have PreRelease
set to "(same as duration)" (the default value for new versions of E-Prime)?

-- David McFarlane

[julia campbell]

Hi all,

I've been working with support to rectify the issue, but they would like for me to use inline coding, which I'm very unfamiliar with.
I'm using EP2.0.10.356.  Generate PreRun is set to inherit (the default) for both tonal stimuli.  I've played around with setting it to beforeobject, but this has no effect on the delay.
All tones have a pre-release of 100 ms or more.  The duration was 50 ms, so I made the pre-release longer.
The duration of the last object is 7000 ms, with pre-release set to duration.

Here's what the setup looks like:
sound object (50 ms)
wait object (500 ms)
sound object (50 ms)
wait object (7000 ms)

only the first sound object has an inconsistent delay: 2-30 ms.
I'm using this to sync with Net Station, an EEG system.

Thanks again.
Julia

[David McFarlane]

Julia,

First, please try the following: Edit your trial Procedure to put a
TextDisplay object in front of the first sound object -- just leave the
TextDisplay blank, or add a fixation cross, whatever (I like to use
something like "[TrialList.Sample]" to show me a count of trials). Set
this TextDisplay to a Duration of 100 ms, with PreRelease of "(same as
duration)". Have it log TargetOnsetTime, OnsetTime, and OnsetDelay.
And log the same things for your first sound object -- TargetOnsetTime,
OnsetTime, and OnsetDelay. Finally, make sure that your sound object
has Onset Sync set to "(none)". Run this and report the results,
especially the OnsetDelay of the first sound object under these conditions.

Second, by "inconsistent delay", do you refer to the OnsetDelay as
reported by E-Prime in the .edat2 file, or to the delay from the onset
of the object in E-Prime to the actual sound output (as measured using
external timing equipment, e.g., oscilloscope or Black Box Toolkit)?

Third, are you trying to sync NetStation to the first sound object? If
so, then how does E-Prime send the trigger to NetStation? If it uses
Task Events or OnsetSignal, then the trigger will still occur at the
same time as the onset of the sound object, regardless of OnsetDelay, so
the OnsetDelay will not matter.

---------------
David McFarlane
E-Prime training online:
http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)

>> <javascript:>>

[julia campbell]

Hi David,

Thank you for your help!

I moved the wait object to the top of the experimental procedure, so it now looks like this:

wait object (7000 ms)

sound object (50 ms)
wait object (500 ms)
sound object (50 ms)

When I logged the OnsetDelay and OnsetTime of each object, it showed that only the first wait object had an onset delay of ~14 ms.  I adjusted the duration of that object to be 6990 ms, and this takes care of the problem.  Now the timing is within 1-2 ms and is consistent.  Before, there would be delays ranging from 10 to 50 ms with a lot of variation.

I was not concerned with the timing on the EEG end of things as I have an AV device to test and correct for jitter offset between EPrime stimuli presentation and EGI marking of stimuli events.  My main concern was having a consistent rate of presentation with minimal delay.  

I’d appreciate your thoughts as to whether this solution is a good one or not.  Thank you again for all of your input!

Julia Campbell, Ph.D, Au.D, CCC-A, F-AAA

Assistant Professor

Communication Sciences and Disorders

The University of Texas at Austin

-- 
You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/zPbRADktp5k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.
To post to this group, send email to e-p...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/5706ADEF.7050803%40msu.edu.

[David McFarlane]

Julia,

This will probably do. The OnsetDelay of ~14 ms that you got sounds
like it is due to synchronizing to the vertical blank of your display --
if you have Onset Sync set to "vertical blank", then your stimulus will
wait for a screen refresh, which could take up to ~16.7 ms on a 60 Hz
display. If you shorten your object duration by another 10 ms, you will
probably see the OnsetDelay increase -- try it and see! Alternatively,
try setting it to 7010 ms, and see if that also decreases the OnsetDelay.

You did not say what version of E-Prime you use. If you made that
experiment with a version prior to 2.0.10, then by default the Onset
Sync of *all* stimuli, including non-visual ones, is set to "vertical
blank". This is a mistake, which got corrected in EP2.0.10. You almost
never want non-visual stimuli to wait for a screen refresh. Generally,
you should manually change the Onset Sync of all non-visual stimuli
(e.g., Wait, SoundOut) to "(none)". (I go over these details in my
online course.)

As I said earlier, you should work through the "Critical Timing" chapter
in the User's Guide that came with E-Prime, which explains some of this.
Well worth the effort.

---------------
David McFarlane
E-Prime training online:
http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)

>> <https://twitter.com/EPrimeMaster>)

>>>>>> <mcfa...@msu.edu <http://msu.edu/>

>>>> <javascript:>>
>>>>>> wrote:
>>>>>>
>>>>>> Julia,
>>>>>>
>>>>>> Please first work through the "Critical Timing" chapter in
>>>>>> the User's Guide that came with E-Prime.
>>>>>>
>>>>>> Aside from the OnsetDelay, note that you will likely have
>>>>>> an additional delay from the onset of the object in E-Prime
>>>>>> until the sound actually starts to play. I have tested
>>>>>> this myself with a Black Box Toolkit, and get latencies
>>>>>> anywhere from 7.25 ms to 53.25 ms, depending on the
>>>>>> machine, version of E-Prime, version of Windows, sound API,
>>>>>> etc. This could be critical if you use E-Prime to control
>>>>>> the time between tones -- instead, you should put your
>>>>>> paired tones into single sound files.
>>>>>>
>>>>>> The new Chronos device from PST promises object-to-sound
>>>>>> latencies of under 1 ms, and I hope to test this myself
>>>>>> soon.
>>>>>>
>>>>>> --------------- David McFarlane E-Prime training online:
>>>>>> http://psychology.msu.edu/Workshops_Courses/eprime.aspx

>>>>>> <http://psychology.msu.edu/Workshops_Courses/eprime.aspx>
>>>>>> Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster

>>>>>> <https://twitter.com/EPrimeMaster>)

[David McFarlane]

Juli,

Hmm, I just realized that you attached your experiment program in your
initial message, I should have just looked at that earlier. You have a
block of InLine code that runs at the end of your trial Procedure. That
inline code explicitly defeats any PreRelease from the last stimulus
object of the Procedure, and that is why the first object of your
Procedure keeps having an extra OnsetDelay. That's all. If you want to
reduce the OnsetDelay of the first object in your Procedure, then you
must do something with your inline code to fix that. The specific fix
would depend on the details of what you want your program to do.

-- David McFarlane

[julia campbell]

Hi David,

Thanks for this input.

I had removed the inline procedure prior to my most recent inquiry, so the delay was present without the Inline.  

I don’t believe I have the sync set to vertical blank (I’ve looked at that but I’ll double-check)—I’m using the latest 2.0 version.

I’ll keep looking at the critical timing chapter as well.

Thanks!

Julia Campbell, Ph.D, Au.D, CCC-A, F-AAA

Assistant Professor

Communication Sciences and Disorders

The University of Texas at Austin

-- 
You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/zPbRADktp5k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.
To post to this group, send email to e-p...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/570BF35D.8010404%40msu.edu.

[David McFarlane]

Julia,

All good. It looks like you do have Onset Sync set to "(none)" on all
your non-visual stimuli -- the latest versions of E-Prime, correctly, do
that for you by default. So all good there. And I see that your
SoundOutput objects use a fixed sound file (instead of using an
attribute reference). That means that they should load the sound file
once at the start of the program, and do not need to load any sound
files during the trial Procedure, which should speed execution.

So with all that, and the elimination of any intervening inline code,
the only thing left to account for your OnsetDelays is the NetStation
PackageCalls, and I really cannot say anything about that. Do you still
have those PackageCall objects in your trial Procedure? What happens to
the timing if you remove those for a separate test version of your program?

-- David McFarlane

[julia campbell]

Hi David,

What a great suggestion—I’ll test without those. I’ll let you know when I do what the result is.

Julia Campbell, Ph.D, Au.D, CCC-A, F-AAA

Assistant Professor

Communication Sciences and Disorders

The University of Texas at Austin

-- 
You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/zPbRADktp5k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.
To post to this group, send email to e-p...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/570D6B8D.3070405%40msu.edu.