Project

General

Profile

Actions

Emulator Issues #12951

closed

Gamecube audio dumping desyncs from video over time

Added by AdmiralCurtiss almost 2 years ago. Updated over 1 year ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:
5.0-16788

Description

This has been known for a while but I guess no one made a ticket for it?

I believe this started happening with https://github.com/dolphin-emu/dolphin/pull/6040 but it could be newer than that. It's definitely related to the nonstandard GC audio sample rate at least.

It has been suggested that this is an integer rounding issue, where the actual sample rate of 54000000/1124 (for 48khz) is not properly represented by our integer timing values. That seems plausible, but requires a bit of refactoring to prove.
https://cdn.discordapp.com/attachments/822820107788746812/986072704186712125/unknown.png


Related issues 1 (0 open1 closed)

Has duplicate Emulator - Emulator Issues #12647: Sound encode and frames encode are not at the same speedDuplicate

Actions
Actions #1

Updated by CasualPokePlayer almost 2 years ago

It has been suggested that this is an integer rounding issue, where the actual sample rate of 54000000/1124 (for 48khz) is not properly represented by our integer timing values.

This is correct-ish. The issue here is that by rounding off 54000000 / 1124 (48khz) and 54000000 / 1124 / 1.5 (32khz) to integer values (48043hz and 32029hz) instead of their proper values, you end up getting an uneven number of cycles per sample.

https://github.com/dolphin-emu/dolphin/blob/d32b13fb36e6616f7bb4a5a395c34ae2f2ada32b/Source/Core/Core/HW/SystemTimers.cpp#L113
This is the relevant timing code. It expects a constant number of cycles per sample, doing math with the CPU clock rate and such to figure that out. The divisions do not divide evenly, causing rounding errors and the actual output sample rate to be around 32024.2hz/48061.7hz.

Using the correct sample rates would be the optimal solution. This would be accurate to hardware and have a nice clean cycles per sample. Audio mixing code and audio dumping code would only need to be reworked to handle the non-integer sample rate. Audio mixing code actually seems to use floats anyways for resampling (https://github.com/dolphin-emu/dolphin/blob/f96e91119accffe1bed892a6419580cffbcec099/Source/Core/AudioCommon/Mixer.cpp#L97), so not much change there. Audio dumping code is more problematic, as wav doesn't seem to support non-integer sample rates. That would need to be reworked into another format that supports such. Or alternatively, the audio could be resampled to a clean integer sample rate (and maybe at that point mix dsp and dtk together into one wav file and avoid splits altogether).

Actions #2

Updated by JosJuice almost 2 years ago

  • Status changed from New to Fix pending
Actions #3

Updated by JMC4789 over 1 year ago

Actions #4

Updated by ZephyrSurfer over 1 year ago

The above pull request was merged in the following version, however I have not tested this fix.

5.0-16788 -> https://dolphin-emu.org/download/dev/de3d1344d5ed939faedae9c19e2e340a83038aba/

Actions #5

Updated by pokechu22 over 1 year ago

  • Status changed from Fix pending to Fixed
  • Fixed in set to 5.0-16788
Actions #6

Updated by JosJuice over 1 year ago

Technically it's not entirely fixed, but it's going to be difficult to get it better without resampling the audio.

Actions

Also available in: Atom PDF