Close audio stream when nothing is playing

[ssfrr]

Copied from @flpf's comment in #29:

I was wondering if it would be possible to include something like Octaves 'sound()' or 'soundsc()'function in AudioiO. I just wrote a small script using AudioIO-functions to illustrate the idea. It seems to work without error messages.
I had some time to look through the code of the package and I think that I understood
your idea a little bit better. For the node-concept a steadily open stream makes much more
sense. But for simple playback of time-series or imported wave-files a function like:

using AudioIO
AudioIO.Pa_Initialize()
function soundd(sound::Vector,sampleRate::Real=48000)
    fac=div(length(sound),sampleRate);
    streamM=AudioIO.Pa_OpenDefaultStream(0,1,AudioIO.paFloat32,sampleRate,fac);
    AudioIO.Pa_StartStream(streamM);
    for i=1:fac
    AudioIO.Pa_WriteStream(streamM,convert(Array{Float32},sound[(i-1)*sampleRate+1:i*sampleRate]));
    end
    AudioIO.Pa_StopStream(streamM)
    AudioIO.Pa_CloseStream(streamM)
end 

could be of use.
The snippet above is not generic and still has errors but I guess it captures the idea.
Would this be something for AudioIO.jl or is it against the basic rationale of the package?

Seems to me there are two issues here:

1. Right now there's no way to play an array at a sample rate other than what the stream is running at (this is issue Support auto samplerate conversion #37).
2. Once the stream is started by the first node that's played, it stays open indefinitely.

If the automatic samplerate conversion worked, do you still see an advantage to closing the stream after the sample finishes playing?

I think if we want to support that behavior I'd probably make it an argument to the play method rather than a whole new one.

[flpf]

1. You are right, if different sample rates (SR) could be played by the same
   stream there would be no need to open/close a new stream.
   On the other hand, SR conversion adds computational overhead and
   introduces errors for non-rational SR ratios. And as most modern audio backends
   support multiple streams/clients I believe it would be more efficient
   to open a new stream for short audio files.
   For the node (multitrack-like) behaviour of AudioIO, different streams are
   useless because of the synchronisation and latency issues you already mentioned.
2. I am not familiar with the low-level design aspects of julia but I could
   imagine that the less IO-stream overhead the better. I noticed a rising
   CPU workload of julia and portaudio/pulseaudio when a stream is open even
   when no sound is playing.
   For a single audio file, that should only be played once, I think it would be
   more efficient if the stream is closed after the sound ends.
   For a node with multiple events (multitrack) this is definitely not the case.

Therefore I believe it would make sense to differentiate both cases
(single-track/multi-track) and use different approaches for the play function.

Please keep in mind that I used julia and AudioIO on Linux only, so my
observations could be specific to my setup and not an issue on MacOS/Win.