Using threads for audio computing?

[lgabiot]

Le 11/05/14 17:40, lgabiot a écrit :

> I guess if my calculation had to be performed on a small number of
> samples (i.e. under the value of the Pyaudio buffer size (2048 samples
> for instance), and that the calculation would last less than the time it
> takes to get the next 2048 samples from Pyaudio, I wouldn't need the
> Queue and Thread system.
> But in my case where I need a large buffer, it might not work?
> Unless I ask pyaudio to feed me directly with 5 seconds chunks (instead
> of the usual buffer sizes: 1024, 2048, etc...), which I didn't try,
> because I hadn't though of it.

I guess this solution might probably not work, since it would mean that 
the calculation should be quick enough so it wouldn't last longer than 1 
sample (1/48000 s for instance), since while doing the calculation, no 
audio would be ingested (unless pyAudio possess some kind of internal 
concurrency system).
Which leads me to think that a buffer (queue) and separate threads 
(producer and consumer) are necessary for this task.

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. I 
believe it is quite like the way multiple processes are handled by an OS 
on a single CPU computer: process A has x CPU cycles, then process B has 
y CPU cycles, etc...
So in my case, I must have a way to make sure that:
thread 1 (which gets audio from Pyaudio and put() it in the Queue) is 
not interrupted long enough to miss a sample.
If I suppose a worst case scenario for the computer, like a 
raspberry-pi, the CPU speed is 700MHz, which gives approx 14 000 CPU 
cycles between each audio samples (at 48 kHz FS). I don't know if 14 000 
CPU cycle is a lot or not for the tasks at hands.

Well, at least, it is what I understand, but since I'm really both a 
beginner and an hobbyist, I might be totally wrong...