First off, it can pretty much be ruled out that this problem has anything to do with 8-bit samples. The error observed in the file you uploaded is a problem with your NVIDIA ASIO driver; We haven't really changed anything in OpenMPT's ASIO handler recently so it would be good to know which version you were previously using. It's also possible that an audio driver update introduced the problem and not an OpenMPT update.

Now i figured out what has been wrong this was not problem related to samples bits. I have applied to sample mute loop at the end (i have been doing this because carry envelope option working only with looped samples) together with Duplicate Note Check : disabled and thus overload of cpu because channels has become multiplied infinitely and this "bug" were not there in older versions and other trackers-players because of limits of channels that can be played at once. here is example of this thing without this deaf loop( attention at vol level"

The maximum number of playing voices has been 256 in all OpenMPT versions in the last 10+ years, and even a 15 year old PC should be able to play that module flawlessly with the maximum number of voices, so I kinda doubt that this is the reason for any problems you might be encoutering. To verify, you can reduce the number of mix channels in the Mixing tab of the OpenMPT settings dialog from 256 to 128.

Infact decreased numbers of voices to 128
have solved problem but that doesn't change the fact that older Openmpt don't freezing with those 256 voices("last good" Openmpt released in my bday 14.08) nevertheless after knowing what was culprit this is not problem any more
.Does anyone tested if this example mod freezing system after while of playing on new mpt?

Okay, I have a clearer understanding now what is happening here. The mixer was considerably rewritten in OpenMPT 1.27, and in particular the resonant filter (which is one of the most CPU-taxing parts of the mixer) was modified to work better at high sampling rates (previously, it would not always work correctly at 96kHz mixing rate). I believe that playing 256 simultaneous unfiltered voices is still going to work perfectly on your machine, but when playing lots of filtered voices, the CPU load might be too high and it cannot keep up with playing the file in realtime.

There is not much we can do here on the OpenMPT side, because those quality improvements and bugfixes in the mixer are required, but I can make two suggestions for your particular machine, in this order:

• Use fewer instruments with resonant filtering, if possible.
• Increase the buffer size of your ASIO driver. This may give OpenMPT more time to mix those filtered voices. Note that you may need to do this in your ASIO driver's control panel, because the latency specified in OpenMPT is just a suggestion to the driver which many drivers ignore completely (as they only support one particular buffer size specified in their control panel).
• Lower the number of voices to 128, as you already did.

That said, there might also be a problem specific to this ASIO driver that we need to investigate (@manx "Internal error occurred at ....\mptrack\MainFrm.cpp(720): ASSERT(m_pSndFile != nullptr) failed in [CMainFrame::SoundSourceUnlock].").

Ok. I will try it if I will need ,regards.

r11463 adds more assertions which might help tracking down the ASIO problem

related: https://forum.openmpt.org/index.php?topic=6580.msg48025#msg48025