gmp
Can you tell me what MMCSS is? I'd certainly like to try it. MOTU has been horrible about addressing this. When I talk to them them seem like they're more into Mac and Logic and don't;' have a clue about why I've having this problem and that I'm the only one who has this happen. I gave up dealing with their lame support on this issue.

it's in preferences / audio / playback and recording ... "Use MMCSS" ... manual says "This option gives real-time applications such as SONAR higher priority for resource scheduling (thread scheduling) under Windows 7 and later (leave it checked)." which is counter-intuitive that this actually improves things, but indicative that under the hood something is going on that is not quite right.
 
don't know who is to blame ... Sonar, Motu or even win10 ... I only got these interfaces like 4 months ago and back then I tested a lot of things with them and don't recall anything like this ... what has changed meanwhile? well everything: Motu driver 3x, Sonar 4x, win10 several times (first 1607 applied, then all the weekly updates) ...
 
seriously thinking about rolling back to August, but that will be a major hassle ...

Here the latest win10 update did not change anything ...
I did some more tests:

• when using the MOTU AVB web UI (launching, changing between pages) while playback at heavy load I do get bursts of audio dropouts; this is most extreme with web UI open in Microsoft Edge (but to a lesser degree in Firefox); it's worse with MMCSS checked, but does not fully disappear when unchecked. to some (but much lesser) extend I could also get this with the same tracks/same plugs in a mixbus project (looks like a MOTU issue)
• however, with the AVB web UI closed, I only get glitches in Sonar, the "same tracks/same plugs" mixbus project plays fine, even when using small buffers to push mixbus reported CPU% to 98% ... on the contrary Sonar produces buzz like glitches with MMCSS on (irrespective of buffer size and CPU use) and occasional crackles with MMCSS off (looks very much like a Sonar issue)

All of this makes me wonder how much heavy load testing either company does despite claiming to provide "pro" tools (ouch, that last line kicked a bit too low ...)

My random crackly recording problem with the MOTU 828x (USB or TB) happens with basically no load on the system... New session with one track and no plugins with buffer at 256 samples. The problem doesn't happen with a Cakewalk U25-EX at an even lower buffer size. You would think the Thunderbolt connection would allow me an even smaller buffer size. I will try testing the 828x with Hyperthreading off, as well as completely disabling my wifi adapter. Mark.

Klaus
If you rule out the influence of MMCSS (keep it off) which made the problem worse as you said, couldn't be the occasional crackles while playback at heavy loads be the result of the usual suspects CPU load, AI Driver Buffer Size, Playback I/O Buffer Size?

 
of course, I did test the usual suspects with MMCSS off, but for both ASIO and IO buffers it's the same i.e. if too small you notice immediately (playback won't start or stops in first few seconds), but once it plays OK, going larger with buffers does not change the random crackling situation.
 

Klaus
I'm a bit skeptical about comparing different DAWs when it comes to efficiency under heavy load - only if I'd know the Audio Engine of both programs is the same...

well, the intention was to check with an audio engine that is not the same to see whether same tracks, same plugs, same ASIO buffers, same load cause the same issues (as this would get Sonar off the hook)
 
 

gmp
Over a year ago, when I was having some trouble with the web UI, a MOTU phone tech support guy told me to use Chrome. He said it was the best for MOTU products. Since then I've used it and it's been good.

 
thanks for letting us know. they should put something like this into a support document / page.
 
having suspected the webUI for adding extra interference, I keep it closed unless I have to change something ...
 

gmp 
Since I've finally found some users that are interested in this glitch problem, I'll keep a daily log again on this and report back here and see if we can unite to get Cakewalk and MOTU to figure this one out.

yes, please do so. when we had some other issues with MOTU driver not being recognized after reboot, it took several of us from the forum here to alert them that this is not a "single user hardware setup issue". eventually they decided to dig in and fixed it within 2 weeks.

Hello again, here is another update...

I can re-create the static recording problem through Thunderbolt by using MOTU Audio Console or CueMix and then going back to Sonar to record.

BUT, when I totally disabled my laptop's WiFi in device manager, The 828x with Thunderbolt seemed to work perfectly fine... even when monitoring and recording at a 64 sample buffer size.  When I re-enabled WiFi, the problem came back.

The problem is that I need to be connected to WiFi for my Waves Plugins license to work (and you may need to be on WiFi if your audio console is using a web browser???).

So, I tried USB again after disconnecting the Thunderbolt cable... this time the USB connection seems to be running really stable, even at a 64 sample buffer size.  The USB connection WAS giving me random problems before... maybe recent Windows 10 or Sonar updates fixed it?

Is there any way I can have WiFi and the 828x using Thunderbolt get along with each other?

I will let you know after I have a chance to use the system more, whether or not it stays stable with USB.

Thanks,
Mark

Yeah, I might have to go back to the Waves plugin license being on a USB stick... I was trying to avoid it as I already have an iLok to plugin sometimes as well.
Mark.

FYI, I opened a support ticket with MOTU last week and added a lengthy problem description. I got a short reply last night, so we at least got the communication going. If anything comes out of that ... I'll let you guys know

I received a beta driver last night, which I put thru a 3 hour test. It seems to behave a lot better as regards interference with webUI open in different browsers (basically, I could not get it to cause the serious dropouts I could produce before) and it also seems to perform better (but not perfect) with that Sonar MMCSS option (so that is still under investigation / being discussed with MOTU support) ... I still wish someone from Cakewalk would comment and share more information rather than the "keep it checked" that's all there is in the manual.
 
In these 3 hours of recording no audio file corruptions occurred, but I need to test that a lot longer as this was a rare but serious issue.
 
The driver is confidential and explicitly not to be shared/distributed, but if it proves to be better in the long run, MOTU should make it public shortly after (happened the same way last time)

KPerry
This may vary with that MOTU driver (although I thought they were unified now...) but with the MOTU Ultralite 3 which I have, the ASIO driver itself enables MMCSS when in use, so the checkbox in SONAR has no effect.  The WDM driver does not enable MMCSS so the checkbox in SONAR does do what it's supposed to.

how do you find out whether the driver itself enables MMCSS or not?

I unchecked MMCSS. I recorded a mix routed back into Sonar from my analog mixing console and when I listened back to it, I found 2 bad glitches on the intro that weren't there while I was recording, so I decided I better check the box for MMCSS again.
 
In the past all glitches were audible, so when I heard one, i could just back up and punch back in to fix it. I'll just wait until they fix this.
 
I'm very encouraged by the beta driver. Great work pressing MOTU. I had no luck with them for well over a year. I hope we get this resolved once and for all.

Rob[atSound-Rehab]

gmp
In the past all glitches were audible, so when I heard one, i could just back up and punch back in to fix it.

well, in my case glitches are not audible while recording. all sounds perfect in the MOTU DSP monitor mix. when played back in Sonar, the glitches are there.
 
BTW, it happened again with this beta driver in a multi-track session last night. so while the playback in Sonar seems better, the record corruption is still there (w/ or w/out MMCSS) ... the beta driver also crashes Mixbus in playback (which the official driver did not do on the same project) ... so not quite there yet ...

With the glitches not audible, I now understand your serious problem. That's far worse than mine. I hope my occasional random playback glitches are fixed when they get you up and running. Keep up the pressure and thanks for all the updates

I have more information from a long test I did today, but I have to say that I am getting really tired of testing these issues and also of the situation it puts me in (i.e. not being able to rely on the recordings to arrive properly on the disk)

Since I own 2x 1248s I hooked up a 2nd DAW to the 2nd AVB and created AVB streams to send all 20 channels that I record on DAW #1 to DAW #2 to also record it there ... to see whether there may any issues with the hardware units themselves or the DAW.

1248 no 1: is hooked up to the main DAW (specs in my signature), using the unofficial 71666 beta driver
1248 no 2: is hooked up to a much smaller DAW (Acer tablet), which is still very capable of doing these multi-track recordings; here the last offical driver 71418 (Nov 1 , 2016) is installed

Either DAW uses Sonar 2016.09 and win10pro fully up to date.

Well, it turned out quickly that the problem of corrupted recordings ...
... happens on either DAW - but not both at the same time (!!!); yet this rules out other usual suspects like HDDs, etc.
... happens @ all buffer sizes (256, 512, 1024)
... when it happens, it's audible on all tracks, but seems more audible on those tracks with higher level/bigger transients (i.e. more bits/data)


I just sent audio examples to prove this to MOTU ... and need to do likewise with Cakewalk as I cannot let Sonar off the hook. I tried 2 recordings using mixbus and both turned out perfect (coincidence? anti-Murphy's law?)
 
 

Rob[atSound-Rehab]
I have more information from a long test I did today, but I have to say that I am getting really tired of testing these issues and also of the situation it puts me in (i.e. not being able to rely on the recordings to arrive properly on the disk)

Since I own 2x 1248s I hooked up a 2nd DAW to the 2nd AVB and created AVB streams to send all 20 channels that I record on DAW #1 to DAW #2 to also record it there ... to see whether there may any issues with the hardware units themselves or the DAW.

1248 no 1: is hooked up to the main DAW (specs in my signature), using the unofficial 71666 beta driver
1248 no 2: is hooked up to a much smaller DAW (Acer tablet), which is still very capable of doing these multi-track recordings; here the last offical driver 71418 (Nov 1 , 2016) is installed

Either DAW uses Sonar 2016.09 and win10pro fully up to date.

Well, it turned out quickly that the problem of corrupted recordings ...
... happens on either DAW - but not both at the same time (!!!); yet this rules out other usual suspects like HDDs, etc.
... happens @ all buffer sizes (256, 512, 1024)
... when it happens, it's audible on all tracks, but seems more audible on those tracks with higher level/bigger transients (i.e. more bits/data)


I just sent audio examples to prove this to MOTU ... and need to do likewise with Cakewalk as I cannot let Sonar off the hook. I tried 2 recordings using mixbus and both turned out perfect (coincidence? anti-Murphy's law?)
 
 

 
Good testing Rob. This sure proves that there is a problem with MOTU and Platinum. Have you tried to get Noel on the case? He's been with Cakewalk about 20 years and is brilliant. He may be aware of a similar problem with another audio interface that would relate to this.

Rob[atSound-Rehab]

gmp
Have you tried to get Noel on the case? He's been with Cakewalk about 20 years and is brilliant. He may be aware of a similar problem with another audio interface that would relate to this.

As I'm running out of ideas on what would be causing this I just tried to PM him. It said "message delivered", but now the message cannot be found in the Sent box and I wonder if Cakewalk filters/blocks this way of direct communication to avoid being flooded with support enquiries ...

Maybe it's just a delayed response. I looked at my old PM's and saw 3 folders on the left: unread, sent, and inbox. It listed how many messages were in each folder. I saw my PM's to and from Noel. If it doesn't show up in 24 hours fro sure resend it. I don't' ever remember any delayed response. Hopefully this will help get a solution.

I've been using a MOTU 16A with Sonar Plat for the past 10 months and haven't had an issue like this... touch wood.
I'm also running the latest Platinum update.
Your kind of problem would drive me mad.