Using threads for audio computing?

[lgabiot]

Le 12/05/14 08:13, Stefan Behnel a écrit :
> This sounds like a use case for double buffering. Use two buffers, start
> filling one. When it's full, switch buffers, start filling the second and
> process the first. When the second is full, switch again.
>
> Note that you have to make sure that the processing always terminates
> within the time it takes to fill the other buffer. If you can't assure
> that, however, you have a problem anyway and should see if there's a way to
> improve your algorithm.
>
> If the "fill my buffer" call in PyAudio is blocking (i.e. if it returns
> only after filling the buffer), then you definitely need two threads for this.
>
>
>> But AFAIK the python GIL (and in smaller or older computers that have only
>> one core) does not permit true paralell execution of two threads.
>
> Not for code that runs in the *interpreter", but it certainly allows I/O
> and low-level NumPy array processing to happen in parallel, as they do not
> need the interpreter.
>
> Stefan
>
>
Thanks for your answer.

If I follow your explanations, I guess I have to review my understanding 
of python execution model (I have to admit it is quite crude anyway).

In my understanding, without threads, I would have two functions:
- get_audio() would get the 5 seconds of audio from Pyaudio
- process_audio() would process the 5 seconds of audio

the main code would be roughly executing this:
while(True)
	get_audio()
	process_audio()

so since the audio is a live feed (which makes a difference, say, with 
an audio file analyser program), the get_audio() part must take 5 
seconds to execute. (but most probably the processor stays still most of 
the time during the get_audio() part).
then once get_audio() is done, process_audio() begins.
Process_audio will take some time. If that time is greater that the 
times it takes for the next audio sample to arrive, I have a problem.
(which you already explained differently maybe with:
 > If the "fill my buffer" call in PyAudio is blocking (i.e. if it returns
 > only after filling the buffer), then you definitely need two threads 
for this.
)

So if I follow you, if the Pyaudio part is "Non-blocking" there would be 
a way to make it work without the two threads things. I'm back to the 
Pyaudio doc, and try to get my head around the callback method, which 
might be the good lead.