I have no idea what's going wrong here. I added code that might aid debugging this to the current test versions.
The code is, however, disabled by default because it causes significant increase in memory consumption (about 30MB). Performance will not suffer in any measurable way.
Can you please grab a current test build (at least 1.24.01.03-r4685) and set the following settings (in the advanced settings tab):
Debug.TraceEnable=1
Debug.StopSoundDeviceOnCrash=0
You need to restart OpenMPT for the debug settings to take effect.
From now on, OpenMPT will, in case of a crash, additionally write a trace.log to the crash output directory.
When the crash happens again, please provide the trace.log in addition to the crash.dmp. This might help to further diagnose the problem.

https://dl.dropboxusercontent.com/u/16644842/mpt/2015-01-01%2000.40.31.zip
Caught fucker.

Has the error message displayed in the last crash you posted actually been the same as in the screenshot which you originally posted (i.e. "ASSERT(false) failed in [SoundDevice::CAudioThread::Deactivate]" or was it something different?
From the trace log, it does not seem so, thus i'm a bit confused now.
OpenMPT will now, from r4696 additionally on, just write out the error message to the crash directory as error.txt so you dont have to copy or screenshot it yourself anymore.

The last crash didn't produce an error dialog, unlike first. It wrote dmp and log, opened the dump folder and closed app completely.

Or maybe I missed something...

https://dl.dropboxusercontent.com/u/16644842/mpt/2015-01-03%2013.49.17.zip
Caught another crash with the new version. This one locked up MPT instead of exiting cleanly and had to be nuked from taskman.

https://dl.dropboxusercontent.com/u/16644842/mpt/2015-01-03%2013.59.47.zip
Another, smaller log. This time, the app showed error dialog, then crashed and closed without taskman after clicking ok.

So, it looks like I got mislead by the first error message which seemed to indicate problems with the sound device. The last two error messages you posted dont look like that. OpenMPT trying to shut down the sound device during a crash had originally just caused another crash.
Anyway, analysing these crashes requires debug information which we just did not retain for all test builds until very recently (r4697). Can you please try to reproduce this once again with the current version? Sorry for the inconvenience.

I downloaded latest mptrack.exe and I still get r4696

Oops, looks like our automation scripts got confused. Until I figure out what's wrong there, more current builds are available at http://buildbot.openmpt.org/builds/auto/openmpt-win32/ . It's just the -latest alias that is broken currently.

The -latest builds are now updated correctly again.

The bug senses our attempt to locate it in r4700 and won't come out to play anymore. Maybe if I write this, MPT will crash just to spite me.

I'll leave a bunch of instances running overnight, playing song, for the hell of it.

Almost 8 hours in and the 10 instances running have done nothing crashy. I shall go to bed and see next day. But I doubt results will be any different. But hey, who knows,

Maybe the mystery crash decided to fix itself.

Nope.

Caught a stop of playback with frozen VU meters, but app didn't crash and it didn't produce anything :<.

EDIT:
Caught another. The playback doesn't stop(I was wrong), but the display stops being updated.
VUs get stuck and patterns don't scroll.
Pausing and playing fixes this.

I have a feeling this has replaced previous crashing.

EDIT:
Caught a proper crash, enjoy.
https://dl.dropboxusercontent.com/u/16644842/mpt/2015-01-05%2015.58.51.zip

Sorry for following up late on this one.
The bug tracker just does not send out notification emails when you just edit a note instead of adding another one, so i had completely missed your newest crashdump until today. Sorry about that. Next time, please just add another note instead of editing a previous one.

OK, to the crash itself.

It looks like this is a crash in the mixing code.
The crash is at MixerInterface.h(90):
<pre>
89: filter(outSample, c);
90: mix(outSample, c, outBuffer);
91: outBuffer += Traits::numChannelsOut;
</pre>
which really does not tell much at all on its own.

I have not been able to reproduce this with a VisualStudio build myself at all.

However, openmpt123 built with clang address sanitizer gives the following:

<pre>
manx@idefix ~/projects/openmpt/trunk-tmp $ bin/openmpt123 --quiet --filter 8 /home/manx/VirtualBox\ VMs/shared/archon_-_sextyfour.mod
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started

==15186==ERROR: AddressSanitizer: heap-use-after-free on address 0x60800000b645 at pc 0x7f1d3d535690 bp 0x7fff18f32cd0 sp 0x7fff18f32cc8
READ of size 1 at 0x60800000b645 thread T0
#0 0x7f1d3d53568f in OpenMPT::PolyphaseInterpolation<OpenMPT::IntToIntTraits<2, 1, int, signed char, 16ul> >::operator()(int (&) [2], signed char const, int) /home/manx/projects/openmpt/trunk-tmp/soundlib/IntMixer.h:112:16
#1 0x7f1d3d53568f in void OpenMPT::SampleLoop<OpenMPT::IntToIntTraits<2, 1, int, signed char, 16ul>, OpenMPT::PolyphaseInterpolation<OpenMPT::IntToIntTraits<2, 1, int, signed char, 16ul> >, OpenMPT::NoFilter<OpenMPT::IntToIntTraits<2, 1, int, signed char, 16ul> >, OpenMPT::MixMonoRamp<OpenMPT::IntToIntTraits<2, 1, int, signed char, 16ul> > >(OpenMPT::ModChannel&, OpenMPT::CResampler const&, OpenMPT::IntToIntTraits<2, 1, int, signed char, 16ul>::output_t, int) /home/manx/projects/openmpt/trunk-tmp/soundlib/MixerInterface.h:88
#2 0x7f1d3d47044a in OpenMPT::CSoundFile::CreateStereoMix(int) /home/manx/projects/openmpt/trunk-tmp/soundlib/Fastmix.cpp:444
0000003 0x7f1d3e083d3f in OpenMPT::CSoundFile::Read(unsigned int, OpenMPT::IAudioReadTarget&) /home/manx/projects/openmpt/trunk-tmp/soundlib/Sndmix.cpp:261
0000004 0x7f1d3e2c7c95 in openmpt::module_impl::read_wrapper(unsigned long, float, float, float, float) /home/manx/projects/openmpt/trunk-tmp/libopenmpt/libopenmpt_impl.cpp:399
0000005 0x7f1d3e2d5e8a in openmpt::module_impl::read(int, unsigned long, float, float) /home/manx/projects/openmpt/trunk-tmp/libopenmpt/libopenmpt_impl.cpp:663
0000006 0x7f1d3e2ab262 in openmpt::module::read(int, unsigned long, float, float) /home/manx/projects/openmpt/trunk-tmp/libopenmpt/libopenmpt_cxx.cpp:218
#7 0x4ec909 in void openmpt123::render_loop<float, openmpt::module>(openmpt123::commandlineflags&, openmpt::module&, double&, openmpt123::textout&, openmpt123::write_buffers_interface&) /home/manx/projects/openmpt/trunk-tmp/openmpt123/openmpt123.cpp:1043
0000008 0x4e5d0f in void openmpt123::render_mod_file<openmpt::module>(openmpt123::commandlineflags&, std::string const&, unsigned long, openmpt::module&, openmpt123::textout&, openmpt123::write_buffers_interface&) /home/manx/projects/openmpt/trunk-tmp/openmpt123/openmpt123.cpp:1390
0000009 0x4aeab4 in openmpt123::render_file(openmpt123::commandlineflags&, std::string const&, openmpt123::textout&, openmpt123::write_buffers_interface&) /home/manx/projects/openmpt/trunk-tmp/openmpt123/openmpt123.cpp:1470
0000010 0x4acdba in openmpt123::render_files(openmpt123::commandlineflags&, openmpt123::textout&, openmpt123::write_buffers_interface&) /home/manx/projects/openmpt/trunk-tmp/openmpt123/openmpt123.cpp:1513
0000011 0x49641a in openmpt123::main(int, char**) /home/manx/projects/openmpt/trunk-tmp/openmpt123/openmpt123.cpp:1935
0000012 0x49237a in main /home/manx/projects/openmpt/trunk-tmp/openmpt123/openmpt123.cpp:2011
0000013 0x7f1d3b7d5ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
0000014 0x49179c in _start (/home/manx/projects/openmpt/trunk-tmp/bin/openmpt123+0x49179c)

0x60800000b645 is located 37 bytes inside of 88-byte region [0x60800000b620,0x60800000b678)
freed by thread T6 (threaded-ml) here:
#0 0x47b539 in free (/home/manx/projects/openmpt/trunk-tmp/bin/openmpt123+0x47b539)
#1 0x7f1d39d9ed5e (/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so+0x10d5e)

previously allocated by thread T0 here:
#0 0x47b789 in calloc (/home/manx/projects/openmpt/trunk-tmp/bin/openmpt123+0x47b789)
#1 0x7f1d39d9eb0e (/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so+0x10b0e)

Thread T6 (threaded-ml) created by T0 here:
#0 0x46ab72 in pthread_create (/home/manx/projects/openmpt/trunk-tmp/bin/openmpt123+0x46ab72)
#1 0x7f1d39dd374c (/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so+0x4574c)

SUMMARY: AddressSanitizer: heap-use-after-free /home/manx/projects/openmpt/trunk-tmp/soundlib/IntMixer.h:112 OpenMPT::PolyphaseInterpolation<OpenMPT::IntToIntTraits<2, 1, int, signed char, 16ul> >::operator()(int (&) [2], signed char const*, int)
Shadow bytes around the buggy address:
0x0c107fff9670: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 04 fa
0x0c107fff9680: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 04 fa
0x0c107fff9690: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 06 fa
0x0c107fff96a0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 06 fa
0x0c107fff96b0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c107fff96c0: fa fa fa fa fd fd fd fd[fd]fd fd fd fd fd fd fa
0x0c107fff96d0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
0x0c107fff96e0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
0x0c107fff96f0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
0x0c107fff9700: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
0x0c107fff9710: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==15186==ABORTING
</pre>

The time during playback when this happens varies. It happened so far for all interpolation types except "none".

I currently do not think the use-after-free itself is particularly conclusive. Without having investigated any further, I'd guess that the mixer is trying to read a sample out of bounds for some reason, and at that address, memory had been allocated before.

I think I recently discovered the same crash with MSVC; when adding thousands of modules to Mod Library, it crashed mid-way on one module in the mixer, but I couldn't reproduce it with that module. Since it's random, I don't really think that the problem is in the mixer itself, since rendering is absolutely identical every time (at least for MOD, where you have no random volume and panning factors).

Ok, i think i found the problem and fixed it in r4728.
When proper ProTracker-compatible sample change handling got introduced in r4223, some cases were missed which resulted in inconsistent sample pointers getting used, ultimately resulting in the buffer overflow causing the crash.
I"m still leaving the bug open and will wait for Saga Musix to comment on the solution as he is more familiar with the code in question than i am.

Yup, the new implementation looks good to me.