Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pulseaudio backend keeps buffering while a record stream is paused #2829

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2018-02-17 00:00:43 +0000, Mickaël Thomas wrote:

Created attachment 3175
Test case

Quoting SDL_DequeueAudio doc:

Capture devices will not queue data when paused; if you are expecting
to not need captured audio for some length of time, use
SDL_PauseAudioDevice() to stop the capture device from queueing more
data. This can be useful during, say, level loading times. When
unpaused, capture devices will start queueing data from that point,
having flushed any capturable data available while paused."

When using the pulseaudio backend, this is not what happens.

The recorded data continues to be queued in pulseaudio buffers while the stream is paused, leading to a huge latency in the stream (the time during which the stream was paused).

This is probably related to this pulseaudio issue: https://bugs.freedesktop.org/show_bug.cgi?id=48879

On 2018-02-17 23:37:11 +0000, Ryan C. Gordon wrote:

This is fixed in https://hg.libsdl.org/SDL/rev/625cdd85edfe, thanks!

--ryan.

On 2018-05-01 23:44:16 +0000, Zack Middleton (zturtleman) wrote:

This seems to still be an issue using the latest code from HG. After unpausing the Pulseaudio capture device, the audio from while the capture device was paused is added to the queue accessible through SDL_DequeueAudio().

Using SDL's testaudiocapture (Pulseaudio, Debian GNU/Linux 8 x86_64):

  1. Start testaudiocapture
  2. Speak
  3. Click window to start recording
  4. Release mouse button to stop recording
  5. Audio from before clicking window and while clicking window is played back
  6. Steps 2-5 can be repeated

Expected result: Only the audio recorded while clicking window to be played back.

On 2019-05-18 18:48:54 +0000, Ryan C. Gordon wrote:

Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release.

Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon.

If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks.

Thanks!

--ryan.

On 2019-06-21 17:28:25 +0000, Sam Lantinga wrote:

Let's revisit this after 2.0.10 ships.

On 2019-07-30 17:49:35 +0000, Ryan C. Gordon wrote:

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

On 2019-09-20 20:47:36 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-09-20 20:48:39 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2020-01-28 16:37:23 +0000, Ryan C. Gordon wrote:

Both testaudiocapture and the previously-attached test case are working correctly here on the PulseAudio target.

--ryan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant