Opened 15 years ago
Closed 6 years ago
#3952 closed defect (wontfix)
SWORD2: Core on startup if no audio device
|Reported by:||SF/lblume||Owned by:||csnover|
|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)
Stack: $ 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 by , 15 years ago
comment:2 by , 15 years ago
comment:3 by , 15 years ago
|Priority:||normal → low|
comment:4 by , 15 years ago
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 by , 13 years ago
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 by , 13 years ago
|Priority:||low → normal|
comment:7 by , 13 years ago
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 by , 12 years ago
comment:9 by , 6 years ago
|Status:||new → closed|
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.
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?