[Scummvm-devel] Fwd: [Scummvm-cvs-logs] CVS: scummvm/sound vorbis.cpp,1.12,1.13

Max Horn max at quendi.de
Sun Mar 21 10:21:04 CET 2004


Am 21.03.2004 um 17:59 schrieb Torbj?rn Andersson:

> Update of /cvsroot/scummvm/scummvm/sound
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4000
>
> Modified Files:
> 	vorbis.cpp
> Log Message:
> When I played an Ogg Vorbis-encoded FotAQ I noticed that whenever a 
> sound
> effect happened during a line of speech there was a chance - not a
> certainty - that the speech would get cut off prematurely.
>
> As far as I can tell, this is because the Vorbis decoder isn't the 
> only one
> who's accessing the same file. Now the Vorbis decoder will explicitly 
> seek
> to the position where it expects the file to be at before reading from 
> it.
> I hope this is the correct fix. It does fix the problem for me, at 
> least.
>
> I don't know if any of the other decoders needs a similar patch. I 
> couldn't
> reproduce the problem with my MP3-encoded FotAQ, but there are other
> possible explanations for that, e.g. the bug gets harder to trigger the
> more sound data that is decoded in each pass.
>
Hm, that's a serious problem then. The change you fixed in will cure 
the symptoms in most cases, but there is still a possibility for 
problems.

Essentially, if two threads (the sound thread and the main thread) 
access the same file, it's possible that e.g. the sound thread seeks, 
then the main thread gets its time slice, and also seeks/reads from the 
file. Then when we are back in the sound thread, the problem is back.

The only way to fully resolve that would be to use a mutex there, I am 
afraid... Maybe we should add lock()/unlock() methods to class File 
<sigh>


Bye,

Max





More information about the Scummvm-devel mailing list