Arx Libertatis Bug Tracker
Please log in to bookmark issues
OPEN  Bug report #136  -  Without an audio-engine conversations speed up
Posted Nov 28, 2011 - updated May 24, 2012   Shortlink:
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
    Not assigned to anyone
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Not determined
  • Resolution
    Not determined
  • Priority
  • Reproducability
    Not determined
  • Severity
  • Targetted for
    icon_milestones.png Not determined
  • OS
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
  • Fixed in
    icon_customdatatype.png Not determined
Issue description
I'm guessing that without the audio-engine loaded and loading samples, the timing can not be loaded from those samples and so a default is applied for the scrolling of the conversation text which tends to be far too fast.

Assuming that is the cause;

One possible fix would be to generate a speed based upon word count if the audio lengths are not present.

A more accurate fix would be to always load sample lengths directly from the samples rather than polling the audio-engine.
Steps to reproduce this issue
Nothing entered.

Comment posted by
 Daniel Scharrer
Dec 01, 00:04
Hm, maybe the cleanest way to do this would be a 'null' audio backend that doesn't actually output anything but updates play status / calls callbacks according to the play time - what do you think?

For this it would probably be enough to not check if the backend is initialized when only loading samples / querying attributes but not actually playing them.
Comment posted by
 Daniel Scharrer
Dec 01, 00:06
The speech code actually queries the sample length directly, but samples don't get loaded if the backend isn't initialized even if it isn't really needed.
Comment posted by
Dec 01, 05:43
i wonder if some of the samples (for example in mp3) may need to be decoded for a time value to be available.

i guess the best way would be a null audio backend. it also isn't a very critical bug though as there shouldn't be too many cases where a backend isn't loaded.

i discovered the issue because the audio driver i installed recently has been doing an infinite loop in kernel when trying to allocate a directsound interface which is used by both openal and the directsound backend. only quick solution was to drop the audio completely.

of course i'll just need to revert to the older driver.
Comment posted by
 Daniel Scharrer
Dec 01, 13:09
All audio samples are stored as WAV files (either RAW or ADPCM) so the sample length is always easily available.