Expose callback events? about soundcard HOT 6 CLOSED

This is a big undertaking. I know from experience that implementing these callback interfaces can be quite tricky, and fraught with difficult problems (lack of error signaling, frequent segfaults, timing issues...).

Also, the Windows and Linux side currently do not use the callback interface, so this would require a big re-architecting. The macOS side has some really weird quirks with its callbacks, that we would need to carefully abstract away to make a callback API usable.

And finally, I haven't found callback interfaces to be faster or more reliable than polling interfaces. I would strongly recommend simply using the existing polling interface in a thread, and possibly tie a callback to that instead of using the C callbacks.

But of course I won't stop you, and will try to help wherever I can.

from soundcard.

Thanks for the explanation. I will look into the option of maybe implementing functions that poll gor audio data and call a provided callback function just for the purpose of abstracting polling and providing a more clean interface. If I'll manage to create anything useful I'll create a pull request.

from soundcard.

@bastibe What polling interface? I can't find any info about it in the documentation.

from soundcard.

@RuABraun
You could try something like:

input = soundcard.all_microphones(include_loopback=True)[self.device]
with input.recorder(self._samplerate, blocksize=self._chunksize) as recorder:
    data = recorder.record(self._chunksize)
    self._callback(data)

from soundcard.

And callback would then do stuff on a separate process is that the idea? My worry is that the second recorder.record() ends you will start skipping samples from the input until you call it again.

Actually I've just realized I can just use concurrent futures with a large enough value for chunk size so that I can do whatever needs to be done before the next buffer is ready.

from soundcard.

@slole, thank you, that's exactly what I meant, yes.

@RuABraun, If your processing code takes (potentially) longer than chunksize, you might want to put data into a queue, and read that queue from a separate thread.

Be aware, however, that even a separate thread might stall the audio thread enough to drop frames. Audio runs in real time, and real time does not wait for anyone.

Alternatively, write the data to a file or socket, and read that from a separate process. Then you should be safe from dropouts.

from soundcard.