• SONAR
  • Yikes! Having terrible / odd glitch with RME MADI-FX / Sonar X3d / ASIO
2014/01/19 05:39:22
ewb
(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
2014/01/19 10:02:03
Guitarmech111
I think you need to call RME support on Monday. I do not have any MADI experience. My UFX syncs to lightpipe and has no issues that I see so far with regards to what you have.
If you say the issue is still present with SONAR closed, that would point to the hardware. Now if you meant to say minimized, that may be another story.

Have you tried to reprofile your audio interface? You may have to go with the old - If it hurts when you do that, don't do it and use the WDM mode for now.
 
What happens when you have no hardware FX attached to the main hardware unit? Do you use the Totalmix matrix to route your audio ins/outs?
 
Just trying to gather info that I would try, but I do not know your specific hardware. Sorry.
2014/01/19 10:30:29
gswitz
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.
2014/01/19 10:47:59
Razorwit
Hi ewb,
I'm trying to replicate it here (I have a MADI FX driving a Lynx Aurora and an Orion32), but I'm not certain I understand the recipe. Here's what I'm doing:
 
1. Create a new project with only one audio track.
2. Put some audio on that track and assign it directly to a hardware out...say, MADI 1/2.
3. During playback, re-assign the output on that track to some other output, say MADI 3/4
 
Since the project contains only one audio track, reassigning the output should leave MADI 1/2 empty which then causes the problem. 
 
Is that a correct recipe for the behavior you're seeing?
 
Dean
2014/01/20 03:10:01
ewb
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. =\
2014/01/20 07:41:29
gswitz
This will be a ridiculous work around, but what about creating 4 stereo outs and assign them to the 8 channels with nothing on the tracks. Would that solve the problem?
2014/01/20 14:24:38
ewb
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!
2014/01/20 14:37:58
Razorwit
Hi ewb,
Glad to see you have a workaround in place. I've tried to replicate the problem a couple times on my system and am unable to reproduce it. It sounds like you have a good solution in place, so the point may be moot, but FWIW it's not behavior that I'm seeing here. Let me know if I can help out or try anything and I'll be happy to do what I can.
 
Dean
2014/01/20 14:48:05
ewb
Perhaps our different Windows versions is playing a role? (7x64 vs 8.1x64)
 
Thanks for trying though.
2014/01/21 08:14:01
Noel Borthwick [Cakewalk]
Will look into the assertion that we're not zeroing buffers on stop. I'm pretty sure that we do however...
12
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account