PlanetZ forums - scopeusers.com

in acpi i have not managed to understand which irq is which.
i see 24 irqs but the real are 16, isnt;t that right?

my scope pro has irq 19 and pulsar2 has irq 20. is there a way to set them have the same irq? or do i have to update to standart pc?

right.

this is what makes problems. there is no advantage to the path that you seek....

and what if i turn to standard pc with core duo6600 and gigabyte 965 dq6??


i ask because there are some issues that i get and i wonder if there is connection to this.

issues like pc restart if i turn off cme uf7 with ableton or some instability with midi of scope, sometimes.

to tell you i always remember that with older mobos midi of scope used to work without probs even without any midi filter.

sometimes also i get lost asio and when i turn off ableton and scope to reload them i get a pc restart.

i set everything to most stable situation in bios, no overclocking, i have 4gb ram kingston running x2 which means in a low mhz setting.

the only thing for sure is that the mobo has free only the first of the 2 pci slots and there must be lots of device turn offs to work without sharing.

these pc restarts are connected to asio loss

the restarts sound like bad hardware. this can happen even with new parts. all new motherboards need lots of things disabled in order to have free irqs, that's just how it works. the newer motherboards should be in acpi, but hey, try standard pc if you like, i would do a complete reinstall if you do, however.......

If you are using the CME usb driver, this will sometimes cause a Windows crash if the keyboard is powered off while an app is using it. You can use just the midi outs if you want to avoid this.
Switching from acpi to standard pc sounds like a lot of trouble for no likely benefit.

/dave

yes, it does matter in which order you shut things down....

For Multiprocessor machines the non-ACPI variant is called "MPS Multiprocessor PC". If you use "Standard PC" with a multicore machine you'll disable a lot of functionality in Xp's kernel & HAL.

However I've successfully used ACPI with my dual-cpu Xeons for years, since Scope 3.1c to be exact. The PCI bandwidth issues you'll experience in ACPI are NOT based on ACPI trying to 'steer' interrupts at the time the OS boots, but rather based on the fact that at the hardware level there are shared IRQ's causing devices to step on each other. This is not normally an issue for typical consumer devices, but ALL dsp cards suffer in this situation (Scope, UAD & Powercore) since they're bandwidth intensive and very picky about PCI latency & IRQ timing issues. The way to resolve this is NOT to remove ACPI but rather to learn a bit about how to disable unnecessary devices occupying IRQ's and how to map your PCI slot IRQ usage. There's a ton of info about this on these forums so just use search.

Disabling ACPI as a 'fix' began with a failed implementation from VIA in their chipsets and became a standard tech response from Creamware/SonicCore who do not have the time, money or energy to teach every one of their users about how IRQs work in a modern computer system (based on 20-30 years of legacy isa/pci technology layered on top of itself). A user who has the time & energy to figure things out will be better served in the long run as it only needs to be learned once! Once the fundamentals are understood later changes to the model are easy to get your head around with a bit of catching up on your reading (and to be honest ACPI has only changed once since its inception).

The active sensing issues are NOT necessarily going to be solved by removing ACPI support, and are *always* best handled by just using a different midi interface. There are single port usb devices available from $75 on up to excellent and still inexpensive options that every studio owner should consider anyway such as the MOTU micro express (which is insanely flexible for the price). If you require a direct connection to Scope from a controller that has active sensing (ie, you want to play scope synths directly rather than routing your midi control through software) then a simple $30 external midi filter is an easy solution.

In the case of your CME, you're potentially just using usb anyway which would require routing your midi through software (a sequencer or midi loopback driver) so active sensing is a non-issue. If you're using usb to the sequencer AND midi to Scope from the same keyboard I hope you're keeping your eye on avoiding midi loops...

i tried mpc multiprocessor update and on reboot i got blue screen
dq6 gigabyte does not have an option other than acpi.

acronis true image saved me.

the usb is the most unstable thing on the board

perhaps the board is faulty or there is a newer bios that works...

i use the latest bios F11 of gigabyte dq6p965 v1.1 and even on 2 3 versions back there was not this option of apm apic. there is only acpi, unless there are hidden bios settings that need some shortcut combination. there are hidden settings that appear by pressing ctrl+F1 concerning overclocking, but hidden settings about acpi... i do not think so.

Sorry I wasn't suggesting you use MPS Multiprocessor PC. I'll rephrase...

ACPI mode is what modern hardware & software uses, Scope is compatible with this.

Scope & other bandwidth intensive devices are sensitive to PCI congestion or poor PCI bus routing. "Other bandwidth intensive devices" includes devices like SATA & SAS Raid controllers, Fibrechannel cards (for high bandwidth network servers), high count audio i/o devices--try putting 3 RME HDSP MADI cards running @ 96khz on a cheap motherboard, and dsp cards like Scope / Uad's and so on. All of these will work best when the hardware is given the proper priority in the system. and reveal limitations in the hardware & software layers they exist in.

A bug in the usb implementation which stalls the PCI bus (AMD's second-gen MPX series of boards), a flawed PCI/ACPI stack altogether (Nvidia, SiS & especially VIA boards from years ago), a poorly integrated PCIe busto memory controller/hub ("north" chip) can also stall the system bus and so on. At the same time even properly implemented systems can be reduced in performance with a poor peripheral attached to that part of the bus. A cheap usb device with poor drivers and quickly thrown together hardware out of generic parts, another bandwidth intensive device sharing the same IRQ (see above).

Some systems will be robust enough that they won't wince even with the same devices you have IRQ sharing issues with, and another might be crippled just by attaching your digital camera when trying to do mp3 playback. Unfortunately it really is hard to know what devices might have limitations that affect you as it's not going to be restricted based on price, brand, component choice and so on, though these things are potential guideposts. I've bought very expensive systems that have wound up having serious flaws, and very cheap hardware that just refuses to quit working no matter what I throw at it.

In the case of Scope we have a large amount of documentation on its issues from the collected experience of its users and the company that creates it. Ie, PlanetZ is a wonderful resource for Scope users. Scope can happily work in ACPI systems with multi-core cpu's and even multiple cpu's with multiple cores, though there are some known bugs that need to be steered around quite often such as active sensing. Oddly enough some people don't experience issues even with that...

So, to get Scope stable it would help to strip things down to be as simple as possible. The shortest explanation is usually given when looking to expend as little energy as possible: disable ACPI. But this is similar to wrapping your arm in gauze when you get a papercut (in my opinion). The real reason that this is suggested is because it unmasks one level of the process, and it's assumed that reveals shared addressing that wasn't obvious with ACPI 'steering' devices to 'virtual' IRQ's so you can move things around. However ACPI isn't really 'virtual' its just a newer mode of addressing. Even non-ACPI systems with 'Plug&Play' enabled in the bios can still perform 'irq steering' (on Standard PC click on a device and see what IRQs are available to be mapped, some devices will show several).

So when using Scope & faced with PCI bandwidth issues you need to move some things around or disable them. Some people just do this randomly 'until it works', and when it does work who could argue?

For example, my current system housing Scope is an older Xeon system with 32bit PCI, 64bit/66mhz PCI (PCI-X), dual channel u160 adaptec scsi controller, IDE, usb, agp and so on. My host card (Pulsar2) is sharing IRQ 18 in Windows with the onboard u160 scsi controller under the ACPI Multiprocessor PC HAL. I experience no issues. In my "DOS mode" list they don't share, and digging further reveals that the actual irq's are listed as PCI Bus 0 - IRQ 18, and PCI Bus 1 - IRQ 18. The u160 scsi controller is on the PCI-X bus and has 533mb/s bandwidth and much faster timing, Scope is running on the 32bit PCI bus with only 133Mb/s. I dug a bit deeper into Intel's errata on the i860 chipset and learned that the PCI-X bus can actually affect the PCI/32 bus's performance under a high load, but it works out like this: over 300Mb/s bandwidth usage on the PCI-X bus reduces the PCI/32 bandwidth to 90Mb/s. 400Mb/s on the PCI-X reduces that another quarter to 60Mb/s and so on. So with 2 drives, 1 on each controller, I'm only pulling about 130Mb/s peak if I were to read from both drives at the same time. This poses no issue for Scope, and the Adaptec drivers & chipset are high enough quality there are no apparent bugs.

Now, someone else on these boards has the same motherboard running under ACPI, but recently solved his crashing problems by disabling the onboard LAN. I have my onboard LAN enabled still and use it constantly, but have no crashes. So there's a non-obvious sharing issue there.

This probably seems OCD to some, but this is what I do personally:
- Avoid setting 'steering' settings in the BIOS as that complicates things.
- boot into a realtime OS (DOS) and run a utility that lists devices attached to the system bus or just hit pause/break during the boot process when IRQ mapping is listed (this happens so fast these days I prefer to use a DOS boot disk on the ultimate boot cd).

Sometimes you'll get a string of data for a device rather than it's reported name, especially with the DOS utilities for probing the system bus. Usually the device id will be present there somewhere, and you can actually compare this to the device id's of items (from their properties panel in the windows Device Manager) to determine what it is.

I actually do this at first during the build process, and try to get things setup as benignly as possible there before I've even installed an Operating System. Since some devices will be glaringly obvious there (3rd party onboard raid or another PCI slot/graphics card sharing with Scope) it's easy to fix them then. I hang onto this chicken scrawl I've put on paper for later...

Once booted into the OS, cross reference devices that share resources there with what ACPI is showing in Device Manager from within windows. If something shares there take note of it. When you experience a problem, reference these 2 charts and move things around appropriately. If you repeat the DOS mapping and record the results (or your POST screen with pause/break) before booting into the OS you'll be able to cross reference that with the resulting ACPI mappings once in windows, shuffling things around until you achieve stability.

The tradeoff here is a bit more up front work to avoid having to randomly move things to every PCI slot just to 'see how it works out'. I'm no fun at the Casino table I guess...or I like to calculate my gambles.

thanks a lot