Bug 1956 – Windows: MME and WDS playback cursor is buffer length ahead of actual audio playing

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 1956 - Windows: MME and WDS playback cursor is buffer length ahead of actual audio playing


Summary:	Windows: MME and WDS playback cursor is buffer length ahead of actual audio p...

Status:	NEW

Product:	Audacity
Classification:	Unclassified
Component:	Audio IO
Version:	2.3.0
Hardware:	PC Windows (all)

Importance:	P4 Repeatable
Assigned To:	Paul L

URL:
Keywords:

Duplicates:	1959 (view as bug list)
Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2018-08-29 11:52 UTC by Peter Sampson
Modified:	2021-09-24 17:48 UTC (History)
CC List:	4 users (show)

See Also:	1959
Steps To Reproduce:	1. Set the latency buffer length to 1000ms 2. Set Audio host to MME or WDS 3. Record a few seconds of audio. 4. Play the recording back 5) Observe: The playback cursor is 1 second (i.e. buffer length) ahead of actual audio being played back.
Release Note:
First Git SHA:
Group:	---
Workaround:
Closed:

Flags:	petersampsonaudacity: Regression-

Attachments
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 Peter Sampson 2018-08-29 11:52:45 UTC

With MME and WDS the whole audio or selection is played and starting after a delay of 1 second (the buffer length) and the playback cursor is out of sync with the playback by 1 second (buffer length).

WASAPI is not affected (we fixed Bug #1949 ) - nor is Mac affected.

This is not a regression on 2.2.2 or on 2.1.3

Comment 1 James Crook 2018-08-30 07:24:13 UTC

Demoted to P2, since most users will have 100ms as their buffer size AND this is not a regression on 2.2.2.  Bug assigned to Paul.

The delay in starting playback should be split off as a separate bug.  Buffers can/should be primed as quickly as we can.

This bug 1956 can remain for the behaviour that the play head is shown for 'buffer loading time' not 'buffer utilisation time'.  Users expect the play head to track what is actually playing right now.

Comment 2 James Crook 2018-08-30 09:58:13 UTC

*** STEPS UPDATED ***
And title changed.  I've split bug 1959 (slow priming of buffers) out of this bug, as it has a different root cause.

Comment 3 James Crook 2018-08-30 10:11:24 UTC

Demoted to P5.  The latency is communicated to portaudio, and it is portaudio that does buffering in that case.

Comment 4 Peter Sampson 2020-12-21 08:26:44 UTC

*** Bug 1959 has been marked as a duplicate of this bug. ***