We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4087 - pulseaudio backend keeps buffering while a record stream is paused
Summary: pulseaudio backend keeps buffering while a record stream is paused
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: HG 2.0
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.12
Depends on:
Blocks:
 
Reported: 2018-02-17 00:00 UTC by Mickaël Thomas
Modified: 2020-01-28 16:37 UTC (History)
1 user (show)

See Also:

Attachments
Test case (919 bytes, text/plain)
2018-02-17 00:00 UTC, Mickaël Thomas 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mickaël Thomas 2018-02-17 00:00:43 UTC 
Created attachment 3175 [details]
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
Comment 1 Ryan C. Gordon 2018-02-17 23:37:11 UTC 
This is fixed in https://hg.libsdl.org/SDL/rev/625cdd85edfe, thanks!

--ryan.
Comment 2 Zack Middleton (zturtleman) 2018-05-01 23:44:16 UTC 
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.
Comment 3 Ryan C. Gordon 2019-05-18 18:48:54 UTC 
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.
Comment 4 Sam Lantinga 2019-06-21 17:28:25 UTC 
Let's revisit this after 2.0.10 ships.
Comment 5 Ryan C. Gordon 2019-07-30 17:49:35 UTC 
(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.
Comment 6 Ryan C. Gordon 2019-09-20 20:47:36 UTC 
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.
Comment 7 Ryan C. Gordon 2019-09-20 20:48:39 UTC 
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.
Comment 8 Ryan C. Gordon 2020-01-28 16:37:23 UTC 
Both testaudiocapture and the previously-attached test case are working correctly here on the PulseAudio target.

--ryan.