PsychPortAudio('GetAudioData'...) not returning timestamps

Programming Help
,
1

Hello, I’ve just started using Psychtoolbox last week. I’m having an issue where the call to PsychPortAudio with ‘GetAudioData’ is returning bad data. If I run SimpleVoiceTriggerDemo.m, line 110:

[audiodata offset overflow tCaptureStart]= PsychPortAudio('GetAudioData', pahandle);

…the variables offset, overflow, and tCaptureStart are each returned with a value of zero. The voice triggering aspects of SimpleVoiceTriggerDemo works just fine, but obviously timestamps that are derived from those variables are incorrect. I wasn’t able to find anyone else reporting this issue, but please direct me to another post if this has been discussed.

My setup:
Windows 10
Matlab R2020a
PTB version 3.0.16 - Flavor: Beta
No errors printed to console when running SimpleVoiceTriggerDemo

Thanks.

2

Should work, and does work fine, at least as quickly tested on Linux.
What’s the full output of the script? This is the most up to date beta, right (UpdatePsychtoolbox).

3

I ran UpdatePsychtoolbox again just to be safe. Here’s the output of SimpleVoiceTriggerDemo after updating.

I’ll also add (not sure if relevant) that the PsychPortAudio('GetAudioData', pahandle) call is sending back data in the audiodata variable.

SimpleVoiceTriggerDemo(0.15, 0)
Detected optional PortAudio override driver plugin in Psychtoolbox root folder. Will use that.
PTB-INFO: Using modified PortAudio V19.6.0-devel, revision unknown
PTB-INFO: New audio device 0 with handle 0 opened as PortAudio stream:
PTB-INFO: For 2 channels Capture: Audio subsystem is MME, Audio device name is Microsoft Sound Mapper - Input
PTB-INFO: Real samplerate 44100.000000 Hz. Input latency 2.902494 msecs, Output latency 0.000000 msecs.

PART I - Simple “offline” response collection at end of trial.
Each trials response period lasts 5 seconds…

Make noise! Make noise! —> Reaction time is -1051511415.481341 milliseconds.
Make noise! Make noise! —> Reaction time is -1051518898.632061 milliseconds.
Make noise! Make noise! No response at all within 5 seconds?!?

Make noise! Make noise! —> Reaction time is -1051533381.383749 milliseconds.
Make noise! Make noise! —> Reaction time is -1051540799.552281 milliseconds.

PART II - The saga continues… This time with a polling method.

Make noise! Make noise! —> Reaction time is -1051546967.844631 milliseconds.
Make noise! Make noise! —> Reaction time is -1051542079.171300 milliseconds.
Make noise! Make noise! —> Reaction time is -1051563979.447508 milliseconds.
Make noise! Make noise! —> Reaction time is -1051566865.716488 milliseconds.
Make noise! Make noise! —> Reaction time is -1051569213.782820 milliseconds.
Make noise! Make noise! —> Reaction time is -1051570239.381057 milliseconds.
Make noise! Make noise! —> Reaction time is -1051575574.913289 milliseconds.
Make noise! Make noise! —> Reaction time is -1051576225.994796 milliseconds.
Make noise! Make noise! —> Reaction time is -1051581779.312630 milliseconds.
Make noise! Make noise! —> Reaction time is -1051584477.295289 milliseconds.
Demo finished, bye!

4

Try it this way: SimpleVoiceTriggerDemo(0.15) instead of specifying/enforcing sound device 0, which seems to be the MME variant of your soundcard. MME does not provide timing/timestamping, only if it says WASAPI as sound system.

And this:

" Detected optional PortAudio override driver plugin in Psychtoolbox root folder. Will use that." suggests you have a possibly unneeded portaudio_x64.dll in the Psychtoolbox folder, which you could move away or delete?

-mario

5

I removed the explicit device ID as you recommended, and it works! Here’s the info that’s printed out by SimpleVoiceTriggerDemo() now:

SimpleVoiceTriggerDemo(0.15)

PTB-INFO: Using modified PortAudio V19.6.0-devel, revision unknown
PTB-INFO: New audio device -1 with handle 0 opened as PortAudio stream:
PTB-INFO: For 2 channels Capture: Audio subsystem is Windows WASAPI, Audio device name is Microphone (Yeti Stereo Microphone)
PTB-INFO: Real samplerate 48000.000000 Hz. Input latency 30.000000 msecs, Output latency 0.000000 msecs.

I also removed the .dll file as you mentioned. I think I saw some demo comment referencing it and thought it was better for some reason? Don’t quite remember – doesn’t matter much. Thanks for the tip.

Is there a way (in Matlab or otherwise) to find what IDs are associated with what audio devices? Some googling led me to audiodevinfo, but it seems that’s only returning me the IDs for MME devices when I do the call audiodevinfo and look at what’s in ans.input.ID

I have a second, related issue. The timestamps in BasicSoundOutputDemo() are not working, it seems due to using the MME devices. When I run it with no input parameters, below is what’s written to the command window.

PTB-INFO: Multi-display setup in explicit multi-display mode detected. Using the following mapping:
PTB-INFO: Screen 0 corresponds to the full Windows desktop area. Useful for stereo presentations in stereomode=4 …
PTB-INFO: Screen 1 corresponds to the display area of the monitor with the Windows-internal name \.\DISPLAY1 …
PTB-INFO: Screen 2 corresponds to the display area of the monitor with the Windows-internal name \.\DISPLAY2 …

PTB-INFO: Your version of Matlab 64-Bit is global system DPI aware. On Windows-8 or later, fullscreen onscreen windows will only work
PTB-INFO: properly timing-wise when displayed on displays with the same pixel density as your systems primary display monitor.
PTB-INFO: For your multi-display setup the stimulus display monitor must have a DPI of (96, 96), matching that of
PTB-INFO: your primary display monitor. Ideally you will only display on the primary display in the first place.
PTB-INFO: Displaying on anything with a different DPI will cause mysterious visual timing problems, sync failures etc.
PTB-INFO: Read ‘help RetinaDisplay’ for more info on this topic.
PTB-INFO: Using modified PortAudio V19.6.0-devel, revision unknown
PTB-INFO: New audio device -1 with handle 0 opened as PortAudio stream:
PTB-INFO: For 2 channels Playback: Audio subsystem is MME, Audio device name is Logitech Speakers (High Definit
PTB-INFO: Real samplerate 48000.000000 Hz. Input latency 0.000000 msecs, Output latency 182.000000 msecs.
Audio playback started, press any key for about 1 second to quit.

Audio playback started, press any key for about 1 second to quit.
This is some status output of PsychPortAudio:
Active: 1
State: 2
RequestedStartTime: 0
StartTime: 0
CaptureStartTime: 0
RequestedStopTime: 1.7977e+308
EstimatedStopTime: 0
CurrentStreamTime: 1.0679e+06
ElapsedOutSamples: 58656
PositionSecs: 1.2220
RecordedSecs: 0
ReadSecs: 0
SchedulePosition: 0
XRuns: 0
TotalCalls: 47
TimeFailed: 8
BufferSize: 1248
CPULoad: 0.0013
PredictedLatency: -1.0679e+06
LatencyBias: 0
SampleRate: 48000
OutDeviceIndex: 7
InDeviceIndex: -1
Measured average samplerate Hz: 0.054924
Delta between audio hw clock and host clock: -1067944033.476817 msecs. Ratio 0.000001.

I don’t know the implications of this, but I’ve just discovered that if I change the PsychPortAudio(‘Open’…) call in BasicSoundOutputDemo to use low-latency mode, it uses the WASAPI device instead, and the timestamps work properly. (Specifically, I changed the 4th input argument from 0 to 2). Is there any harm in using low-latency mode all the time?

pahandle = PsychPortAudio('Open', device, [], 2, freq, nrchannels);

So in sum (long post, sorry):

  1. How can I properly find and refer to WASAPI devices?
  2. Is there harm in using low-latency mode for audio-only PsychPortAudio calls?
6

dev = PsychPortAudio('GetDevices') gives you a list of all devices, see the help text of PsychPortAudio GetDevices? for how to only show the ones corresponding to a specific audio backend like WASAPI.

On modern systems, always using low-latency mode - which also enables high timing precision and timestamping - is not harmful. That’s why by default, low-latency mode 1 is used if the parameter is omitted. This will normally also select the proper audio output / input device if device is omitted. At least for setups without too many outputs/inputs/sound cards where an automatic selection is easy. BasicSoundOutputDemo.m explicitly shows high latency/no timing precision mode, by selecting mode 0.

7

Thanks so much, Mario. On my PC there’s a lot of i/o devices, so explicitly calling the device ID will be handy. I’ll keep that info about low-latency mode in mind as well.