You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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):
Start testaudiocapture
Speak
Click window to start recording
Release mouse button to stop recording
Audio from before clicking window and while clicking window is played back
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.
The text was updated successfully, but these errors were encountered:
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:
On 2018-02-17 23:37:11 +0000, Ryan C. Gordon wrote:
On 2018-05-01 23:44:16 +0000, Zack Middleton (zturtleman) wrote:
On 2019-05-18 18:48:54 +0000, Ryan C. Gordon wrote:
On 2019-06-21 17:28:25 +0000, Sam Lantinga wrote:
On 2019-07-30 17:49:35 +0000, Ryan C. Gordon wrote:
On 2019-09-20 20:47:36 +0000, Ryan C. Gordon wrote:
On 2019-09-20 20:48:39 +0000, Ryan C. Gordon wrote:
On 2020-01-28 16:37:23 +0000, Ryan C. Gordon wrote:
The text was updated successfully, but these errors were encountered: