search

PortAudio / portaudio

PortAudio is a cross-platform, open-source C language library for real-time audio input and output.
Other
1.46k stars 303 forks source link

[Enhancement] I think we should make the blocking read API better #874

Open RightFS opened 8 months ago

RightFS commented 8 months ago

situation: I need capture the audio output (loopback) to do some echo cancellation. The timing requirements are very strict, if I use the callback to capture I need to do some addtional synchronizations. But If I use the blocking API, It will not return when no sound is palying...

I think we can return a muted buffer after the wait time.

wait time = buffer length / sampleRate / channels

example: require to fill a 8 samples buffer on a 48000/16/2 stream, just wait for 4/48000ms then fill 0 to the buffer and return it, if there are some sound in the middle of buffer, the buffer should be 00001110

I want to record a continuous audio stream, if no sound just return muted buffer instead of blocking.

The current situation: time 12345678 buff 345

What I want: time 12345678 buff 00045600

RossBencina commented 8 months ago

Do you mean you just don't want to block if there is no data? In that case, just check for the buffer fill level with Pa_GetStreamReadAvailable before you call Pa_ReadStream and only read as much data as is available.

For echo cancellation (or full-duplex IO in general) I would be inclined to use the callback API as it will typically have more deterministic latency.

RightFS commented 8 months ago

Do you mean you just don't want to block if there is no data? In that case, just check for the buffer fill level with Pa_GetStreamReadAvailable before you call Pa_ReadStream and only read as much data as is available.

For echo cancellation (or full-duplex IO in general) I would be inclined to use the callback API as it will typically have more deterministic latency.

The problem in my case is reading from a loopback input will never return if there no sound is playing. same problem in callback mode, no sound playing, no callback calling

RossBencina commented 8 months ago

The problem in my case is reading from a loopback input will never return if there no sound is playing. same problem in callback mode, no sound playing, no callback calling

The behavior that you describe ("never return if there no sound is playing" or "no sound playing, no callback calling") won't happen. If there is no source available either

  1. The host audio stack will feed you silence, or
  2. You won't be able to open or start the stream in the first place.

Neither blocking read nor callback is gated on "sound playing".