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...
--
https://mail.python.org/mailman/listinfo/python-list
