[Scummvm-devel] Symbian, files and audio code

[Max Horn]

Hi,

with my recent overhaul of the AudioStreams code, I likely (and somewhat
deliberately) broke the Symbian port. It used to scatter #ifdefs
throughout the code of the AudioStreams dealing with (re)opening file
handles constantly. Apparently, this is necessary on Symbian as file
handles can only be used within the thread that created them; but usually
we create audio streams (and their associated file handles, if any) in the
main thread, while reading from them in the mixer thread.
Besides that, we used to have problems because we were reading from files
in two different threads, which would lead to race conditions. This latter
problem should be gone now, since we replaced (most?) of these occurances
by code which first reads the relevants parts of the files into a memory
buffer before passing this buffer to the audio code.

The only cases where we still let an AudioStream read directly from a file
is when the AudioStream has exclusive access to that file, e.g. when
playing a .flac/.ogg/.mp3 file (such as an audio track). But in this case,
the file handle ownership issue remains.

I am unwilling to add Symbian #ifdefs to our AudioStream code again.
Besides being harder to implement now (since the AudioStreams are never
seeing File objects directly anymore, but rather SeekableReadStreams),
it's also prone to breakage the next time somebody needs to change the
AudioStream code, and it extends badly to new audio code.

So, we need a better solution. One idea would be to add a virtual reopen()
method to ReadStream or SeekableReadstream, which by default would do
nothing. Only for class File, and only on Symbian, would it reopen the
file.  This extends well to other hypothetical streams suffering from
thread ownership problems, and to other platforms which have the same
problem as Symbian. The main issue with implementing that, though, is how
to keep track of the seek position w/o incurring too much overhead...

Another idea would be to create the file handles in the correct thread, by
adding code to the Mixer (or using a fake AudioStream for this purpose)
which instantiates the AudioStreams and the file handles they use in the
mixer thread. The gory details could be hidden inside the stream factory
functions.

I am not quite happy with either approach, though. While I have various
other ideas on how to tackle this floating in my mind, so far all seem to
be worse. At least judging by the impact they would have on client code
(I'd prefer to hide these complications from engine authors, as opposed to
forcing them to learn how to tip toe around these issues). Hence
alternative suggestions are highly welcome, esp. from the Symbian folks
who are most affected by this, after all :-).


Cheers,
Max