• Registered: 2012-04-04
  • Posts: 3

Topic: Multiple Multiface I's. One works, the other doesn't??

hey!
done extensive searches and can't find an answer to my problem...


Running win 7 32bit with 2 rme Multiface 1's with the PCI card. both rev 1.8.

one works, one doesn't (red host error). It always seems to be the card in the bottom PCI of my machine (done all the usual checking firewire cables, new drivers, older drivers, different slots, flashing the cards)

also tried the cards in other win7 32bit machines, and the same problems occurs...

am I doomed?

also Total mix and DSP settings can see both cards. DSP gives an I/O box error and blank fields with the SyncCheck, also no default sample rate (blank field) and if I output quicktime to the (not working) multiface, no meters light up on total mix.

Everything works as normal otherwise

this is annoying!!!

Please help!

  • Jeff
  • Jeff
  • Moderator
  • Offline
  • From: USA
  • Registered: 2007-05-21
  • Posts: 4,684

Re: Multiple Multiface I's. One works, the other doesn't??

If one Multiface works on both cards, and the other works on neither card, then odds are good that the non-working one needs service.

Regards,
Jeff Petersen
Synthax Inc.

Jeff's Website

  • Registered: 2012-04-04
  • Posts: 3

Re: Multiple Multiface I's. One works, the other doesn't??

sorry I dont think I explained it clearly enough, my bad....

both multiface boxes work with both cards, but if BOTH are in my machine at the same time, one will not work, always the one occupying the bottom PCI slot.

They both work in my other machine now, so I know its nothing to do with the boxes OR cards.

my machine has a asus m4a79xtd evo

can anyone suggest any solutions??

  • From: Germany
  • Registered: 2007-04-10
  • Posts: 9,854

Re: Multiple Multiface I's. One works, the other doesn't??

Can you test the one connected to the bottom card with external power?


Regards
Daniel Fuchs
RME

Regards
Daniel Fuchs
RME

RME Support's Website

5 Reply by Burky86 (edited by Burky86 2012-04-10 22:28:10)

  • Registered: 2012-04-04
  • Posts: 3

Re: Multiple Multiface I's. One works, the other doesn't??

What psu should I use?

Found a 12v 1000mA power supply. Tried it and it gives power to the unit, but I/O box still reads disconnected??

  • Registered: 2007-07-16
  • Posts: 45

Re: Multiple Multiface I's. One works, the other doesn't??

The power supply specs are listed on the power supply unit aren't they?
If the multiface on the bottom pci slot will not work regardless of the unit used, my choice is an IRQ interrupt conflict. That is if you are using PCI slots. You need to move or disable some other devices or better yet see if the bios will let you change some permanently (have no idea if this is possible with M$ 7).. Disable parallel port, serial port and anything else unnecessary while in the bios. Don't forget to F10 to save your changes.

GNU/Linux
  • Registered: 2007-07-16
  • Posts: 45

Re: Multiple Multiface I's. One works, the other doesn't??

I would like to add, there used to be information about PCI slots, IRQs and conflict on the Internet but it wasn't that well known even when it was relevant. I don't know if it is still there now..
Basically, IRQs have priority. 9 is the IRQ which is available to users and gets the highest priority. I think 5 being the least in the old system of 15 interrupts. As computers modernised, then 21 (?) interrupts became available. After that with multi-core and multi cpu systems many more IRQs became available. But in the old days with 15 IRQs the generally available IRQs were in order of priority of 9,10,11,4,5 (14, 15 were dedicated to ATA devices). The thing with PCI slots on computers is they were often nearly predicable with the third PCI slot down being the only one which could access IRQ 9. I know this sounds very folklore-ish and it was a bit like that. The first slot often shared the IRQ with the AGP device and I can't remember what happened to the second slot but the third slot was where IRQ 9 was. But the big trick in juggling IRQs was trying to get the audio device high up on the chain but also on it's own. That is, not sharing an IRQ with another device mainly not the AGP device. Now, RME devices were able to share IRQs from early days (some devices couldn't share) but that didn't mean you necessarily want to be sharing the IRQ. All of this was to get the highest priority and thereby the lowest reliable latency from you audio device.
If your system is working well I would not bother with any of this, you can waste days farting around, but if your system is not working then it's useful to know.

GNU/Linux