Sound delay in DOTT and Fate of Atlantis

Subforum for discussion and help with ScummVM's PocketPC/HandheldPC port

Moderator: ScummVM Team

User avatar
knakos
ScummVM Porter
Posts: 424
Joined: Wed Nov 02, 2005 2:35 pm
Location: Athens, Greece

Post by knakos » Thu Mar 06, 2008 11:25 am

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).

japher
Posts: 5
Joined: Wed Mar 05, 2008 8:57 pm

Post by japher » Fri Mar 14, 2008 5:41 pm

knakos wrote:By default, the sound mixing has priority over the graphics so I would expect the opposite effect from what you all describe.
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:I am assuming that by using exactly the same files on the PC version you have no sound delay.
Yep :P
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). :P
I'll try compressing in all different formats & bitrates and report my results back here. This might shed some light on the problem.

Interestingly, both TheVaultDweller and I are using a HTC TyTN II (Kaiser). Maybe this is specific to our hardware (or Windows ROM?).

Wodball
Posts: 1
Joined: Fri Mar 07, 2008 9:05 pm

Post by Wodball » Sat Mar 15, 2008 1:22 am

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.

japher
Posts: 5
Joined: Wed Mar 05, 2008 8:57 pm

Post by japher » Mon Mar 17, 2008 6:54 pm

Same issue, different hardware & software environment, way back in scummvm 0.8.2:
viewtopic.php?t=1380

Maybe it's time to raise a bug against the wince port?

japher
Posts: 5
Joined: Wed Mar 05, 2008 8:57 pm

Post by japher » Mon Mar 17, 2008 6:58 pm

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?

User avatar
knakos
ScummVM Porter
Posts: 424
Joined: Wed Nov 02, 2005 2:35 pm
Location: Athens, Greece

Post by knakos » Tue Mar 18, 2008 8:15 am

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.

japher
Posts: 5
Joined: Wed Mar 05, 2008 8:57 pm

Post by japher » Thu Mar 20, 2008 11:22 am

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

Post Reply