<p>It generally helps to provide some sort of specification as to how well you want to control the timing. There are 4 orders of magnitude difference between the 100 ms timing accuracy required for auditory and visual stimuli to be judged simultaneous (<a href="http://link.springer.com/article/10.3758/BF03193329s" rel="nofollow">Zampini et al. 2005</a>) and the 0.1 ms timing accuracy required for binaural stimuli to be judged simultaneous (<a href="http://scitation.aip.org/content/asa/journal/jasa/46/6B/10.1121/1.1911887" rel="nofollow">Hershkowitz and Durlach 1969</a>). There are two types of latency when it comes to audio stimulation, what I will refer to as the ongoing and onset latencies.</p>

<p><strong>Ongoing Latency</strong></p>

<p>Imagine a study on virtual reality where the subjects head orientation is being tracked in real time presented sound depends on the orientation. In this type of study it is not possible to load the sound in advance onto the sound device. If the audio device requires 1000 ms of sound in advance so as to not drop samples, there will be a noticeable lag between moving the head and the sound position updating. <a href="http://www.idc.ul.ie/icad2005/downloads/f39.pdf" rel="nofollow">Scarpaci et al. (2005)</a> found that an for these types of studies an overall latency of under 32 ms is desirable. This overall latency needs to include the time required to read the current position as well as generate the sound and then buffer the sound. Depending on the speed of other devices and the amount of required processing time, this may only leave 5-10 ms for sound buffering. Head movements are relatively slow and our sensitivity to the location of a sound is relatively poor, and other experiments may require much lower latencies.</p>

<p>A perfect sound device would have an ongoing latency less than a sample. With a sample rate of 10 kHz, the sound hardware has 0.1 ms per sample, but at 100 kHz it only has 0.01 ms per sample so when choosing a sound device it is important to consider the sample rate. Off the shelf systems with <a href="http://www.portaudio.com/" rel="nofollow">PortAudio</a> can provide ongoing latencies on the order of 10 ms. The <a href="https://docs.psychtoolbox.org/PsychPortAudio" rel="nofollow">PsychToolbox patches PortAudio</a> and can achieve lower ongoing latencies. <a href="http://www.idc.ul.ie/icad2005/downloads/f39.pdf" rel="nofollow">Scarpaci et al. (2005)</a> achieved subsample ongoing latency with a 44.1 kHz sample rate by using a real time Linux kernel and a dedicated DA board. Custom systems by <a href="http://www.tdt.com/" rel="nofollow">TDT</a> can provide subsample ongoing latency with a 200 kHz sample rate.</p>

<p><strong>Onset Latency</strong></p>

<p>Imagine an EEG study in which one wants to start recording from the EEG electrodes at the same time as the sound starts playing. Unlike ongoing latency, it is possible to load the stimulus onto the sound device in advance. The goal is then to have the sound device start as quickly as possible. In my opinion, it is more important to minimize the variability in this latency rather than minimize the latency itself. If it takes between 99 and 101 ms (high latency, low variability) to start the sound, then if the EEG recordings are delayed by 100 ms, the onset of the sound and recordings will be within +/-1 ms. If however, it takes between 0 and 20 ms (low latency, high variability) and the EEG recordings are delayed by 10 ms, then the onset asynchrony can be as large as 10 ms. The case where the onset latency really matters is when the start of the sound is externally triggered. For example if a subject presses a button to start the sound, having a "long" delay would be problematic.</p>

<p>Similar to ongoing latencies off the shelf systems can provide onset latencies on the order of 10 ms and <a href="https://docs.psychtoolbox.org/PsychPortAudio" rel="nofollow">PsychToolbox</a> can get down to about 5 ms (maybe less). <a href="http://www.idc.ul.ie/icad2005/downloads/f39.pdf" rel="nofollow">Scarpaci et al. (2005)</a> did not measure onset latency and performance is likely poor since the system was not optimized for that aspect of sound delivery. The <a href="http://www.tdt.com/" rel="nofollow">TDT</a> systems provide an external trigger and can provide onset latencies down to levels that make it difficult to measure (sub microsecond). <a href="http://www.crsltd.com/tools-for-vision-science/auditory-stimulation/audiofile-audio-stimulus-processor/" rel="nofollow">CRS</a> provides custom hardware that can be externally triggered so should provide extremely low onset latencies, but the system requires the stimulus to be loaded in advanced so it essentially has an infinite ongoing latency.</p>

CC BY-SA 3.0
2014-10-31T03:26:35.657Z
I concur with StrongBad: I have experience with both TDT and the PsychoPhysics Toolbox (PTB-3) in Matlab. The TDT system is hardware that is specifically designed for audio-related tasks and brings latencies down to sub-microseconds. If you do not wish to spend hundreds to tens of thousands of dollars on a TDT modular system, then PTB-3 offers a free software environment add-on to Matlab and it offers EXCELLENT help files and instructions how to bring down latencies in the millisecond order on a pc/mac/Linux machine. Hope this helps.
AliceD
CC BY-SA 3.0
2014-09-09T09:21:10.540Z
2014-09-09T09:21:10.540Z
StrongBad
<p>I need to carefully control the latency and timing of auditory stimulation in an upcoming experiment.  Some of this depends on software, but my question is specifically relating to <strong>hardware</strong>, <strong>drivers</strong> and <strong>OS kernel</strong>.  In other words, I'm not looking for advice on programming languages; I have that part covered.</p>
<h1>Driver &amp; OS</h1>
<p>I'm somewhat familiar with the ASIO4ALL driver suite in Windows, but I was weighing this against the option of using a Linux distribution (e.g. Ubuntu) with a real-time kernel installed.  My concern is that sound is notoriously problematic in Linux.  I seem to recall real-time audio being all but impossible if you're working with ALSA.  Is the same true of Pulseaudio?  Has anybody successfully set up low-latency audio output in Linux?</p>
<h1>Hardware</h1>
<p>What sound cards are commonly used?  Can anybody suggest some specialized hardware?  Ideally, I'd like to stick with a PCI card of some sort and not have to resort to bulky external sound cards, but I could be swayed if these cards offer significant advantages.</p>
<p>Thanks!</p>

CC BY-SA 3.0
2014-07-10T13:40:09.987Z
Have you read the specific instructions and benchmarks for the specific experimental software you're gonna use?
jona
CC BY-SA 3.0
2014-07-10T15:10:57.287Z
@jona, Sure, but there's no mention of recommended hardware, nor is there any information about real-time Linux kernels.  Is there some spec whose relevance I'm overlooking?
Louis Thibault
CC BY-SA 3.0
2014-07-10T16:07:25.920Z
What software are you going to use? All the experimental software I know comes with extensive discussions of this topic.
jona
CC BY-SA 3.0
2014-07-10T16:54:06.303Z
@jona, This PC will mainly be running psychopy (and other python-driven scripts).  Psychtoolbox is also likely to be installed.
Louis Thibault
<experimental-psychology><psychophysics><hearing><stimulation>
What hardware setup is commonly used for low-latency audio stimulation?
Louis Thibault
# What hardware setup is commonly used for low-latency audio stimulation?

(Asked by: username_0 on 2014-07-10)

I need to carefully control the latency and timing of auditory stimulation in an upcoming experiment. Some of this depends on software, but my question is specifically relating to **hardware**, **drivers** and **OS kernel**. In other words, I'm not looking for advice on programming languages; I have that part covered.

# Driver & OS

I'm somewhat familiar with the ASIO4ALL driver suite in Windows, but I was weighing this against the option of using a Linux distribution (e.g. Ubuntu) with a real-time kernel installed. My concern is that sound is notoriously problematic in Linux. I seem to recall real-time audio being all but impossible if you're working with ALSA. Is the same true of Pulseaudio? Has anybody successfully set up low-latency audio output in Linux?

# Hardware

What sound cards are commonly used? Can anybody suggest some specialized hardware? Ideally, I'd like to stick with a PCI card of some sort and not have to resort to bulky external sound cards, but I could be swayed if these cards offer significant advantages.

Thanks!

**Tags:** experimental-psychology, psychophysics, hearing, stimulation

> **Comments:**
> **username_1**: Have you read the specific instructions and benchmarks for the specific experimental software you're gonna use?  
> **username_0**: @username_1, Sure, but there's no mention of recommended hardware, nor is there any information about real-time Linux kernels.  Is there some spec whose relevance I'm overlooking?  
> **username_1**: What software are you going to use? All the experimental software I know comes with extensive discussions of this topic.  
> **username_0**: @username_1, This PC will mainly be running psychopy (and other python-driven scripts).  Psychtoolbox is also likely to be installed.  

---

## 1 answers

### Answer by username_2 on 2014-09-09. Score: 4 | Accepted answer

It generally helps to provide some sort of specification as to how well you want to control the timing. There are 4 orders of magnitude difference between the 100 ms timing accuracy required for auditory and visual stimuli to be judged simultaneous ([Zampini et al. 2005](http://link.springer.com/article/10.3758/BF03193329s)) and the 0.1 ms timing accuracy required for binaural stimuli to be judged simultaneous ([Hershkowitz and Durlach 1969](http://scitation.aip.org/content/asa/journal/jasa/46/6B/10.1121/1.1911887)). There are two types of latency when it comes to audio stimulation, what I will refer to as the ongoing and onset latencies.

**Ongoing Latency**

Imagine a study on virtual reality where the subjects head orientation is being tracked in real time presented sound depends on the orientation. In this type of study it is not possible to load the sound in advance onto the sound device. If the audio device requires 1000 ms of sound in advance so as to not drop samples, there will be a noticeable lag between moving the head and the sound position updating. [Scarpaci et al. (2005)](http://www.idc.ul.ie/icad2005/downloads/f39.pdf) found that an for these types of studies an overall latency of under 32 ms is desirable. This overall latency needs to include the time required to read the current position as well as generate the sound and then buffer the sound. Depending on the speed of other devices and the amount of required processing time, this may only leave 5-10 ms for sound buffering. Head movements are relatively slow and our sensitivity to the location of a sound is relatively poor, and other experiments may require much lower latencies.

A perfect sound device would have an ongoing latency less than a sample. With a sample rate of 10 kHz, the sound hardware has 0.1 ms per sample, but at 100 kHz it only has 0.01 ms per sample so when choosing a sound device it is important to consider the sample rate. Off the shelf systems with [PortAudio](http://www.portaudio.com/) can provide ongoing latencies on the order of 10 ms. The [PsychToolbox patches PortAudio](https://docs.psychtoolbox.org/PsychPortAudio) and can achieve lower ongoing latencies. [Scarpaci et al. (2005)](http://www.idc.ul.ie/icad2005/downloads/f39.pdf) achieved subsample ongoing latency with a 44.1 kHz sample rate by using a real time Linux kernel and a dedicated DA board. Custom systems by [TDT](http://www.tdt.com/) can provide subsample ongoing latency with a 200 kHz sample rate.

**Onset Latency**

Imagine an EEG study in which one wants to start recording from the EEG electrodes at the same time as the sound starts playing. Unlike ongoing latency, it is possible to load the stimulus onto the sound device in advance. The goal is then to have the sound device start as quickly as possible. In my opinion, it is more important to minimize the variability in this latency rather than minimize the latency itself. If it takes between 99 and 101 ms (high latency, low variability) to start the sound, then if the EEG recordings are delayed by 100 ms, the onset of the sound and recordings will be within +/-1 ms. If however, it takes between 0 and 20 ms (low latency, high variability) and the EEG recordings are delayed by 10 ms, then the onset asynchrony can be as large as 10 ms. The case where the onset latency really matters is when the start of the sound is externally triggered. For example if a subject presses a button to start the sound, having a "long" delay would be problematic.

Similar to ongoing latencies off the shelf systems can provide onset latencies on the order of 10 ms and [PsychToolbox](https://docs.psychtoolbox.org/PsychPortAudio) can get down to about 5 ms (maybe less). [Scarpaci et al. (2005)](http://www.idc.ul.ie/icad2005/downloads/f39.pdf) did not measure onset latency and performance is likely poor since the system was not optimized for that aspect of sound delivery. The [TDT](http://www.tdt.com/) systems provide an external trigger and can provide onset latencies down to levels that make it difficult to measure (sub microsecond). [CRS](http://www.crsltd.com/tools-for-vision-science/auditory-stimulation/audiofile-audio-stimulus-processor/) provides custom hardware that can be externally triggered so should provide extremely low onset latencies, but the system requires the stimulus to be loaded in advanced so it essentially has an infinite ongoing latency.

> **Comments:**
> **username_3**: I concur with username_2: I have experience with both TDT and the PsychoPhysics Toolbox (PTB-3) in Matlab. The TDT system is hardware that is specifically designed for audio-related tasks and brings latencies down to sub-microseconds. If you do not wish to spend hundreds to tens of thousands of dollars on a TDT modular system, then PTB-3 offers a free software environment add-on to Matlab and it offers EXCELLENT help files and instructions how to bring down latencies in the millisecond order on a pc/mac/Linux machine. Hope this helps.  

---

