Speak:spd-say in Linux GNU/Octave hangs during the system call

[hyiltiz]

Debian testing 64bit Linux version 4.1.0-2-amd64, GNU/Octave 4.0.0, Psychtoolbox 3.0.12 - Flavor, Thinkpad E50 Laptop with Dual Display through VGA. I will come up with more information if needed.
Installed through Debian's official repositories (not NeuroDebian).

Running Speak interactively from within /usr/bin/octave-cli or using the /usr/bin/octave-cli --eval flag form within the command line can successfully call do a system() call to spd-say and gives speech. However, I have a code about 5000 lines where the system() call to spd-say simply hangs until ^C key press kills the instance, and then no speech is out, and we get warning from Speak that spd-say has not been installed; in fact, it was simply that the return status from spd-say was abnormal due to the ^C manual kill.

The Speak part in that 5000 lines of code produces speech and works as expected under MATLAB (both tested Windows 7/8 64bit, OS X). So what could this problem be? I am interested in reducing that 5000 lines of code so that one could find out why Speak does not work under that case, but echo funcName on syntax for Octave does not exist, and it is literally too hard to locate the issue.

Do you have any hint that some other commands in Psychtoolbox (Priority, PsychPortAudio, PsychHID etc.) has been interfering with Speak in a platform-dependent way which caused this incompatibility?

@denispelli
@kleinerm

[kleinerm]

PsychPortAudio would be a good candidate. It takes exclusive control of the sound card on Linux for best timing and control, blocking the PulseAudio sound server. If spd-say depends on PulseAudio as output then it would probably hang. It's the same with GStreamer movie playback, you can't do it in parallel with PsychPortAudio, unless you play movies without sound and set some flag in the 'OpenMovie' call.

[hyiltiz]

Wow! Could we consider that a bug since someone using Speak can reasonable using PsychPortAudio as well for other audio cues/stimuli, but not being able to use them together seems absurd.

Maybe we could implement one of the following:

• Turn off PsychPortAudio if active before a system() call to spd-say --wait on Linux, then turn it back on;
• Redirect spd-say --wait's output to PsychPortAudio somehow so we are not relying on the PulseAudio server for it.

I think the first could be a quick workaround. Could turning PsychPortAudio on and off for each Speak call could affect performance?

BTW, I realized that the code I was talking about does not use PsychPortAudio at all; it uses its Snd() wrapper, if that matters.

[kleinerm]

It's not a bug, but a known limitation. In order to provide precise audio output, low latency and especially precisely timed audio output and input, PsychPortAudio needs to take exclusive control of the audio card, and that will block the regular desktop sound server and all "normal" audio applications. This is the case on Linux, and on Windows with most ASIO sound cards (the only way to get any reliably timed and controlled audio on Windows). On OSX the sound system allows shared use but silently screws up timing in subtle ways if you do, so you are not off any better.

On Linux one could likely play tricks with ALSA to get an OSX like config, where one can use PsychPortAudio with limited precision and higher latency in a compatible way. But that's extra work, and i don't have time for that atm. You can use the 'EngineTunables' function to disable the automatic suspension of PulseAudio, but then PPA only sort of works and has bugs iirc.

You can't really turn of PsychPortAudio, as that would require completely closing down the driver, releasing all resources etc. Usercode would have to manually close the audio driver before using Speak, and then setting up everything anew. What one could do is let spd-say write its output to a .wav file, then read that into PPA and play it. A bit clunky but doable.

I'm marking this one as "enhancement" request for future work.

[hyiltiz]

Thank u! I keep all instructions etc in a single file so i18n could be easily implemented. Maybe should do the same for sounds; rendering the wav during the initialization process without actually playing it could be a good dynamic solution .