Opened 10 years ago

Closed 16 months ago

#3952 closed defect (wontfix)

SWORD2: Core on startup if no audio device

Reported by: SF/lblume Owned by: csnover
Priority: normal Component: Engine: Sword2
Keywords: Cc:
Game: Broken Sword 2


When Broken Sword 2 is started on a Solaris 10 system without an audio device, it cores dump on start.

Other engines start fine (Indy4, Simon).

Setting "No music" and "Subtitles only" still give the same error.

The same binary starts fine on a system with an audio device.

Console output:
$ scummvm
Using configuration file: /home/laurent/.scummvmrc
WARNING: Could not open audio device: No available audio device!
User picked target 'sword2' (gameid 'sword2')...
Looking for a plugin supporting this gameid... Broken Sword 2
Starting 'Broken Sword 2: The Smoking Mirror'
WARNING: Sound initialization failed. This may cause severe problems in some games.!
Exception arithmétique (core dumped)

$ pstack core.scummvm.8080
core 'core.scummvm.8080' of 8080: scummvm
086d7c22 _ZN5Audio17makeRateConverterILb0ELb0EEEPNS_13RateConverterEjj (5622, 0, 0, 0, 30, d0402a44) + 12
0865ceab _ZN5Audio7ChannelC1EPNS_5MixerENS1_9SoundTypeEPNS_11AudioStreamEbbib (8884608, 88847c8, 1, 8b91100, 0, 0) + ab
0865cff0 _ZN5Audio9MixerImpl15playInputStreamENS_5Mixer9SoundTypeEPNS_11SoundHandleEPNS_11AudioStreamEihabbb (88847c8, 1, 8b9110c, 8b91100, ffffffff, ff) + 100 085ab8b6 _ZN6Sword25SoundC1EPNS_12Sword2EngineE (8b91100, 8bb1058, 280, 1e0) + 1a2
085812f4 _ZN6Sword212Sword2Engine4initEv (8bb1058, 4, 8047680, 8866738) + 398
08186a98 ???????? (8868038, 0, 886d800, 8ab93b8)
0818762e scummvm_main (1, 8047a70, 0, 882c7f4, 8047a40, 8695a09) + 616
08184b8a main (1, 8047a70, 8047a78) + 36
08180ba4 _start (1, 8047b64, 0, 8047b6c, 8047b89, 8047ba1) + 80

Ticket imported from: #2099100. Ticket imported from: bugs/3952.

Change History (9)

comment:1 Changed 10 years ago by eriktorbjorn

It seems to crash because the ScummVM mixer tries to create a converter from the sound's sample rate (22050 Hz) to the mixer's sample rate (0 Hz).

I guess it's the mixer that should be made more robust, but I'm too tired to take any closer look tonight anyway. Fingolfin, do you have any thoughts on this?

comment:2 Changed 10 years ago by eriktorbjorn

Owner: set to fingolfin

comment:3 Changed 10 years ago by fingolfin

Priority: normallow

comment:4 Changed 10 years ago by fingolfin

All in all, our support for system without an audio device is rather weak. We have some code in there to cope with it, but it requires adjustments to each specific engine. For example, some engines want to sync audio and video. This causes breakage (e.g. lockups) if audio samples are never consumed, or are consumed instantly (i.e. if we were to fake an audio device by pumping all samples to /dev/null, so to speak).

But of course we should at least exit with an error if running w/o a working audio device does not work, instead of crashing.

comment:5 Changed 9 years ago by fingolfin

This bug is affected by my recent changes to the mixer. It now does not crash anymore due to a zero sample rate. Rather, it now crashes because a QueuingAudioStream is sent to the mixer for playback; the mixer immediately delates it, because no audio playback is possible; but the engine then later tries to queue data into the already deleted stream.

I see two possible options, which can be combined:
1) Extend all backends where setting up audio can fail to set up a "fake audio thread"; then, pretend audio is present, and call the audio mixer callback at regular intervals, only throw away the generated data. This way, most games should run fine even if there is no audio playback, except of course that the user won't hear anything.

2) Games/engines could check during startup whether digital audio is present. If not, they should error out (that is, present a dialog with an explanation to the user, before returning to launcher / exiting). That is, they error out *unless* they are known to work correctly despite the absence of proper audio support.

comment:6 Changed 9 years ago by fingolfin

Priority: lownormal

comment:7 Changed 9 years ago by SF/lblume

From my personal point of view, 1) is better, simply because I sometimes do some basic testing remotely in an audioless VNC session.
However, if 2) is simpler for you, I think it's fine and I can deal with it :-).

comment:8 Changed 8 years ago by fingolfin

Owner: fingolfin deleted

comment:9 Changed 16 months ago by csnover

Owner: set to csnover
Resolution: wontfix
Status: newclosed

In 2017, I think it is fair to say that is no reason to spend effort on trying to make ScummVM work in the absence of audio hardware.

Note: See TracTickets for help on using tickets.