In article <536f869c$0$2178$426a7...@news.free.fr>, lgabiot <lgab...@hotmail.com> wrote:
> Hello, > > I'd like to be able to analyze incoming audio from a sound card using > Python, and I'm trying to establish a correct architecture for this. > > Getting the audio is OK (using PyAudio), as well as the calculations > needed, so won't be discussing those, but the general idea of being able > at (roughly) the same time: getting audio, and performing calculation on > it, while not loosing any incoming audio. > I also make the assumption that my calculations on audio will be done > faster than the time I need to get the audio itself, so that the > application would be almost real time. > > > So far my idea (which works according to the small tests I did) consist > of using a Queue object as a buffer for the incoming audio and two > threads, one to feed the queue, the other to consume it. > > > The queue could store the audio as a collection of numpy array of x samples. > The first thread work would be to put() into the queue new chunks of > audio as they are received from the audio card, while the second would > get() from the queue chunks and perform the necessary calculations on them. > > Am I in the right direction, or is there a better general idea? > > Thanks! If you are going to use threads, the architecture you describe seems perfectly reasonable. It's a classic producer-consumer pattern. But, I wonder if you even need anything this complicated. Using a queue to buffer work between threads makes sense if the workload presented is uneven. Sometimes you'll get a burst of work all at once and don't have the capacity to process it in real-time, so you want to buffer it up. I would think sampling audio would be a steady stream. Every x ms, you get another chunk of samples, like clockwork. Is this not the case? -- https://mail.python.org/mailman/listinfo/python-list
