Codecov Report

Attention: Patch coverage is 0% with 59 lines in your changes missing coverage. Please review.

Project coverage is 8.51%. Comparing base (06c6fd0) to head (494d7c8).

❗ There is a different number of reports uploaded between BASE (06c6fd0) and HEAD (494d7c8). Click for more details.

HEAD has 6 uploads less than BASE

Flag	BASE (06c6fd0)	HEAD (494d7c8)
	18	12

@@            Coverage Diff             @@
##           master    #122        /-   ##
==========================================
- Coverage   92.37%   8.51%   -83.87%     
==========================================
  Files           2       2               
  Lines         354     235      -119     
==========================================
- Hits          327      20      -307     
- Misses         27     215       188     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ssfrr @Gnimuc @rob-luke @JeffFessler Ok, now that JuliaLang/julia#17573 is fixed, we can now use call-back functions. This means that there is a much more performant way to use PortAudio. In this minimal version, which works on my currently Windows laptop (still need to add docs and more tests), you only have to provide a call-back function in the form:

stream = PortAudioStream() do input_buffer, output_buffer, frames_per_buffer, frames_already
     # both arrays have dimensions (number_of_channels, frames_per_buffer)
     # read the input_buffer if you want, and fill up the output_buffer with new sounds
     # frames_already is the number of frames we've already processed
     # return the number of new frames we processed
     # if this is less than frames_per_buffer, the stream will stop automatically
     # otherwise, keep going
end
start(stream)
sleep(FOR_A_BIT)
close(stream)

This currently doesn't really jive well with the SampledSignals interface. We could support SampledSignals with a callback function, which puts inputs into a channel for SampledSignals and then waits for outputs from another channel from SampledSignals, but this is slow and kind of ruins the point.

My temptation is just to create a new package, maybe PortAudio2 or PortAudioCallback which offers a lower level interface to PortAudio. Given that PipeWire seems to be taking over from PulseAudio, someone will probably need to build PipeWire in BinaryBuilder sometime soon to support it. At the moment, I'm learning C and trying to translate my music software to C because I'm getting tired of waiting for someone to maintain the julia QML package. So I'm loosing a bit of steam on maintaining this tbh.

Hi,
good package. However, I was wondering how much more performant it will be with this PR. I'm toying around live audio recording and then doing some SampleBuf, SampleBufSource and SampleBufSink to pre-process the audio-data, so that I can have live transcripts with Whisper.jl, any thoughts?