 |
It seems that "sound" keyword no longer uses the actual sound data. The real sound is played by OpenAL. The material depends on the amplitude data which is fetched in CPU mixing loop. They are somewhat separate now... When you load the mission from scratch, global sound time starts counting immediately. When the mission is loaded and you see "Press attack", sound decoding starts, but not from the beginning of the sound sample, but from the middle. Perhaps it starts from the moment (global_sound_time modulo sample_length)... You can see where sound sample decoding is by enabling com_showSoundDecoders. However, the sound itself is played by OpenAL, and it starts playing from the beginning of the sample when "Press attack" screen appears. So it is not synchronized. I wonder if the problem is present in two slightly different cases: 1. Sound sample is non-looping. 2. Sound is enabled only when player hits a button. |
|
|
One more thing. It would be great if someone can test 2.05 version with OpenAL enabled. |
|
|
Ok, I just checked, and here are two interesting facts. 1. The sound DOES play before you "click attack to start" in both 2.05, 2.06 beta, and SVN. Be sure to wait at least 30 seconds if you check it. 2. The issue is perfectly reproduced on 2.05 if you enable OpenAL ("s_useOpenAL 1"), but is not reproducible without OpenAL. In 2.06 beta or SVN we have OpenAL always enabled. So this is not a code regression, it is not that we broke something in 2.06. It is an inherent problem of the original Doom3 code for the OpenAL case. The difference is: No OpenAL: the sound starts playing from its middle, just as it should according to current sound time and channel trigger time With OpenAL: the sounds starts playing from the beginning, which is not correct, since the offset from channel trigger time and current sound time is not zero when sound starts. |
 |
"In 2.06 beta or SVN we have OpenAL always enabled." Do you know why that change was made? |
|
|
The change came from x64 branch with a set of changes from dhewm3. It was done in dhewm3 to remove all OS-specific backends for better platform independence. Also, it may be related to EFX support, although I cannot be sure here. |
|
|
Looking at idSoundWorldLocal::AddChannelContribution... There is an "if": if ( sound->removeStatus < REMOVE_STATUS_SAMPLEFINISHED ) Strangely, inside this if properly calculated offset is never used. And there is also an "else" for it, which happens when removeStatus = REMOVE_STATUS_SAMPLEFINISHED. However, it never happens now. It uses properly calculated offset and it calls some things which are clearly necessary only when OpenAL is NOT used. So I guess that this case is actually for non-OpenAL playback and it is dead now. |
|
|
Supposedly fixed in revision 7361 (binaries available in 15129). Please check that it works now. This change may potentially break some other stuff: in particular, how sounds are synchronized with anything else. This is especially true for ambients, I suppose. BTW, Is this sound keyword used in any real map? |
|
|
The keyword is used in all the flickering electric light entities. I'll test the fix. |
|
|
The fix appears to be working from my preliminary test of the testmap. My build is crashing for other reasons so I wasn't able to do a full test. |
|
|
Is there ANY real FM where synchronization between a sound and a material connected to it is crucial? I know that test map works, but I think it's better to check on at least one real FM. On the other hand, I think the issue happens only when the sound in question starts immediately at the beginning of the FM. So it is very unlikely to find any real-world case where issue happens on current 2.06 beta. |
|
|
As I said, any map using the humming electric light entities will be using this, though it's unlikely players would notice if the flickering of the light wasn't synced with the humming sound, so not really crucial. I don't know if any maps have used it in other ways--there's no way to know that without looking at the pk4 or asking mappers directly. |
- Anonymous
