I think what happens here is simply that there are a limited number of voices available. The sound of rushing water has a low priority, so when something with a higher priority comes along, it gets evicted. If I comment out the priority check (definitely not the right way of fixing it) from MidiDriver_ADLIB::allocate_voice(), the rushing water sound continued indefinitely.
There could of course be a bug in the way it handles priorities, but it might also be that we're simply running into the limitations of AdLib itself. (Random idea: Right now, we use one FM_OPL object to generate the samples. What would happen if we used two, and split the voices fairly between them? Though even if it works, it sounds too invasive for this release.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the comments in bug report #728417 ("MI2: Waterfall-sound stop playing") the problem happens with the original interpreter as well, so I guess ScummVM does handle priorities correctly. Or at least close enough.
(I still like the idea of trying to get two emulated sound cards working in parallel though, so I might experiment with that. From what I remember, there are cases where notes get cut off noticeably when the music gets complicated, probably for the very same reason, and this might help.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This bug is nice to get fixed before the release. Raising priority for keeping the track.
I think what happens here is simply that there are a limited number of voices available. The sound of rushing water has a low priority, so when something with a higher priority comes along, it gets evicted. If I comment out the priority check (definitely not the right way of fixing it) from MidiDriver_ADLIB::allocate_voice(), the rushing water sound continued indefinitely.
There could of course be a bug in the way it handles priorities, but it might also be that we're simply running into the limitations of AdLib itself. (Random idea: Right now, we use one FM_OPL object to generate the samples. What would happen if we used two, and split the voices fairly between them? Though even if it works, it sounds too invasive for this release.)
According to the comments in bug report #728417 ("MI2: Waterfall-sound stop playing") the problem happens with the original interpreter as well, so I guess ScummVM does handle priorities correctly. Or at least close enough.
(I still like the idea of trying to get two emulated sound cards working in parallel though, so I might experiment with that. From what I remember, there are cases where notes get cut off noticeably when the music gets complicated, probably for the very same reason, and this might help.)
Since it's reported to happen in the original interpreter too, it's no longer a priority for 1.0.0.