Hello,

you did not mention the basic stuff: had MADI card and 9652 been synced by a word clock connection (BNC cable MADI out to 9652 in)? That would explain the problem perfectly...

Hello,

nice to see you here...

There is no general problem with the use of more than one HDSP card. This is likely to be a problem of an individual configuration.

Hope you won't mind the comment, but this setup does not provide full redundancy in case of a computer crash. You could connect the Micstasy to the 648, and split the signal to several destinations with the 648's matrix, i.e. to the MADI card and the Tascam.

Are you referring to actual playback of the recorded signal during the recording, or just monitoring (hardware/software)?

Regards,
Daniel Fuchs
RME

Hallo Herr Fuchs, hallo Herr Carstens,

now, since everybody is asking detailled question, here the full story:

As long as you don't have a MADI-equipped DA-converter, you need the RME-648 for converting the signal from MADI to ADAT an so on. This is what we did. The problem was that we couldn't get in contact with the Micstasy via RME MIDI-remote. I don't know what the reason was (possible ID-conflicts between the 648 and the Micstasy?). Anyway we decided to route the MADI-out of the computer into the RME 648. This worked well although it was clear to me that in the case of a computer crash the backup signal would be lost.

What I want to point out is that also with only two HDSP-9652 in the one computer (not MADI-card involved) we had during the last months a lot of problems with Sequoia and the RME cards. The standard message Sequoia gave was: lost ASIO-buffers.

So my question is: where we have to tweak the system? On the RME-driver, on the Sequoia preferences, on both or on the computer hardware, i.e. PCI-slots)?

Or will possibly the new PCI-e architecture solve the problems?

Thanks and have a nice Sunday

Dear Herr Fuchs,

1. one of our Micstasy has the firmware 1.3. Can you tell me what we have to do to get the actual firmware 2.? into it?

2. Originally the 648 was after the Micstasy and before the recording computer. Since I had problems talking in this configuration to the MADI via MIDI remote I changed the routing as follows:

Micstasy directly to the recording computer via MADI
MADI OUT of the computer to to the 648 for routing the MADI-Input of the computer to the 648.

3. This happens also with Sequoia 8.31. We have tried various setups of the RME's latencies. No improvement.

4. The Mainboard is an INTEL. I don't know the chipset right now. But it has only one dedicated IRQ on the PCI-slots. All the others are sharing their IRQ with other components. So changing the PCI slots really doesn't help.

5. Thanks for the hint.

No exchange of EPROM at Tritonus possible?

...but after the update you have the chance to send talkback (or whatever) over Madi to the AES/ADAT out of the Mixtasy ;-) really nice feature!!!

PS: Andreas, nice to see you here - all the best from Bremen

Hello Mr. Neubronner,

apart from problems maybe caused by the usage of multiple cards (where several reasons can be given for(Mainboard,Chipset, setup ..etc.)), I would like to give some comments/suggestions to your "setup".

As I understand your description, you like to connect 1 (or 2, or more) Micstasy(with MADI-Option-Board) to your Sequoia-PC, equiped with the HDSP-MADI card.
Also you like to record the Micstasy`s signal on your Tascam MX2424 for Security-BackUp.
(Therefore the MX2424 should receive the Micstasy`s signal direct)
Once you need to monitor the signal you get from Micstasy`s, and also you maybe need to monitor the Sequoia (Playback) mixer-output. Your ADI-8DS is needed as DAC for your monitoring.

Your entire setup should be connected in this way:

1. Connect HDSP-MADI-Output to Micstasy-MADI-Input.
This allows you to send the (Midi)remote signals from DAW, via MADI, to the Micstasy.

2. Connect Micstasy`s MADI-Output to ADI-648-MADI-Input.
(In case of more than one Micstasy, first connect the Micstasy Daisy-chain, than to ADI-648)
This sends the audio signals, but also the remote feedback of Micstasy to the ADI-648.

3. On ADI-648 the audio signals received from Micstasy via MADI, once need to be routed to (desired) MADI-Outputs of the ADI-648 , and also needs to be routed to the (desired) ADAT-Outputs of the ADI-648.
(This can be done very flexible by the 16x16 Routing-Matrix of the ADI-648)

4. Connect the MADI-Output of ADI-648 to the HDSP-MADI, this way you get the Micstasy audio signals into the Sequoia DAW.

5. !!! Connect the MIDI-Output of the ADI-648 to MIDI-Input of the ADI-648, by a standard MIDI-cable. Now you also receive the remote feedback of the Micstasy at the DAW (via HDSP-MADI)
This is neccessary because the ADI-648 does not send the "MADI-embedded-MIDI" signals received on its MADI-Input to its MADI-Output!

6. Connect the desired ADAT-Outputs of the ADI-648 to the MX2424, to receive the Micstasy`s output signal.

7. Route the Sequoia Mixer-Output to HDSP-MADI-Outputs e.g. Channel 49 to 56.
Now the Sequoia mixer outputs are going first to Micstasy`s MADI-Input, on Micstasy`s MADI-Output you get these channels unaffected and so they will be received on the ADI-648 MADI-Input. Route these MADI-Input channels of the ADI-648 to a desired ADAT-Output of the ADI-648 and connect the ADI-8DS for DAC (Monitoring).
(Remark: here the MADI-channels 49 to 56 are unaffected since those MADI-Channels are not used by a Micstasy (says no Micstasy is configured to Id 07 = Channel 49 to56)see Micstasy manual > Id configuration)
Now you can use all the Sequoia monitoring functions!
(Routing the channels this way, adds only 3 (three) samples delay by each Micstasy in the chain)

!! There are good chances to run the entire described setup with no additional separate wordclock cable connections! Just select the "correct" sync-setting on each single device.

This all should "run" also with Micstasy Firmware 1.3.
There is one issue in Firmware 1.3 . The "Bank-setting" of Mictasy needs to be Bank 01, other Banks will not work. (This is fixed in Firmware 2.0)
(So you maybe could (should) send the Micstasy for Firmware-Update while your next holiday, to get the new great features)

BTW: since beginning of April latest Driver version 3.04 for HDSP-Cards is available. Download drivers and firmware from the RME web-site.

As you remarked to Frank Fabian "still miss the redlight"; with the RME MADI-embedded-MIDI you can send MIDI events from your HDSP-MADI DAW to the MIDI-Out of the Micstasy, why not using this to switch a redlight?

Cheers,

Joram

Hello Mr. Neubronner,

I am afraid that changing the interrupts will not change a lot. With APIC under XP you have little influence what IRQ is mapped anyhow, and as long as Windows doesn't think there is a problem it won't do it for you. The only remaining possibility actually is tweaking the PCI latency, if possible. I am however not an expert on PCI latency becaus ei never had a problem with that.

The reason for the 300ms offset was already explained by Matthias. Maybe let me stress that it is really important that the sync is persistent. If one card has lost sync, the only way to get it back is restarting the ASIO loop. One card out of sync can cause LAB.

Edit: I just see that you have apparently worked with Windows drivers in the mixed MADI/9652 setup. My last impression was that such a setup is not so good, running so many devoces in parallel work more effficiently under ASIO, but of course is technically not possible because the cards don't share drivers (at least I not that I knew of).

Under different conditions (stable sync): As far as the LAB are concerned, increasing the ASIO buffer normally fixes the issue indeed.

If your system is suffering from a PCI bandwidth problem can be examined by a simple test with DigiCheck. Simply open all ASIO devices and send some test tones to some of the channels. If you don't see any artefacts or signal dissipating to other channels in TotalMix, everything should be alright. Also check the CPU load.
You can additionally cause load to the system by copying large files in the background.
With a grain of salt, this simulates the basic functions of a generic DAW.
With these methods youy should be able to detect the bottleneck on your system, and then see further.

If you have such issues in the field, disabling the waveform drawing during recording in Sequoia will give you 20% more safety overhead. I do that sometimes when there are issues or CPU load is too high.

Good luck with fixing.

Best regards from Vienna,

Sebastian Gabler