search

Scirra / Construct-bugs

Public bug report submissions for Construct 3 and Construct Animate. Please read the guidelines then click the 'Issues' tab to get started.
https://www.construct.net
104 stars 83 forks source link

Audio "PlaybackTime" does not slow down when changing "PlaybackRate" #4877

Closed Jase0000 closed 3 years ago

Jase0000 commented 3 years ago

Problem description

When playing a sound, if you observe the "PlaybackTime" value for a sound, it will give you the correct value.

However, if you change the "PlaybackRate", lets say to 0.5, then the "PlaybackTime" does not increase slowly to match the playback rate. If you wait long enough, the "PlaybackTime" value will freeze, even though the sound continues to play, so you cannot know how far along the sound you are.

Attach a .c3p

https://drive.google.com/open?id=18apRamrA5cd-iCOxNF3hvveB3zKLN9UX

Steps to reproduce

  1. Click the "Play at 1x" button to hear the regular sound file of a piano.
  2. Click the "Play at 0.5x" button and observe the "Current PlaybackTime:" in the text.
  3. After a few seconds, you will see the "Current PlaybackTime" will match the "Duration" and no longer increase, but you can still hear the sound playing.

Observed result

"Audio.PlaybackTime()" stops increasing, even though the sound is still playing.

Expected result

Either: "Audio.PlaybackTime()" should be increasing slower when using 0.5x playback rate. (Best outcome) Or "Audio.PlaybackTime()" should continue increasing beyond "Audio.Duration()". (A workaround could be made with this outcome at least)

More details

There's other issues that I've seen appear from this not occurring, such as using "Pause" and "Resume" on a 0.5x playback rate causes the "PlaybackTime" to jump to a different value whilst paused, then back to a different value when resuming, along with "Seek To" being strange when having a different PlaybackRate. I was able to workaround these, but this bug I am reporting is impossible to workaround.

When creating a Rhythm game (E.g. arrows like DDR), linking the arrow Y position with Audio.PlaybackTime is the most accurate method. If you make a workaround variable that adds DT constantly and position the DDR arrow's Y position to this variable, then due to how DT can have minor inaccuracies, the variable will fall out of sync the longer the song plays, causing the "DDR arrows" to be de-synced with the actual audio we can hear.

Dynamic playback-rate shifting is key in my project too, so I cannot bake this in to the sound files. It's working 100% the way I require, but the PlaybackTime is impossible to workaround without causing inaccuracies.

I worry that this might be a "If we fix this, it might negatively affect existing projects for others", which I respect, but I strongly feel that logically the "PlaybackTime" should follow the slowdown/speedup of the PlaybackRate. I also would suspect not many people use the "PlaybackRate" option often, and also if they were, then they too would be confused as to why their slowed-down sounds can't be tracked beyond a certain point with PlaybackTime.

Another "workaround" that would be absolutely great is if the "PlaybackTime" could continue beyond the "Duration" value, instead of freezing when it reaches the Duration value - at least then I can still use the "Audio.PlaybackTime" variable to sync in my Rhythm project.

Many thanks for checking this out.

Affected browsers/platforms: Chrome, NWJS

r250

System details

View details Platform information Browser: NW.js Browser version: 0.54.0 Browser engine: Chromium Context: nwjs Operating system: Windows Operating system version: 10 Device type: desktop Device pixel ratio: 1 Logical CPU cores: 12 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (@62f83a7521ae1f32e563795732dff0c9da1b660d) NWjs/0.54.0 (like Chrome/91.0.4472.77) C3 release: r250 (beta) Language setting: en-US Local storage Storage quota (approx): 49 gb Storage usage (approx): 450 mb (0.9%) Persistant storage: Yes Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported. Nothing is missing. Everything is OK! WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: yes Supports highp precision: yes Vendor: Google Inc. (NVIDIA) Renderer: ANGLE (NVIDIA, NVIDIA GeForce RTX 2060 Direct3D11 vs_5_0 ps_5_0, D3D11-27.21.14.6156) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions: EXT_color_buffer_float EXT_color_buffer_half_float EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_texture_filter_anisotropic EXT_texture_norm16 KHR_parallel_shader_compile OES_texture_float_linear WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context WEBGL_multi_draw OVR_multiview2 Audio information System sample rate: 48000 Hz Output channels: 2 Output interpretation: speakers Supported decode formats: WebM Opus (audio/webm; codecs=opus) Ogg Opus (audio/ogg; codecs=opus) WebM Vorbis (audio/webm; codecs=vorbis) Ogg Vorbis (audio/ogg; codecs=vorbis) MPEG-4 AAC (audio/mp4; codecs=mp4a.40.5) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav; codecs=1) Supported encode formats: WebM Opus (audio/webm; codecs=opus) Video information Supported decode formats: WebM AV1 (video/webm; codecs=av01.0.00M.08) MP4 AV1 (video/mp4; codecs=av01.0.00M.08) WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8) Ogg Theora (video/ogg; codecs=theora) H.264 (video/mp4; codecs=avc1.42E01E) Supported encode formats: WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8)
Jase0000 commented 3 years ago

I am so very blind, I didn't see this was already reported! : #4867

AshleyScirra commented 3 years ago

Closing as duplicate of #4867.