Closed rakslice closed 3 years ago
While testing in BII in Mac OS 7.6.1 with repeated launches of the stock MoviePlayer 2.5 with a WAV file it can conveniently play back, I found a particular kind of pattern:
This is consistent with sound being left in a good or bad state based on the previous app that played sound (or the initial state when no app has played audio yet), but with a one application run delay in the effect showing up -- i.e. not affecting not the next application run that plays audio, only the one after that.
This is not a new error; in older posted BII Windows builds the error was a "Type 10 Error" rather than "unimplemented trap"
Also happens on Linux, though with different errors, e.g. BII just segfaults
A cursory look at the forums finds a lot of stuff that could be down to this.
In the thread at https://www.emaculation.com/forum/viewtopic.php?t=5286 someone suggests turning on 'platinum' sound effects in Mac OS 9; this generates a lot of little random sound effects on Finder UI actions, which have the side effect of keeping the system away from whatever precondition is the problem
Due to an errant early return, the deinitialization does not complete properly in the case where there was a mixer to close
This is a bug from prehistory https://github.com/rakslice/macemu/blame/3e58028cb14cdcbd2d2798055c1e863ed663e693/BasiliskII/src/audio.cpp#L405
I gave Cockatrice III a heads up because this goes back to BII 0.8 code, but testing their build it doesn't seem to have any effect like this playback crash there.
The first playback of audio in an application after startup works fine, but when I exit and launch the application again, audio playback causes various kinds of fatal error.
I can stop and start and close and reopen the same or different files in the application an unlimited number of times, it's just the playback after the first application launched that played audio has exited that has the problem.
SS: The error takes a variety of forms at random:
BII:
Investigating SS unhandled segfault further in gdb, I find that it's in various delegated calls in
audio.cpp
, not always the same one, but in or soon after theInitOutputDevice
of the second audio session.With
DEBUG
set inaudio.cpp
:Start and first audio session:
...
Then, starting the second session (note the invalid zero mixer value from
OpenMixer()
, though the crash is sometimes before that so it may be a knock-on effect: