View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000837||OpenMPT||General||public||2016-07-30 22:58||2016-07-31 14:49|
|Reporter||Saga Musix||Assigned To|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||OpenMPT 1.26.03.00 / libopenmpt 0.2-beta18 (upgrade first)|
|Target Version||OpenMPT 1.?? (long term goals)|
|Summary||0000837: Do not reset sound device when changing previewed file/note|
When refactoring/enhancing the sound device handling, the behaviour when playing a new preview note from the tree view was changed for simplicity's sake: Previously the sound device was kept open, but now it is reset with every note change. This can lead to audible and annoying drops and clicks with some audio device, e.g. Wave Out. The audio driver should really stay open if it's already open.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Yes|
|Tested code revision (in case you know it)|
This will be more difficult than it looks on the surface.
Both previews and actual modules are handled identically with respect to deciding whether to Stop() and Start() the sound device. This is done in order to keep things consistent and easy (or easier) to understand. After all, we are still seeing occasional race conditions related to these code paths (albeit way fewer than in the past). Adding a special case for sample preview would complicate things again here.
The issue is not unsolvable of course. However, I do think it would be better delayed until further decoupling work has been done, which would untie the timing and sample position of a particular module from the one of the playing sound device.
Another layer, let's call it PlaybackManager, which sits between CMainFrame and gpSoundDevice is what I have in mind here. I had already tried implementing this twice, but the code always ended up being even more complicated than it already is, so I ditched it again.