The first option is not so much a priority but a simple flushing of all DMDX files at the beginning of each item so that Win32's write behind caching doesn't write the buffers out to disk half way through a display sequence. Why not do this always? Well, it raises the average ISI for a start and there is always disk activity before any trial.  Note that prior to version 4.0.3.0 of DMDX item files that have large numbers of <SkipDisplay> items in them will be adversely affected by turning Always Flush File Buffers on as it is only on later versions that skip display items no longer flush the file buffers (if it's turned on here).  To elaborate, in the old days background disk activity during an item was enough to cause millisecond callback variations if not outright display errors and if Windows was allowed to queue disk requests arbitrarily disk activity could (conceivably) occur during critical times of an item's presentation.  Machines are fast enough now and there's so much else going on anyway that forcing DMDX to flush it's file buffers is moot, if not outright counter productive.

    The second option is to make DMDX not overwrite diagnostics.txt each time it runs. If enabled someone will either have to periodically prune or outright delete the diagnostics.txt file as it will grow to enormous sizes over time.

    The third option is to boost the vertical retrace thread's priority to THREAD_PRIORITY_TIME_CRITICAL if the use of the high performance timer is enabled, if the high performance timer is disabled it's priority can't be boosted, the millisecond timer will be preempted by the retrace thread. This will also interact with the fourth option below, changing the priority of the sound thread.

    The fourth option is to boost DMDX's process priority to either HIGH_PRIORITY_CLASS or REALTIME_PRIORITY_CLASS.

    The fifth option of modifying the sound thread's priority is provided to minimize the variability of the latency of sounds. Most machines have a latency of around 15 milliseconds, however with the retrace thread (usually running at ABOVE NORMAL) preempting the sound thread there appears to be an additional variable latency, perhaps as much as 20 milliseconds. Assuming you have the equipment to measure this some compromise may be reached to minimize this variability.


    Currently the main loop of DMDX that moves video memory into back buffers and file I/O runs at NORMAL priority, the vertical retrace and sound threads run at ABOVE NORMAL, the input related threads run at HIGHEST and millisecond scheduler runs at TIME CRITICAL (I'm guessing, the callback's priority is set by the operating system, certainly it isn't preemted by much). Note that the input devices DigitalVOX and RecordVocal run at the HIGHEST priority even though they are sound related.

    The priority a thread has (ie: whether it or some other machine process gets executed) is determined by a combination of the process's priority (DMDX's priority) and the thread's priority. The whole issue of how these priorities interact is enormously complicated, for example from the win32 help:
   
Be very careful when manipulating priorities to ensure that a high-priority thread does not consume all of the available CPU time. A thread with a base priority level above 11 interferes with the normal operation of the operating system.

The following table shows the base priority levels for each combination of priority class and thread priority value. Note that for IDLE_PRIORITY_CLASS, NORMAL_PRIORITY_CLASS, and HIGH_PRIORITY_CLASS, this base level can receive dynamic boosts.