View Issue Details

IDProjectCategoryView StatusLast Update
0000837OpenMPTGeneralpublic2016-07-31 14:49
ReporterSaga Musix Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product VersionOpenMPT / libopenmpt 0.2-beta18 (upgrade first) 
Target VersionOpenMPT 1.?? (long term goals) 
Summary0000837: 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.

TagsNo tags attached.
Has the bug occurred in previous versions?Yes
Tested code revision (in case you know it)




2016-07-31 14:49

administrator   ~0002532

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.
Generally not Stop()ing and Start()ing the sound device when switching between different CSoundFile would solve this particular problem, but introduce another one: timing.
The sample-exact playback and render position must be known to various other components (in particular GUI rerawing and VST plugins). When hot-switching CSoundFile while the playback is running, we cannot know upfront the sample-exact timecode of the switch-over which would be needed in order to compensate for that. The information is of course theoretically available, but only in the audio thread itself, and cannot easily (i.e. race-free and deadlock-free) be transferred to the main thread in that particular code path (at least I currently cannot see how, without the addition of another synchronization mechanism, which would be more of a hack than a proper solution).

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.

Issue History

Date Modified Username Field Change
2016-07-30 22:58 Saga Musix New Issue
2016-07-31 14:49 manx Note Added: 0002532
2016-07-31 14:49 manx Target Version => OpenMPT 1.?? (long term goals)