By default, the sound mixing has priority over the graphics so I would expect the opposite effect from what you all describe. It needless to say I have not observed the delay you have.
This is tricky.
I am assuming that by using exactly the same files on the PC version you have no sound delay.
Have you compressed mp3 with a VBR (variable bitrate) setting? This is known to incur slowdown during seeking the track. You can try compressing in CBR (constant bitrate) and possibly setting a low bit rate (like ~64Kbps). Also try perhaps an ogg compression (or flac if you're feeling adventurous).
Sound delay in DOTT and Fate of Atlantis
Moderator: ScummVM Team
Makes sense. For this reason and the fact that I tried the sound_thread_priority=0 trick with no joy, I don't think this has anything to do with a lack of processing power (i.e. the CPU load being too high).knakos wrote:By default, the sound mixing has priority over the graphics so I would expect the opposite effect from what you all describe.
Yepknakos wrote:I am assuming that by using exactly the same files on the PC version you have no sound delay.
I'll try compressing in all different formats & bitrates and report my results back here. This might shed some light on the problem.knakos wrote:Have you compressed mp3 with a VBR (variable bitrate) setting? This is known to incur slowdown during seeking the track. You can try compressing in CBR (constant bitrate) and possibly setting a low bit rate (like ~64Kbps). Also try perhaps an ogg compression (or flac if you're feeling adventurous).
Interestingly, both TheVaultDweller and I are using a HTC TyTN II (Kaiser). Maybe this is specific to our hardware (or Windows ROM?).
Well, I have this same problem too, but my machine is an X51V. My test is usually the breaking of the window during the Fate of Atlantis intro, which is usually delayed by about half a second.
I usually use Ogg (I don't remember the quality setting that I used) for my file compression and also tested a 48kbps CBR Mp3 compressed monster.sou a few months ago. Both had the same delay.
I was thinking that it could be a RAM problem, as the X51V has a paltry 64MB and WM5 sucks up over half of it.
Since knakos said that the sound has priority in loading, I was wondering if there could be a setting for an audio/video offset, where we can set the sound events to go off 500ms before they are expected to. I mean... if you decide to watch Youtube on a PDA like the X51V, you need to push the sound back by around 400ms in order to sync the A/V. I was thinking that a similar solution could be done here...
The other wild thought was maybe the onboard sound is just slow and it's just something that we'll have to live with.
I usually use Ogg (I don't remember the quality setting that I used) for my file compression and also tested a 48kbps CBR Mp3 compressed monster.sou a few months ago. Both had the same delay.
I was thinking that it could be a RAM problem, as the X51V has a paltry 64MB and WM5 sucks up over half of it.
Since knakos said that the sound has priority in loading, I was wondering if there could be a setting for an audio/video offset, where we can set the sound events to go off 500ms before they are expected to. I mean... if you decide to watch Youtube on a PDA like the X51V, you need to push the sound back by around 400ms in order to sync the A/V. I was thinking that a similar solution could be done here...
The other wild thought was maybe the onboard sound is just slow and it's just something that we'll have to live with.
Same issue, different hardware & software environment, way back in scummvm 0.8.2:
http://forums.scummvm.org/viewtopic.php?t=1380
Maybe it's time to raise a bug against the wince port?
http://forums.scummvm.org/viewtopic.php?t=1380
Maybe it's time to raise a bug against the wince port?
As promised, I've done testing with different codecs and this problem remains identical when using uncompressed, mp3, ogg and flac audio.
I'm thinking this is a buffering/latency problem with the hardware and/or sound driver. Maybe the only fix will be a configurable offset which can be used to cue up audio events earlier than usual (as suggested by Wodball).
knakos: can you think of any more information I can gather that would help here? debug output? further testing scenarios?
I'm thinking this is a buffering/latency problem with the hardware and/or sound driver. Maybe the only fix will be a configurable offset which can be used to cue up audio events earlier than usual (as suggested by Wodball).
knakos: can you think of any more information I can gather that would help here? debug output? further testing scenarios?
Yes, a bug report would be appropriate. With respect to 0.8.2, yes it could be the same problem although on that specific post, I tied the lag to cpu (and code) inefficiency. This could be a different thing, or then again not 
Thanks for the feedback so far, I can think of anything else right now. We'll have to try a few builds to see what's going on (be sure to cite this thread on the bug report). Altough I warn you, I won't be dealing with scummvm code for a couple of weeks more due to heavy workload, OK?
K.
Thanks for the feedback so far, I can think of anything else right now. We'll have to try a few builds to see what's going on (be sure to cite this thread on the bug report). Altough I warn you, I won't be dealing with scummvm code for a couple of weeks more due to heavy workload, OK?
K.
Thanks Knakos! I've opened the bug (and I see you've taken assignment already).
For anyone else interested, this is being tracked here:
http://sourceforge.net/tracker/index.ph ... tid=418820
For anyone else interested, this is being tracked here:
http://sourceforge.net/tracker/index.ph ... tid=418820