Opened 16 years ago
Closed 16 years ago
#4181 closed defect (fixed)
BS2: noise in music or speech
| Reported by: | criezy | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Sword2 |
| Version: | Keywords: | ||
| Cc: | Game: | Broken Sword 2 |
Description
When playing BS2, sometime a high level of noise appears when a character start to speak. We can just make out the speech behind the noise. It seems to always happen when some music is playing and I don't know if the noise is related to speech or music. It happened in two locations so far (in the house at the very beginning and in Marseille) and I can't reproduce it. The noise continue after the character stop to speak, but stop if I press F5. I tried to reproduce it in Marseille by playing the same piece about 10 times with a save game but didn't succeed, although I triggered the issue once a bit latter in the game (still in Marseille).
It seems related to the following warning, but I am not sure of it: WARNING: Expected 4096 samples, but got 614!
I couldn't see apparent cause to it. Once it happened soon after I started to play an the two other times it happened after about 30 minutes of play.
ScummVM 0.13.0 branch from February 14. MacOS X, all audio settings to default.
Also I played the game with the same files previously (the last time was with version 0.11.1 I think) and didn't see that problem. The files have been sitting on my hard disk since then (they might have got corrupted while sitting there, but I hope not). I don't completely exclude a corruption of my data files (uncompressed by the way), but the fact it seems to happen randomly to me and in different places seems to indicate a bug.
Sorry for not being more precise. I am continuing to play the game and I will pay attention to this issue to see if I can get more info.
Ticket imported from: #2614306. Ticket imported from: bugs/4181.
Change History (10)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
I just did get some strange music bug (but no warning messages.) in the music myself. I haven't been able to reproduce it, though.
comment:3 by , 16 years ago
Hmm... I see that someone (lavosspawn?) decided to unlock the music briefly in Sound::streamCompMusic(). That may not be entirely safe...
comment:4 by , 16 years ago
I've changed it so that the mutex is now once again locked throughout the entire Sound::streamCompMusic() function. That change was apparently made because loading a compressed song (MP3, FLAC or Ogg Vorbis) took too long on some platforms. I've rewritten the loading so that it should be as cheap as opening songs from the uncompressed music files.
However, that change is pretty experimental so it probably won't go into 0.13.
If this was the bug you were experiencing, it should have been in 0.11.1 as well, so I don't dare to close the bug just yet. On the other hand, thread-related bugs are notoriously hard to trigger, so I'm still hopeful.
comment:5 by , 16 years ago
| Owner: | set to |
|---|
comment:6 by , 16 years ago
Concerning 0.11.1 it is possible that it happened once and that I don't remember. This time it was only after getting it two times in two days that I though there was probably a bug. And I had to work hard to trigger it a third time. Anyway I grabbed a 0.11.1 version on sourceforge today and replayed the game. After playing for a while I reproduced the problem (and I can confirm I got the exact same warning: "WARNING: Expected 4096 samples, but got 614!" - it is much easier to see without all these FSNode warnings).
I have just recompiled a version from SVN trunk with your commit. I will play with that version and report back.
comment:7 by , 16 years ago
Two more weeks playing the game with 0.14.0svn and I didn't reproduce the bug. It looks like your change fixed it. I didn't notice any side effect either.
comment:8 by , 16 years ago
Thanks, that's good to know. I should probably backport the fix to the 0.13 branch, but first I should take some time to make sure I didn't accidentally break the support for compressed music. I'll keep the bug report open for now, as a reminder.
comment:9 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:10 by , 16 years ago
I've played through the entire game on the 0.13 branch, with this bugfix applied to it, and I didn't encounter the bug. I guess that means it almost certainly is fixed, and that it's ok for 0.13.1.
I'm afraid I don't know what went wrong here.
Unless I'm completely off base, the warning means that it has reached the end of the sound it's decoding, but still thinks there are samples left to decode. Since the compression rate is constant - after the first two bytes, each byte of compressed data produces two bytes (one sample) of uncompressed data - the only possibilities I can think of are:
1) You really have reached the end of the file. Unlikely. That should be *very* reproducable.
2) Somewhere along the line the information about remaining number of samples to decode and remaining number of samples get out of sync. That doesn't seem likely either, at least not on its own. It doesn't explain the noises you mention.
3) For whatever reason, the player has skipped ahead in the file. That shouldn't be possible. It moves to the desired position, fills the buffer, and makes a note of the new position. What could go wrong?
4) For whatever reason, it doesn't decode all the data in the buffer it has read, before reading the next chunk. That would explain the noises, and it would probably lead to the warning you mention. But why would that happen?
A thread issue? I thought I had fixed that...