The small difference maybe to understand is that these unshared IRQs do only relate to the physical PCI structure, not to the logical structure ACPI imposes. As a result, Windows doesn't see that and Windows HAL might very well share that IRQ with a different ressource, such as USB that isn't PCI attached altogether.
Now, you also got to live with the situation that you won't find any unshared IRQs on current system PCI slots anymore. So, moving around of cards in PCI slots is maybe not the appropriate method anymore, therfore also not to worry about in what slot you stick it in.
Modern chipset layouts draw upon working Chipset drivers more than ever before, especially ACPI does. You can not get away here with assigning dedicated interrupts because modern systems will not let you. There are simply too many components in modern chipsets. (Have a look on an average current multiprocessor system in MSinfo32....)
The remaining options are simply to update the chipset drivers, avoid unnecessary PCI components altogether (ASUS i.e. still implements PCI attached SATA controllers!!!), and if all that doesn't help fiddle around with PCI timing, assuming that RME has doen the job right to write the driver wich we all do from good history. :-)

Greetings,

Sebastian Gabler

I totally agree. Anyway: fact is that all of our systems where the HDSP-9652-card is in a dedicated PCI-slot (means 1 IRQ only - not shared) we don't have problems at all.

The possibly best solution for more than 24 input is to install a MADI-card and the ADI-648 converter for any MADI-ADAT conversions. This configuration has been tested by us and it works reliable.

Thanks for the hints for testing procedures.

All the best regards to Vienna from Vienna

Andreas 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

I've spent some hours to sort out, what the pci situation on a regular "mainstream" motherboard is:

1: it's hard to find out which pci-slot shares its IRQ with other compoments.

2: on all three boards (two of MSI, one of Intel) there was only one PCI-slot which has its own dedicated IRQ

3: turning off some of the integrated peripherials (such as parallel port, serial port, Firewire) doens't necessarely free more resources for the audio-card.

4: Only turning off the graphic card :-), the network chip :-) or the USB would free IRQ which otherwise would share its IRQ with the according PCI-slot. But this is not an real alternative :-)))

5. I know that this is depending on the type and the manufactor, but it seems to me, that because there are some many compoments on a moddern motherboard that it's quite hard to get dedicated free PCI-IRQ's on almost every motherboard of today's releases.

Some my question is: are there any recommandations of manufactors or types or technologies (like chipsets etc.) what helps finding out of this jungle?

Another question: does it help in general to increase the buffer size in the RME-driver to diminish the risque of "Lost Asio-buffer" messages for instance in Sequoia?

Any help is apprectiated

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

(only valid for shipments from within Germany)

Regards,
Daniel Fuchs
RME

Sorry, no... No EPROM.

Can you send my the exact address?

Danke, Herr Fuchs.

Regards,
Daniel Fuchs
RME

Best regards to my home town, Fabian!

Sorry, no... No EPROM.

...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

Regards,
Daniel Fuchs
RME

Regards
Daniel Fuchs
RME

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.

What's the Micstasy's firmware version (displayed at startup)?

Is that output from the computer a mixed-down signal for monitoring? Or are you routing individual channels to the ADI-8 for external mixing and monitoring? If so, inserting the 648 between Mictasy and MADI card will allow you to split the sigal three ways, to the PC, the ADI-8, and the backup recorder.

Again, not a general issue. Can you provide some details about the PC? Does this also happen with Sequoia 8.x? Does it happen at higher latencies?

I assume you know www.musicxp.net. Switching PCI slots sometimes helps. A different mainboard may or may not.

Not necessarily, at least not just exchanging PCI for PCIe cards on the same system. It's not something that ca be answered with a definite yes or no...

Regards,
Daniel Fuchs
RME

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