PsychPortAudio: Choosing the audio device/API

1
I have problems choosing a specific audio device/API. When I call PsychPortAudio('Open',...) with a specific device ID, the next 'GetStatus' aborts the script with "Caught MathWorks::System::FatalException".
I observe this on several Windows machines (WinXP/32bit, Win7/64bit with PTB-32bit or 64bit, with older or latest version of PTB).
In the following boiled-down demo script I first retrieve the ID of PsychPortAudio's default device and then re-'Open' this device by explicitly specifying the device ID explicitly. According to the messages in the command window, everything looks fine and exactly the same, whether I let PsychPortAudio choose the device or specify it explicitly. Yet, in the latter case the next 'GetStatus' call fails. The weird thing is that I can play sound using this handle, so apparently it is just the 'GetStatus' call which fails - consistently so for different setups. Any idea what's going on here?
I'm aware that I don't have an ASIO audio card plugged in. So please, don't suggest that I should just get an ASIO card and everything will be fine. 'GetStatus' should work for all devices/API's offered by PsychPortAudio.

------------------------------------------------------------------------
function PortAudioDemo
    commandwindow();
    InitializePsychSound();
    ahandle = PsychPortAudio('Open');
    status = PsychPortAudio('GetStatus', ahandle);
    fprintf('#### Retrieved the default device idx (ahandle=%d): %d\n',ahandle,status.OutDeviceIndex);
    PsychPortAudio('Close',ahandle);
    ahandle = PsychPortAudio('Open',status.OutDeviceIndex);
    fprintf('#### Arriving at the critical call (ahandle=%d) ...\n',ahandle);
    status = PsychPortAudio('GetStatus', ahandle);
    fprintf('#### Passed the critical call!\n');
    PsychPortAudio('Close',ahandle);
end

------------------------------------------------------------------------
According output:

PTB-INFO: Using specially modified PortAudio engine, based on offical version: PortAudio V19-devel WITH-DIM

Will use ASIO enhanced Portaudio driver DLL. See Psychtoolbox/PsychSound/PortAudioLICENSE.txt
for the exact terms of use for this dll.


Disclaimer: "ASIO is a trademark and software of Steinberg Media Technologies GmbH."
PTB-Warning: Although using the ASIO enabled Psychtoolbox sound driver,
PTB-Warning: could not find any ASIO capable soundcard in your system.
PTB-Warning: If you think you should have an ASIO card, please check your
PTB-Warning: system for properly installed and configured drivers and retry.
PTB-Warning: Read "help InitializePsychSound" for more info about ASIO et al.
PTB-INFO: New audio device with handle 0 opened as PortAudio stream:
PTB-INFO: For 2 channels Playback: Audio subsystem is Windows DirectSound, Audio device name is Primary Sound Driver
PTB-INFO: Real samplerate 44100.000000 Hz. Input latency 0.000000 msecs, Output latency 39.977324 msecs.
#### Retrieved the default device idx (ahandle=0): 6
PTB-INFO: Using specially modified PortAudio engine, based on offical version: PortAudio V19-devel WITH-DIM
PTB-INFO: New audio device with handle 0 opened as PortAudio stream:
PTB-INFO: For 2 channels Playback: Audio subsystem is Windows DirectSound, Audio device name is Primary Sound Driver
PTB-INFO: Real samplerate 44100.000000 Hz. Input latency 0.000000 msecs, Output latency 39.977324 msecs.
#### Arriving at the critical call (ahandle=0) ...
Caught MathWorks::System::FatalException
>>


2



---In psychtoolbox@yahoogroups.com, <marc.repnow@...> wrote :

>To whom it may concern, here are some audio latency measurements.

>PTB PA/default (DirectSound):      52 .. 60 ms
>PTB PA/ASIO4ALLv2:                 8.8 .. 13.8 ms
>C-program / waveOutXXX:            14.3 .. 23.3 ms
>C-program / Audio Core Interface:  3.7 .. 4.7 ms

>This is with Win7/64 and the HRT HeadStreamer USB audio interface (which uses standard Windows >drivers), measured against a parallel port trigger output. First, the sound was prepared, then a pause of >random duration (using WaitSecs or the high performance timer) was awaited in order to de-synchronize the >process with respect to any other clocks, then the parallel port trigger issued, and finally the audio replay >started.

With "Audio Core Interface" you mean WASAPI, as far as i can see? PsychPortAudio probably supports that interface in a rudimentary form, although i don't remember ever testing it. The WASAPI backend in the underlying Portaudio engine was in early stages of development when i branched off from the upstream code and modified it for our needs. E.g., if it works at all, it won't support timestamping and scheduling.

The ASIO4All performance is what one would expect from a non-ASIO sound card.

But usually most people are not interested in very low absolute latency, but timing precision, e.g., when they want to synchronize or offset sound from visual presentation or other stimulation with controlled timing. With a naive sound driver implementation one usually tries to aim for low latency to kind of approximate this, but PsychPortAudio's sound scheduling is more clever than that and can use status information provided by the sound hardware and prediction to achieve high timing precision on suitable hardware + backends. On Linux and OSX this usually just works, but on MS-Windows the only way we were able to achieve the sufficient amount of control was with native ASIO sound cards, and sometimes if one gets lucky with the ASIO4All emulation, if the underlying windows kernel sound driver was of sufficient quality and only the API sucked. That's why i always recommend native ASIO cards - or ASIO4All as a stop gap measure - if a poor soul has to use MS-Windows in the first place.

>Regarding the DirectSound API, this is not really reliable concerning the timing as well as the sound. It seems >fine for about a minute or so before it gets screwed up here and there (same for all latency classes except 0). >I did not look further into this.

That's the effect of the Window kernel mixer. On many (most?) systems you can't go below about 40-80 msecs latency without malfunctions.

>Regarding the ASIO4ALL API, at first, latency class 0 was the only class which provided clean sounds, but >this class is not usable due to latencies of 450ms or so. However, after having increased the number of >hardware buffers from 2 to 3 (in the ASIO4ALLv2 control dialog) I could get undistorted sound using latency >class 1 which resulted in the pretty low latency values given above.

That's a good result for that method. With proper setup and use of PsychPortAudio's 'when' onset time (cfe. PsychPortAudioTimingTest) you might be able to get a timing onset precision in the sub-millisecond range if you are very lucky. With a proper ASIO sound card, or Linux or OSX, sub-millisecond precision should be a given.

>Regarding the Windows Audio Core Interface, this is a user mode API supported since Vista and I used >Exclusive-Mode Streaming (http://msdn.microsoft.com/en-us/library/windows/desktop/dd370844%28v=vs.85%29.aspx). Obviously, this interface provides quite good timing but, as so often (be it >with Windows or any other system), only under specific conditions. So the values given here could only be achieved for short beeps of max. 190ms. It worked differently and better for my no-name (meaning: don't

That just means it is not suitable for the task, if it only works for 190 msecs.

>know) onboard audio interface. But even when using less optimized modes, the latencies and jitters are >pretty low with this API throughout. Especially the event latencies during continuous replay can be brought >well below the 10ms mark.
>I don't want to go into any further details here, but it seems to me that Windows is not so bad after all. But >for a fair comparison one has to keep the number of software layers low and use APIs that are not just there >for compatibility reasons - IMHO.

Most of the numbers you cited are pretty bad by today's standards and compared to Linux or OSX. The ASIO4All result is kinda ok, it's what one would expect from a cheap onboard sound chip with Linux or OSX, although there with consistent sub-millisecond precision. The WASAPI result would be pretty good for a cheap sound card on Windows, if it worked consistently, which it apparently doesn't do according to you.

It is true though that Microsoft at least made a significant effort in improving their system for pro-audio applications with Vista/7/..., it falls less short of other systems or ASIO than in the past. Still pro audio apps want you to use a decent ASIO sound card on Windows, for the same reason i recommend it.

-mario