I would also strongly recommend to make a recording of the suspicious signals and to have a look at the waveform.

In the past I experienced a similar phenomenon with a ADAT connection at 96K. The waveform of only one of several channels looked bizarre when zoomed in, and the spectrum analyzer showed many frequencies in the non-audible range. It turned out that all samples had been swapped in pairs somewhere between the AD and my digiface (maybe an old driver was involved, too). This leads to mirror frequencies, very crazy...

Maybe in Bob's case some samples are screwed up in a similar way, surely it's worth examining the waveforms.

Regards,
Ulrich

Bob,

I fully support the idea to record the faulty signal including a simple testsignal like a 1 kHz sine. At this time everything seems to point in this direction, especially as MADI 96 kHz with 48k Frame is using S/MUX to realize that sample rate. Looking at the waveform then will quickly not only reveal if it is a byte swapping/corruption problem, but also will give us an idea what kind of error may be causing this, as the wrong bitstream is like a fingerprint of the fault.

I also would like to repeat something I mentioned before: it would be helpful to check the current channel status of the faulty output. Simply feed it into an AES card and fire up DIGICheck, or use your own analyzer.

It happened again today and the problem is not emphasis. Although I did not measure the emphasis bit, I know it is not emphasis because the problem can be recorded and then played back on a DAW (SADiE) that does not employ the emphasis bit. And because Sequoia ignores the emphasis bit when it records audio data.

As requested, when I heard the problem today, I did some further tests. Since there is no way to upload files to your forum, please go to

ftp.digido.com
your   name is  rmedebug   
your pw is rmedebug   

And download the files which are there. 73 MB worth.

Here's what I did: Everything is at 96 kHz. When I heard the problem (HF loss on the right channel). I took a -14 dBFS stereo, uncorrelated, pink noise file and first bounced it at high speed to another track in Sequoia (thereby NOT going through the MADI interface) as a control. This is file #01. Then I patched my Z Sys router so that AES output 1&2 of Sequoia was directly patched to AES input 1&2 and I bounced the pink noise source in real time. This is file #02. It clearly shows a HF loss in the right channel. I then dubbed the AES out of Sequoia into SADiE, real time, this is file #03. It also clearly shows an HF loss in the right channel. (SADiE is on another computer)

Then I attempted to fix the problem by power cycling all four MADI interfaces, turning them back on sequentially, waiting until the first settles down before powering on the next. This time the power cycling DID NOT FIX THE PROBLEM. So I turned off interfaces 2 through 4 and power cycled interface #1 only. Now interface #1 is the only one on, and therefore the MADI loop is not complete (the Hammerfall control panel shows that nothing is connected to its MADI input). Perhaps it is a coincidence, but now the first interface is behaving properly. Then I turned on the other three interfaces and the signal continues to be good.

Then I captured this signal into SADiE, which is file #4, which is now a good file.

Then I measured the right channel spectrum using RME Digicheck's spectral analyzer, of the good signal and the bad one. We can see some classic delay-based comb filtering going on, including a disturbing rise at 40 kHz.

Could it be the Automatic Delay compensation?  Could it be because I'm distributing word clock via a BNC T to all four MADI interfaces instead of daisy-chaining it the way RME recommends?

I hope this helps,

Bob

Thanks for trying, Ulrich. I just checked an FTP client and it is working for me.  But in addition to an FTP client, here are two other methods you can use to get on:

Using a Browser, go to http://www.digido.com/ftp.html

Log in as rmedebug with pw rmedebug

Use the down arrows to download the files. I just checked this and it works.

-----
OR, via WEBDAV:

PC:
1. On the desktop, double-click My Network Places.
2. In the "Network Tasks" pane, click Add a network place.
3. On the welcome screen, click Next.
4. Select Choose another network location, and then click Next.
5. In the "Internet or network address:" field, enter http://ftp.digido.com:9001

same name and password

Mac:
1. In the Finder, go to ?Go? -> ?Connect to Server? (Apple + K).
2. In the "Server Address?, type http://ftp.digido.com:9001 and hit connect!

same name and password

This will mount the volume locally on your computer and you will be able to drag and drop your files, like any other external hard drive!

I hope that one of these two does the trick.

Bob

Gosh I hope so. I forgot to record a sine wave! But the big dip at 6 kHz (which sounds like a HF loss) accompanied by a big peak at 40 kHz should give a clue as to what must be going on, I hope.

Oh, Ulrich, do you work all night?!!!!!

I suspected such. But I received a reply from him that must have been midnight his time...

Anyway, a small correction to my first post. I talked about the first MADI box as the one that says "AUTO01". Actually, the first box says "AUTO". The rest of the boxes increment 02, 03, 04.

BK

I guess my daft guessing here is ruled out a long time ago:
- firmware of the ADI-642 boxes.
- Fiber MADI cable vs. coax MADI cable
- firmware/driver for HDSP/HDSPe card(s)

I had a similar problem (not exact same) for a big studio client once. There problem there was a fairly long run of coax MADI in a electrical noisy environment. A change to fiber cable solved it all. The problem was worse though. Got static noise bursts one one MADI channel.

Best wishes,
P?l Svennevig

OK, Daniel. Did Matthias also look at it and weigh in with his opinion?  Anyway, next time it happens I hope I catch it before a problem occurs and I'll send you a 1 kHz sine wave. Is there any special test signal that Matthias would like to generate that would be more definitive?

BK

Daniel,

I think it's not really about a frequency dip (we don't expect any additional DSP processing being involved here, do we...?) but about the suspicion that the samples are screwed up concerning their order. This could be made visible with a sine wave, but with all other smooth waveforms as well. Only the waveform of noise is difficult to judge here, unfortunately...

Regards,
Ulrich

Right. Some kind of a multitone test signal?  I'd really like to have MC weigh in here so that we can nail this problem by using a definitive test signal the next time it may occur.  The symptom is frequency response and I think the only possible cause is sample slippage, delay and mixing. PLUS, since it occurs in one channel only, it seems that by using a special test signal, we can measure the delay between the altered and unaltered channels and possible come closer to the cause. I'm also willing to put an oscilloscope on the MADI signal if it will prove useful.

Thanks,

Bob

One of them might be good. I'd like to hear Matthias put the seal of approval on which one he wants to see, as I'd like to get this right next time. The problem doesn't occur but once in a blue moon (thank goodness).

Bob

Ok, so when you get the blue screen of death, do the cards still work?  I have a cd transport connected to a digital input which I route to my monitors via totalmix.  The RME cards have a safe-state, so even if the computer itself it booting, crashing or whatever, the cards just hum along.  I can restart my computer with nothing more than a little click in my otherwise uninterrupted listening.  The reason I mention this is that perhaps this can be avoided by powering the converters down first.  Even if it is a crash, the cards should still afford you the ability to power down the converters before losing the madi stream or WC.

I use Euphonix converters, and the manual is very clear about the power-on sequence and stresses to only power on the units once a valid clock and madi stream have been established.  I suspect (my amateur theory) that it is something to do with the madi stream disappearing and reappearing in not the most graceful of fashions.  This is why I would always just power down the converters first and then turn off the computer, then reboot and then turn on the converters one at a time in order.  I would guess that since madi is basically 56 (or 64) aes streams stacked on top of one another that the "destacking" across multiple converters is causing the stream to be shifted.  If you always turn the converter(s) on after a solid madi stream has been established, I think your woes may disappear.  Just a theory...

In the right channel every second sample is 8 samples too early. You agree?

Regards,
Ulrich

Thats the thing, I'm using totalmix to route a signal in from a cd transport via a digital input on my madi converter.  I route it through to output 1/2, which is my main output to my speakers.  In the event of a crash or reboot, the card continues to function.  The audio still passes even when the boot process is scrolling across the screen.  My thought is that even in the event of a crash, the converters see a valid sync, giving you enough time to shut them down without them encountering the invalid stream associated with a hard reboot.  Then you can safely turn the converters back on almost instantly upon powering up the computer.

Compared to you, I know very little about digital audio, but I'm trying to brainstorm... 

What happens if you cycle the word clock, or just switch clock source to madi and then back?  Does the issue resolve?  Maybe it's something with the external clock being 96k, and the madi being 48k frame with delay compensated converter stacking.  Maybe there is enough jitter (or hardware issue) somewhere to push some of the bits up a sample.  (hopefully you can derive a knowledgeable, technical theory from that...)

I just enjoy troubleshooting I guess.

Mr. Daugherty, I think you're doing very well with your brainstorming.  Well, if the computer gets shut down, then there is no longer any MADI stream. But if all you do is a restart, I think the MADI card stays alive, that's its intent.   I think it's the actual MADI stream that's being shook up, it's the most logical explanation for slipped samples on one channel only.

BK

Actually, the first converter (actually just an AES interface) is the first in line in the MADI to receive signal from the PCI card. I did want to try 96k frame, but the RME guys here want me to keep the situation constant until we can isolate the problem, since it is intermittent. Though I think I now know how to induce the problem (shut down the computer and turn it back on with the interfaces on... though that does not always cause the problem).

Guys, please be aware that I am using BNC T Connectors to distribute word clock to all four MADI interfaces (single termination at the end) because of my paranoia about jitter accumulation. I cannot see the functional difference, and it even seems to me that the T-connector eliminates the possibility that one interface is introducing some kind of delay issue into another. However, even that is a remote possibility since the issue is only on the right channel and I can't imagine how "word clock up" or "word clock down" would prejudice the interface into screwing up only one channel at a time. It would have to be very broken from the start.

Haven't tried any reordering though it would be a ROYAL pain in the ass because every cable is nicely lashed up inside my rack AND I would also have to manually reprogram each of the interfaces and take them off AUTO. I'd rather wait for a verdict and instructions from the RME crew than tortuously go through my own debugging.

BK

-

With no answer, today I had the problem (after a computer crash). Toggling ADC or power on the first converter did not fix the problem. I switched to 96K frame on the peripherals and the PCI card and that fixed the problem. I don't know if for good...

For some reason I had settled on 48K frame due to some other problem I can't remember right now! Are there any down sides to choosing 96K frame?  I can go down to single sample rates and the system will switch automatically anyway, right?
'
BK

Dear Mr. Daugherty:

I don't think we are talking about the same thing. Yes, no matter whether my system is set to external or internal clock, you have to hit PLAY in the DAW in order to switch sample rates on the card. It makes sense. Anyway, I'm glad that 96K frame works well for you, I'm hoping it will for me!
So far, so good.

BK