Interaction of Priority and PsychPortAudio

1
Dear Mario and list!

We have the following problem in our setup (WinXP 32 bit, Matlab 7.10, latest PTB beta, Creative X-Fi Xtreme ASIO enabled sound card with most recent drivers and "bit-accurate playback"-option enabled/effects disabled):

When using PsychPortAudio in combination with Priority(1) almost any load on the CPU likely causes audible artifacts. E.g. when waiting for subject's response in a while loop (even when mitigated by WaitSecs('YieldSecs', 0.001)) sound is distorted, mainly by irregular click sounds. This happens also on a second machine with a dual core CPU (other core is idle).

Sound playback is fine with Priority(0) but then we are afraid of timing problems.

I have tested suggestedLatency: with Priority(0) it works well with the automatically adjusted 1msec output latency, with Priority(1), ~50msec latency are needed for artifact free playback. Sampling rate and requested latency class seem not to matter.

Is there anything obvious we missed? Is it possible to adjust the priority of the PortAudio thread/background process? We would be grateful for any hint!

Thank you!, Best,
Andreas
2
--- In psychtoolbox@yahoogroups.com, Andreas Widmann <widmann@...> wrote:
>
> Dear Mario and list!
>
> We have the following problem in our setup (WinXP 32 bit, Matlab 7.10, latest PTB beta, Creative X-Fi Xtreme ASIO enabled sound card with most recent drivers and "bit-accurate playback"-option enabled/effects disabled):
>
> When using PsychPortAudio in combination with Priority(1) almost any load on the CPU likely causes audible artifacts. E.g. when waiting for subject's response in a while loop (even when mitigated by WaitSecs('YieldSecs', 0.001)) sound is distorted, mainly by irregular click sounds. This happens also on a second machine with a dual core CPU (other core is idle).
>
> Sound playback is fine with Priority(0) but then we are afraid of timing problems.
>
> I have tested suggestedLatency: with Priority(0) it works well with the automatically adjusted 1msec output latency, with Priority(1), ~50msec latency are needed for artifact free playback. Sampling rate and requested latency class seem not to matter.
>
> Is there anything obvious we missed? Is it possible to adjust the priority of the PortAudio thread/background process? We would be grateful for any hint!
>

50 msecs for artifact free playback? That sounds like a new high-score, even for ms-windows.

PTB on WindowsXP and earlier always locks both the main thread and the audio driver thread to cpu core 1, so they basically compete for core 1 while leaving core 2 idle. This is done to work around various operating system and hardware bugs wrt. to handling of time. What you can do is set the optional 'lockToCore1' parameter of PsychPortAudio('EngineTunables',...) to zero, so the audio driver thread is free to choose different cores on a multi-core system. Of course that makes you vulnerable to potential bugs in the clock hardware of your computer. See <http://psychtoolbox.org/FaqGetSecsTestFails> for more details and ways to "fix" the clock problems without losing too much performance. I think our Wiki page btw. is too optimistic about more recent cpu's being trouble free, because since that page was last updated, cpu vendors have come up with new creative ways of screwing with time and clocks.

On Vista and later we don't lock threads to core 1 anymore, under the (optimistic) assumption that Microsoft managed to fix their os, given that they had multiple years of time between the release of Vista and when these problems became known.

We also don't lock background processing threads which don't need precision timekeeping. E.g., things like GStreamer's movie decoding threads can use multi-core even on WinXP.

It all boils down to Windows being a bad choice for timing sensitive applications.
No such problems or restrictions exist on OS/X or Linux to my knowledge. In the case of OS/X due to Apple's tight control over their hardware, on Linux due to good engineering - the system provides various rather fancy builtin checks and workarounds to compensate for broken clock hardware.

But 50 msecs seems a bit excessive. We cannot control the priority of the audio device driver thread, but normally such threads are run at high priorities. Maybe your sound driver has a bug. Or some other component in your system is misconfigured and acting up. One quick test is the freely downloadable "dpclat.exe" to quickly gauge general system timing.

ciao,
-mario