Sound class incompatible with Sound Blaster Audigy Rx

Builder
1

Hi,

I am running PsychoPy 2024.1.5 on Windows 10. The Creative Sound Blaster Audigy Rx is a low-latency PCIe sound card (recommended, for example, by EyeLink for use with their eye tracker). The correct drivers are installed (I received a download link from Creative). The card is connected to stereo (2.0) speakers. When running a PsychoPy program that uses the Sound class with ‘ptb’, ‘pyo’, or ‘sounddevice’ as the chosen audio library, no sound comes out of the speakers. There are no error messages. The problem is specific to a combination of the sound card and these audio libraries, since:

(1) using a different sound device: these audio libraries produce sound when the speakers are instead connected to the sound device that is on the motherboard, or to a Creative Sound Blaster Audigy Fx V2 PCIe card (which does not have low latency);

(2) using a different audio library: running a PsychoPy program that uses the Sound module with ‘pygame’ as the chosen audio library, sound is played via the Audigy Rx.

The ‘pygame’ audio library unfortunately has terrible audio latency. The solution I have found is to abandon the Sound class and instead use the ‘winsound’ library that is part of the standard Python installation (winsound — Sound-playing interface for Windows — Python 3.13.3 documentation). This is giving me low latencies (e.g. 11.4 +/- 0.3 ms when playing a tone, as opposed to an audio file, and when sending TTLs via the parallel port). So using ‘winsound’ works for me, but I thought I’d raise this issue all the same in case it can be fixed before other people encounter it.

Richard

1 Like
2

Thanks for the info Richard.
I’m surprised winsound only gives you latency @11ms - I would have expected better. Are you triggering the sound after the win.flip? That might improve your timings. Also, this post might
post
be of interest to you (but it’s oldish - W7, though looks relevant)
THanks for prompting me to properly investigate my sound latency (from Matlab) using an external USB linked Soundblaster unit. I will try it with a dual channel oscilloscope and compare onset against TTL trigger form the parallel port.
I’d be interested to hear how you get on if you do find time to investiagte this further.
Cheers, John

3

Hi John, many thanks for your helpful reply. I’m happy with the latencies that I’m getting, but for other applications there could be problems with using winsound, as I think you’re suggesting.

The application that I was running the audio latency testing for was an EEG project and my understanding of the requirements for this kind of research (I’m a technician) is that the variation in latency, more than the mean latency, is important. If the latency has a low variation, then the mean can be used to correct the timestamps of any markers that appear on the EEG trace. The standard deviation of 0.3 ms corresponded to a range of 2 ms, which seemed pretty good.

For the measurements that I reported, I was not triggering the sound after a win.flip, as I wanted to fully understand the relative timing of the sound and TTL signals. The program waited for a key press and then played the sound asynchronously followed by sending a TTL. But in a subsequent version of the program, designed to mimic more closely the actual program that was going to be used to test participants, I did trigger the sound (and the TTL) after a win.flip and this seemed to make a small improvement to the audio latency. By that stage in testing, I was playing an audio file instead of a tone and sending the TTL through a button box instead of via the parallel port, again to mimic the real program, and both of these things affected latency, but with these factors being equal the latency appeared to be slightly better after (10.3 +/ 0.5 ms) than before (10.4 +/- 0.7 ms) synchronising the sound onset and TTL with the screen update. It is hard to say for sure, as I only ran one test of 100 trials in the ‘before’ condition before deciding for reasons of external validity rather than performance to continue with the ‘after’ condition.

The post that you provided a link to – thanks! – suggests using the ‘SND_MEMORY’ flag to play the sound from memory and opening a new thread to overcome the incompatibility between the ‘SND_MEMORY’ and ‘SND_ASYNC’ flags. I didn’t take this approach, instead using the ‘SND_FILENAME’ and ‘SND_ASYNC’ flags. I would have tried the recommended approach if I’d known about it, and perhaps it would have reduced the mean latency; but I’m satisfied with the latencies that I got so there seems no need to go back and change it now. The post also warned against using the ‘SND_ASYNC’ flag with winsound on the grounds that it slightly reduces the duration of the sound that is played. Fortunately this isn’t a concern for me, as in the program I’m doing the testing for the sound is a fairly arbitrary feedback stimulus of 200 ms duration, but it is good to be aware of this, as it could be relevant in other applications.

Overall, winsound seems to be doing a good job for me, but might not be in other cases, if the mean latency or the duration of the audio stimulus are important considerations. It would for this reason be very helpful if the problem that I’ve encountered with the ptb, pyo and sounddevice libraries could be looked into.

P.S. I’m using a Black Box Toolkit for measuring latencies.