Exclusive audio device lock.

[guruofquality]

From @romeojulietthotel on May 30, 2017 1:46

Pothos takes an exclusive lock on the audio device. I can't think of a reason why it would need to do this. I can run multiple ffplay and they get along fine. But if I then start Pothos while an ffplay is running Pothos spews out errors constantly into the "Message Window".

On stdout I see this:

Expression 'parameters->channelCount <= maxChans' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1513
Expression 'ValidateParameters( outputParameters, hostApi, StreamDirection_Out )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1845

If I start Pothos and then try to play audio via ffplay, ffplay cannot acquire an audio device due the exclusive lock by Pothos.

I read this:

http://portaudio.com/docs/v19-doxydocs/api_overview.html

I/O Methods: callback and read/write

PortAudio offers two methods for communicating audio data between an open Stream and your Application: (1) an asynchronous callback interface, where PortAudio calls a user defined callback function when new audio data is available or required, and (2) synchronous read and write functions which can be used in a blocking or non-blocking manner. You choose between the two methods when you open a Stream. The two methods are discussed in more detail below.

Copied from original issue: pothosware/PothosFlow#150

[guruofquality]

@romeojulietthotel I'm not sure what takes the lock, but I was thinking that one possibility would be to move the call to Pa_OpenStream (from AudioBlock::setupStream) to the AudioSource/Sink::activate() function. That way there would be no lock acquired until the topology is actually activated.

[romeojulietthotel]

I guess that gives a small relief. I have found some apps will use audio at the same time and some will not. CubicSDR uses https://github.com/thestk/rtaudio/ and it also wants exclusive access to audio.