Topic: Experience MadiFX and Win10?

Hi,

who has got much experience with MadiFX in conjunction with Windows 10?

Which buffer sizes are you able to use when recording long takes (e.g. up to two hours) with huge track counts?
Which DAW software and which Windows built are you running?

Thanks for any input!

Ulrich

Re: Experience MadiFX and Win10?

Sequoia seems to benefit very much from Win 1803 PLUS activated MMCSS option in MadiFX driver.

It would be great if someone of RME could explain to us: Why is MMCSS suddenly so important? In recent years (Win7) we never felt the need for activating this driver option.

BTW: Reboot after changing that option seems to be necessary, right?

Best, Ulrich

Re: Experience MadiFX and Win10?

Ulrich wrote:

Hi,

who has got much experience with MadiFX in conjunction with Windows 10?

Which buffer sizes are you able to use when recording long takes (e.g. up to two hours) with huge track counts?
Which DAW software and which Windows built are you running?

Thanks for any input!

Ulrich

What is a huge track count ?
What is the use case ? Recording, Mixing, Mastering ?

For a performance related question:
What is your HW ? CPU, RAM, Mainboard, SSD or Disk ?
What is the current CPU load of the machine with such a huge project ?
How many plugins do you have in each of the tracks on average, are they CPU intensive ?
Are you using VSTi's, if yes which ?

What sample rate do you use for recording ?
Which ASIO buffersize do you use currently ?
At which ASIO buffersize you are starting to get audio loss ?

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

Re: Experience MadiFX and Win10?

It's about orchestral live recording, e.g. 60 tracks, sometimes more (up to 100 tracks). Standard FS.
HDSPe MadiFX, Sequoia (13 or 14).
While testing new hardware (X299 based boards) we experienced problems with Win10 (dropouts with smaller buffers, e.g. 256, RME's default buffer size). Finally we found out it seems to be solved only in Win 1803 with MMCSS activated in the driver (see my last post).
But did anybody else also come across such a problem? @RME: Why is MMCSS so important now, what's the technical background?

5 (edited by ramses 2018-08-13 18:35:58)

Re: Experience MadiFX and Win10?

Sorry, I have no idea about your specific question about MMCSS.
My intention is simply to be supportive in your case.

I could think of, that its maybe also for RME easier to answer your performance / work load related question,
if its known what Hardware you had before and have now and where the performance difference exactly is.

I tried to nail this down by knowing all the surrounding conditions  OS/HW of old/new system, what workload etc ...
and by simply asking, when exactly you have the issues, with what ASIO buffersizes on the different HW/OS combinations.

I fear if you do not deliver some more information, then it might be the case to only be able to tell in a very
general way about MMCSS cases of other customers, but maybe not about your case.

Of course you are free to wait for RMEs response 1st, maybe you also do not want make public, what systems you use.
But then I can't give you any advice.

What I can give you maybe as information, which is Win10 specific, is this from my Blog, maybe its related.
Its about some performance issues in Win10 that some people detected: https://www.tonstudio-forum.de/blog/ind … ing-EN-DE/

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

Re: Experience MadiFX and Win10?

Well, it's all there: a x299 based board, that means there is a modern CPU (hexacore i7), lots of RAM, system disk is SSD (of course) recording still on traditional HDD, there's only a simple AMD graphics card - this test system is built by a very experienced audio PC manufacturer. But we still have had these problems with Win10 only until 1803 edition. I am really curious what's the reason for the 1803/MMCSS solution - reading your blog I thought it could be related to the "Top 2" section of your blog entry, who knows...

7 (edited by ramses 2018-08-13 19:26:47)

Re: Experience MadiFX and Win10?

Ulrich wrote:

Well, it's all there: a x299 based board, that means there is a modern CPU (hexacore i7), lots of RAM, system disk is SSD (of course) recording still on traditional HDD, there's only a simple AMD graphics card - this test system is built by a very experienced audio PC manufacturer. But we still have had these problems with Win10 only until 1803 edition. I am really curious what's the reason for the 1803/MMCSS solution - reading your blog I thought it could be related to the "Top 2" section of your blog entry, who knows...

You can run their tests.

Interesting to read is their facebook article:
https://www.facebook.com/notes/vb-audio … 165445117/

Which leads you to an also very interesting article on stack overflow which compares Win10 to Win7 performance of memory subsystem, which you should maybe also read: https://stackoverflow.com/questions/450 … -is-not-sc

Their VB test script you can find here on their forum
https://forum.vb-audio.com/viewtopic.ph … amp;p=1255

There is a link to this ZIP
https://download.vb-audio.com/Download_ … _v1000.zip

Maybe try to run it on your system with or without MMCSS.

"To make the test in your computer right now, the program (EXE) can be download directly there:
https://download.vb-audio.com/Download_ ... _v1000.zip
Just run it during some hours (12 or 24h00) or until getting the first incident (will be displayed in red)."
The source code of the Real Time Task performed is very simple:
void MyAudioCallback(LPT_APPCTX lpapp, void * lpBuffer, int nbSample)
{
   int * lpSource, *lpTarget;
   int vi, fTurn;

   //simple BUS Copy (in this example, this is not enough to make appear the problem)
   lpSource = (int*)lpBuffer;
   lpTarget = lpapp->pInternalBUS2;
   for (vi=0;vi<NB_CHANNEL_IN_BUS;vi++)
   {
      memcpy(lpTarget, lpSource, sizeof(int)*nbSample);
      lpSource=lpSource+nbSample;
      lpTarget=lpTarget+nbSample;
   }
   //copy to delay line (we add this regular delay line copy, used in multi track recorder as DTR process for example).
   fTurn=0;
   lpSource = (int*)lpBuffer;
   for (vi=0;vi<NB_CHANNEL_IN_BUS;vi++)
   {
      lpTarget = lpapp->pDelayLineBuffer[vi];
      lpTarget = lpTarget + (lpapp->pDelayLineBuffer_nu[vi] * BUFFER_SIZE);

      memcpy(lpTarget, lpSource, sizeof(int)*nbSample);
      lpSource=lpSource+nbSample;

      lpapp->pDelayLineBuffer_nu[vi]++;
      if (lpapp->pDelayLineBuffer_nu[vi] >=DELAYLINE_NB_BUFFER)
      {
         lpapp->pDelayLineBuffer_nu[vi]=0;
         fTurn=1; //count number of memory restart address
      }
   }
   if (fTurn != 0) lpapp->pDelayLineBuffer_turn++;
}

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

8 (edited by ramses 2018-08-13 19:48:41)

Re: Experience MadiFX and Win10?

This topic might be related:
https://www.forum.rme-audio.de/viewtopic.php?id=25871

Please find here some very interesting information from Timur Born:
https://www.forum.rme-audio.de/viewtopic.php?id=25743

Or read this other thread from here:
https://www.forum.rme-audio.de/viewtopi … 45#p122545

Also this information from Steinberg might be interesting: "[...] Steinberg issued a warning for win10 users about anything above 14 virtual cores causing issues. Are you on Win10? If yes does disabling HT fix anything?[...]"
https://www.forum.rme-audio.de/viewtopi … 95#p121895

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

Re: Experience MadiFX and Win10?

Interesting, thanks a lot!

MC, do you have any further insights on MMCSS suddenly improving behaviour only in Win10 1803 ?

Re: Experience MadiFX and Win10?

Yes and no...

It's true HDD is a bottleneck, but now (with WIN 10 1803 and MMCSS activated) I can succesfully record up 150 tracks even with HDD. Using SSD I can record all 192 inputs.

So I still observe a huge improvement with Win10 1803 *AND* MMCSS option activated, compared to older Win 10 editions.

BTW: At least here I have to reboot my system in order to make a change of the MMCSS setting take effect. This contradicts with MC's statement in another thread here in the forum that restart of ASIO should be sufficient. In case this is the general behaviour (and not only my Sequoia DAW) there should be an appropriate message for the user, I guess.

11 (edited by Potscrubber 2018-08-27 03:01:02)

Re: Experience MadiFX and Win10?

Ulrich wrote:

It's about orchestral live recording, e.g. 60 tracks, sometimes more (up to 100 tracks). Standard FS.
HDSPe MadiFX, Sequoia (13 or 14).
While testing new hardware (X299 based boards) we experienced problems with Win10 (dropouts with smaller buffers, e.g. 256, RME's default buffer size). Finally we found out it seems to be solved only in Win 1803 with MMCSS activated in the driver (see my last post).
But did anybody else also come across such a problem? @RME: Why is MMCSS so important now, what's the technical background?

Hi Ulrich

It's not all of a sudden, MMCSS has given better low buffer performance for some years even on Win 7.  There is some background to it around if you do a search here and off-site.  I have the same usage case as you.  If you are just capturing and not mixing, you might get even better performance setting Sequoia to use one core (non hyperthreading) or two (if hyperthreading).  Also disabling "playback during recording" can add even more overhead.  But then you can't freak colleagues out by demonstrating editing while recording ;-)

In short, my tests (& real world use) get incremental performance increases with the following:

  • MMCSS on

  • Redundancy mode & mirror madi ticked in driver (if only using one madi port but sounds like you need more!)

  • No WDM devices

  • Optimise multi-client mixing off if you don't need it

  • Restrict Sequoia to one physical core if recording only

  • "Playback during recording" off (record options)

  • The minimum Sequoia monitor mode for your usage

all the best,
Simon

Madiface XT, Madiface, 3x Micstasy, ADI8QS
Sequoia 17, W10 x64
https://bsound.co.nz/tools-nix

Re: Experience MadiFX and Win10?

Why would you even need low latency during recording? Just set everything to maximum (including DAW settings) and be on the safe side...


Regards
Daniel Fuchs
RME

Regards
Daniel Fuchs
RME

Re: Experience MadiFX and Win10?

With a team sharing the same DAWs I prefer to setup the DAW in a way it can handle both recording and playback/mixing situations comfortably, without switching options back and forth. This results in asking for lower buffers - which is no problem NOW anymore...

Re: Experience MadiFX and Win10?

Recording with monitoring (through DAW). Necessary to have low latency.
OK, I could use hardware monitoring using totalmix, but for me it is more comfortable to use Sequoias mixer for that together with low latencies.
Georg

15 (edited by ramses 2018-10-21 09:17:35)

Re: Experience MadiFX and Win10?

I just stumpled over this thread on the Steinberg Cubase forum, which could bring some light into this.
Sounds to me that MMCSS would be nice to have, but that Microsoft changed / limited the implementation in Win10.

EDIT: URL of posting on Steinberg Forum that explains the topic/issues and links to the helpcenter article
https://www.steinberg.net/forums/viewto … p;t=117319

https://helpcenter.steinberg.de/hc/en-u … CPU-setups

As of Windows 10, the amount of real-time processing threads with Multimedia Class Scheduler Service (MMCSS) priority is limited to 32 per process - 4 of which are blocked by non-audio-threads already running.

In short, the outcome of this is that on systems built around a CPU with more than 14 logical cores*, processing threads exceeding this amount will be carried out as non-real-time (like UI-threads), introducing drop-outs and performance issues.

As long as no fix is provided on the operating system side, the following work-around will avoid performance issues and dropouts:
    Option 1: Downgrade to Windows 8.1
    Option 2: Limit the amount of cores used by Cubase/Nuendo to 14

There are mainly two ways of limiting the amount of cores:
Limit the amount of logical cores to 14 in your BIOS/UEFI (if applicable, please consult the motherboard documentation for details)
or
Limit the amount of cores used by the application's engine, here is how-to:

I could think of that this could be related to the issues that you experience with Sequoia under Win10.

There is also a link to a test program mmcss-test.exe
https://helpcenter.steinberg.de/hc/en-u … s-test.exe
which shows the amount of MMCSS priority threads and the amount of threads which failed to set MMCSS priority.

When running it on my Win7 system with Xeon E5-1650 (6 cores/12 threads), then there is no issue.
I tried even very high values of 8192 and 16384 which also succeed under Win7.
Careful: 16384 creates a lot of stress on your CPU, runs for 36 sec with 100% CPU load.

On Windows 10 (even the latest 1809, my upgrade succeeded before it has been pulled back my Microsoft)
it fails to support only 32 threads out of 128.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

16

Re: Experience MadiFX and Win10?

That is old news also found in this forum:

https://www.forum.rme-audio.de/viewtopi … 98#p121898

https://www.forum.rme-audio.de/viewtopi … 06#p131206

Also you linked to this exact topic in this post already:

https://www.forum.rme-audio.de/viewtopi … 98#p133198

Forgot? wink

Regards
Matthias Carstens
RME

17 (edited by ramses 2018-10-21 11:02:18)

Re: Experience MadiFX and Win10?

Yes and no wink The last thread you mention I remember and it also contains the link to the Steinberg Forum.

From the Steinberg forum I only remember the information, that Cubase has issues in Win10 on systems with CPUs that have a high number of logical cores.

New for me is the root cause for this behaviour.
That in Win10 the number of MMCSS prioritiseable threads per process is limited to 32.

This root cause is not mentioned directly in Fabios posting on Steinberg Forum.
But in the Helpcenter Article which I cited.
I think when I looked at that time into this Posting on Steinberg I simply missed to click onto the Helpcenter article.

Here on RME Forum only the URL to the Steinberg Forum article has been linked.
When searching for MMCSS and briefly browsing through all the 3 URLs that you kindly provided,
then I can't see any discussion which explicitely mentions the Win10 MMCSS limit as the root cause for audio drops.

My intention was to bring the root cause more "to light" based on the theory that also others might have missed
to look deeper and to also read the Steinberg helpcenter article.

I personally think its important to understand this as we get more and more CPUs on the market which have a large number of logical cores at a very attractive price point. So its more likely to trap into this issue.
To put some examples of AMD CPUs with logocal cores over 16:
Ryzen 7 1700: 16 logical cores, €206
Threadripper 1920X: 24 logical cores, €403
Threadripper 1950X: 32 logical cores, €764:

The other question is, whether also other DAW vendors are aware of this. At the end in most cases it will always come to the vendor of the recording interface, as everybody thinks, the issue is with the ASIO driver.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub13

18 (edited by Timur Born 2018-10-25 00:38:58)

Re: Experience MadiFX and Win10?

Sequioa does not make use of MMCSS on its own at all, it does seem to benefit somewhat from W10 1803, though. Switching on MMCSS in the RME driver only affects the main ASIO thread, all additional Sequoia threads only use non realtime priorities (15). It can still be beneficial, because it solves some priority conflicts with Windows UI (alt-tabbing for instance).

Manually setting all Sequoia threads to realtime priority works even better, unsurprisingly, but that comes with its own drawbacks.

Same applies to Samplitude.