hulika

Author Topic: emu X not respondin to midi tracks  (Read 967 times)

Offline x_taxi

  • Forum Fanatic
  • ****
emu X not respondin to midi tracks
« on: December 06, 2007, 10:44:32 AM »
hi,

i'm usin emu X on cubase VST 5.1. i load up three instances of emu X, specifically street kits, mo phatt and proteus X composer. all is fine when i'm startin the project. in the middle of sequencin, one or two emu X VST's won't respond to midi tracks. i restart the project. sometimes i get the audio playback functional. it's a hit or miss thing. sometimes i need to restart windows. help! i'm in the middle of a project and losin the audio sporadically cramps my creativity! usin the mouse on the VST keyboard makes a sound though.

my system specs: amd x2 5000+, 3 gb ram usin the 3g/ switch, windows xp sp2, msi neo k9n, sata II drives, 1820m, patchmix v2.0 beta

by the way, it also happens on samplitude v10 even with only one instance of emu X, with the added headache of lost asio buffers. so i decided to stick with cubase VST for emu X. i love the samples, but it's very flaky.

anything i'm missin here? thank you.

:) :) :)

(posted the exact same post at the productionforums)
:razz::razz::razz:

Offline KitC

  • Prime Moderator
  • *****
Re: emu X not respondin to midi tracks
« Reply #1 on: December 06, 2007, 11:05:35 AM »
If you hear a sound while moving a mouse, it's usually indicative of IRQ sharing problems, especially with the vidcard. If you posted in the Production Forums, you know we will ask you about your IRQ table. Have you also updated your video drivers recently?
Sonar 4.04PE/5.2PE/7.02PE/8.31 PE, Project 5 v2.5.1, EmulatorX 1.5, Cubase SL2, Ableton Live 7.14,  Intel Q6600 MSI P43 Neo 4Gb Crucial Ballistix Tracer DDR2-800, Emu 1820m, Yamaha DSP Factory, Terratec DMX 6fire

Offline KitC

  • Prime Moderator
  • *****
Re: emu X not respondin to midi tracks
« Reply #2 on: December 06, 2007, 01:42:46 PM »
Unfortunately, you will really have to move the card using the Production Forum's famous "virgin re-install routine". There's no avoiding it. Most soundcards really require their own unshared IRQ in order to function without glitches of any kind. Some of the biggest causes of pops and crackles are sharing with video, ide/sata controllers, and to a lesser extent, usb/firewire/network controllers - practically every onboard device on a motherboard. Rule of thumb is that in order to free up mobo resources, turn off devices that you do not use. Good examples are LTP and COM ports since most devices are usb anyway. Turn off firewire and networking if you don't use either.

I checked the K9N Neo manual and very atypical of MSI, they did not include pcie irq allocations, only pci. If I were to go by usual mobo hardwiring convention, the pci slot closest to the vidcard slot usually shares an irq with video. That leaves the other 2 slots possibly sharing with usb, firewire or sata. I'd recommend moving the Emu to the 2nd or 3rd pci slot, just follow the virgin reinstall routine that we outlined over at the other forum.
Sonar 4.04PE/5.2PE/7.02PE/8.31 PE, Project 5 v2.5.1, EmulatorX 1.5, Cubase SL2, Ableton Live 7.14,  Intel Q6600 MSI P43 Neo 4Gb Crucial Ballistix Tracer DDR2-800, Emu 1820m, Yamaha DSP Factory, Terratec DMX 6fire

Offline KitC

  • Prime Moderator
  • *****
Re: emu X not respondin to midi tracks
« Reply #3 on: December 06, 2007, 04:54:27 PM »
The Emu does it's mixing and fx with the onboard dsp and any irq conflict will cause a break in communications with the cpu since you have 2 (or more) devices vying for a share of the cpu's time.

Think of IRQs as highways that can support a limited amount of data. In your case, you have a high output device on your particular lane (the video card) sharing the same lane with another high output device (Emu). Audio is VERY sensitive to breaks in the data packet stream and if the buffers don't replenish quick enough, you will get the common problems of popping, clicking and other audio artifacts. Video, OTOH, just loves to take control of the lane it's in - most video card driver programmers think of every conceivable means to pack a LOT of data into the pipeline going to the cpu; and they even cheat by 'fooling' other devices into giving up their share of cpu time. As luck would have it, your Emu shares with your 7200GS, not a good combination.

Why do the other instances only get affected? The way I see it, the first instance is sending out just the right amount of data packets that fits in the spaces allowed it by the video card data stream. Adding another instance just overwhelms that stream and guess who takes control of that IRQ? You guessed it... the video card. AGP mobos had PCI Latency Tool so that IRQ latencies (not to be confused with audio latency) could be adjust so that a majority of onboard devices would 'sync' the the data highway's 'speed' and, like highway onramps, just merge perfectly with the data stream. The advent of pcie video cards (and other pcie devices) has made PCI latency adjustment impossible for now due to reasons that are too complicated for me to explain in layman's terms. Suffice to say, the door is closed to end user adjustment of PCIE bus latency.

Btw, not only Emu is affected by the need for a solo IRQ. As a matter of fact, ALL soundcards are recommended to have their own IRQ if you just want plain stable operation. Some other card's driver can do a better job with sharing; soundblasters, for ex., can share with video, but the blaster's emphasis is mostly for gaming. In most gaming benchmarks, you will see that adding a blaster improves on framerates; that means that the blaster intentionally takes 2nd seat to video, something you wouldn't want your DAW to be in. It's also one of those reasons why most DAW builders don't recommend putting that latest 8800GT into your DAW machine.

hth,
Sonar 4.04PE/5.2PE/7.02PE/8.31 PE, Project 5 v2.5.1, EmulatorX 1.5, Cubase SL2, Ableton Live 7.14,  Intel Q6600 MSI P43 Neo 4Gb Crucial Ballistix Tracer DDR2-800, Emu 1820m, Yamaha DSP Factory, Terratec DMX 6fire