Yikes! Having terrible / odd glitch with RME MADI-FX / Sonar X3d / ASIO

(Posted on RME board as well)
 
Hi there. Just got my MADI FX up and running and I'm having a very strange issue that I've never encountered in any DAW setup. Definitely a bug... but after playing with it for hours I can't determine if its on the Cakewalk or RME side. Likely Cakewalk... but unfortunately I have no other software to try it with.
 
System in question is RME HDSPe MADI-FX set to sync from MADI, Burl Mothership (16 channels in, 16 out, set to internal master clock) on MADI 1, Ferrofish A16 MK-II (16 I/O, sync to MADI) on MADI 2. Intel 3930k running Windows 7 x64, Sonar X3d with ASIO driver. RME driver 1.17 with Firmware 89 and DSP 19.
 
Problem also verified on Sonar X2b. WDM driver exhibits no issues across the board.
--------
 
Ok... this is hard to explain:
 
DURING PLAYBACK:
 
If I reassign any track or bus hardware output in a manner that the old output WILL BE LEFT EMPTY (no other tracks feeding it) and the new output WAS EMPTY (before the reassign) I am left with an infinite, skipping loop of audio in the original hardware channel. The junk audio is composed of approximately the last 100 milliseconds of playback information from the track I reassigned.
 
For instance:
 
Guitar    -> MADI 1-2
(Empty) -> MADI 3-4
 
I reassign the guitar *during playback*...
 
(Empty)  -> MADI 1-2
Guitar     -> MADI 3-4
 
The guitar is successfully reassigned, but I am left with a short, infinite loop of guitar in MADI Out 1-2.
There will be no issue / effect if either the original or target hardware output has other content feeding it. For instance:
 
Vocal     -> MADI 1-2                    Vocal  -> MADI 1-2
Guitar    -> MADI 1-2   |Reassign|  Guitar -> MADI 3-4    (OK!)
(Empty) -> MADI 3-4                   
 
or
 
Guitar -> MADI 1-2   |Reassign|  Guitar -> MADI 3-4    (OK!)
Vocal  -> MADI 3-4                     Vocal  -> MADI 3-4

----
 
Further observation:
 
The looping sound remains even after stopping playback and even after closing / reopening SONAR. It IS silent while Sonar is closed and / or while in ASIO configuration.
 
The junk audio is clearly visible in Totalmix (playback channel pegged at whatever level the audio was when the reassignment happened)
 
Analysis with DIGICheck shows the audio looping in the respective channels' ASIO playback and hardware. This, however, is STILL VISIBLE when Sonar is closed or has otherwised released its ASIO control. It is like a short audio buffer is trapped somewhere in a rogue thread.
 
It can be stopped by reassigning any track or bus to the glitched hardware output while playback is stopped.
 
During playback it can also be stopped by re-routing any track / bus to the glitched output, but (as noted) if the hardware output that bus was on is now orphaned, it will become a glitched output itself.
 
It has a similar, odd relationship to other tracks in groups of 8. If I reassign from an empty/silent group of 8 buses, to another group (MADI 1-2 to MADI 9-10 for instance) there will be no AUDIBLE loop and it will not appear in TotalMix. However, the looping audio can still be seen in DIGICheck, and it will be heard as soon as any other output from the original group of 8 is used (for instance, MADI 3-4).

-----
 
Confused? Me too. =\
 
Thanks for your time,
-ewb

http://www.rme-audio.de/forum/viewtopic.php?id=19203
 
I see you've already posted to the RME forum and Mathias has answered back.

He's very good!!
 
In preferences, try disabling
Audio > Playback and Recording > Always Stream Audio through FX
 
For what it's worth, I'm not having the problem with my UCX. I just tested according to your instructions.

Thanks for the responses.
 
Yeah, Mathias is ridiculous... responded within a couple of hours. =]
 
Looks like Sonar is failing to request the buffers be cleared. Still waiting to hear what the ultimate solution may be.
 
gswitz - I tried the "Always Stream Audio through FX" option. No luck.
 
Razorwit - That is indeed the correct way to replicate the error. After playing around with it for awhile, a more concise description would be:
 
During playback or live input monitoring, creating an unused hardware output by reassigning its source track will fail to clear that orphaned hardware output's audio buffer IF said source track is reassigned to an unused hardware output.
 
Quite a mouth full.
 
Mathias made note of the "Optimize Multi-Client Mixing" option... which will actually cure the problem for the first 8 channels of the first MADI port. All other channels in the system still suffer. =\

Wow... gswitz.... genius.
 
Not only does that work, but it works even if the workaround tracks are ARCHIVED.
 
Created 32 tracks assigned to all 32 outputs, archived all, hid all. Problem is gone. Will make that part of my templates and it should be a fairly painless workaround in the meantime.
 
Thanks!

Perhaps our different Windows versions is playing a role? (7x64 vs 8.1x64)
 
Thanks for trying though.

The problem was confirmed and fixed with a new driver on RME's side (within 3 days of reporting the issue... on a weekend... wow).
 
(EDIT): Apparently I don't have privileges to post links until I log another 13 posts...
 
The RME forum thread and the new driver can be found via gswitz link on reply 2.
 
Or Google: RME Yikes
 
And it should be first on the list.

Here is the link:
http://www.rme-audio.de/d...ver_pciefx_win_118.zip

This is one reason why I am a huge fan of RME. Fantastic support.

D'oh! not for the UFX...  Glad things got situated!