Posted: Wed Mar 20, 2002 1:56 am
I've now tried my Pulsar I on a dual p2-300, dual p3-600 and now a dual xeon 1.8 with a separate 64bit pci bus for my scsi drives. I'm unfortunately going to repeat what we already know, that a dual processor system is not a stable platform for the Pulsar. I'm really curious as to why...
I've used several methods for controlling cpu affinity and priority level for both my audio applications and the pulsar.exe program, and while there's some improvement
I still experience quite frequent copy protection violations and occasional pci errors. Let's deal with each of these independantly.
With copy protection violations, I've noticed that when first starting the app I will almost always get copy protection violations if I have *not* set cpu affinity to the pulsar.exe app. When I have set the affinity before starting, I would say I have about a 20-30% chance of failing on loading the first project. I occasionally even get a failure on the board itself. Sometimes even loading an insert without stopping playback in my sequencer can cause a copy protection error. I do write-protect the cset.ini file, and waiting for the pulsar app to finish it's current task before loading something else or manipulating anything seems to help prevent the errors.
The PCI errors I get, don't seem to directly correlate to what I've read here about pci bandwidth issues. I'm able to load up to my dsp limit in Masterverbs (4, 5 causes dsp overload error) when using the dynamic mixer with each channel of audio being driven as a 24bit asio stereo channel from within the sequencer, and leave this running for quite some time without experiencing any errors. And yet, when I'm pushing the system closer to 60% or higher cpu usage, and I'm doing a complex arrangement using say, the hummel bluesynth and the hummel miniscope with a few filters, and overdrive, a few compressor/limiters and 2 or 3 tracks of midi along with a few automated parameters, I will recieve pci errors. Notice I'm not using any of the samplers or reverbs in the pulsar at this point, although i'm not sure what other devices require a lot of access to main system memory. I have noticed, however, that midi automation seems to cause the pci errors more often than anything else I do. Changing a parameter even with the mouse seems to cause problems too occasionally, although overall the pulsar is a LOT more stable when running in the foreground rather than behind my sequencer.
All in all, I really don't want to give up my pulsar, and I am even considering stepping up to a Pulsar 2 to gain more dsp capacity (possibly retaining the pulsar 1 along with it if that proves to be stable enough), and yet I regret that the Pulsar.exe app is not written to properly take advantage of a multithreaded multitasking environment. I do understand that there is no benefit for the pulsar itself from this type of setup, but my own experiences in Cubase and Nuendo have shown that the additional cpu helps a great deal, something which I also know from my backgrounds as both a 3d animator and an application developer. At this point, I'm faced with needing another machine dedicated entirely to the Pulsar, which I know is a path that several people have taken. However, that effectively doubles the cost of a Pulsar 2. I am NOT sure that a Pulsar 2 wouldn't fix the problems entirely even on my current dual xeon, however. I have no idea whether they use the pci bus more efficiently as has been suggested by a few posters on this forum before.
Basically, I've found the pulsar to be extremely stable (once a project is loaded and has passed the copy-protection acid test) when used by itself or as the foreground app with very little interaction. But once I begin to multitask, loading or deleting modules when playing back audio, or even just turning knobs onscreen or driving them with midi automation, I run the risk of a pci error dialog asking for a reset of the pulsar's dsp's.
I've used several methods for controlling cpu affinity and priority level for both my audio applications and the pulsar.exe program, and while there's some improvement
I still experience quite frequent copy protection violations and occasional pci errors. Let's deal with each of these independantly.
With copy protection violations, I've noticed that when first starting the app I will almost always get copy protection violations if I have *not* set cpu affinity to the pulsar.exe app. When I have set the affinity before starting, I would say I have about a 20-30% chance of failing on loading the first project. I occasionally even get a failure on the board itself. Sometimes even loading an insert without stopping playback in my sequencer can cause a copy protection error. I do write-protect the cset.ini file, and waiting for the pulsar app to finish it's current task before loading something else or manipulating anything seems to help prevent the errors.
The PCI errors I get, don't seem to directly correlate to what I've read here about pci bandwidth issues. I'm able to load up to my dsp limit in Masterverbs (4, 5 causes dsp overload error) when using the dynamic mixer with each channel of audio being driven as a 24bit asio stereo channel from within the sequencer, and leave this running for quite some time without experiencing any errors. And yet, when I'm pushing the system closer to 60% or higher cpu usage, and I'm doing a complex arrangement using say, the hummel bluesynth and the hummel miniscope with a few filters, and overdrive, a few compressor/limiters and 2 or 3 tracks of midi along with a few automated parameters, I will recieve pci errors. Notice I'm not using any of the samplers or reverbs in the pulsar at this point, although i'm not sure what other devices require a lot of access to main system memory. I have noticed, however, that midi automation seems to cause the pci errors more often than anything else I do. Changing a parameter even with the mouse seems to cause problems too occasionally, although overall the pulsar is a LOT more stable when running in the foreground rather than behind my sequencer.
All in all, I really don't want to give up my pulsar, and I am even considering stepping up to a Pulsar 2 to gain more dsp capacity (possibly retaining the pulsar 1 along with it if that proves to be stable enough), and yet I regret that the Pulsar.exe app is not written to properly take advantage of a multithreaded multitasking environment. I do understand that there is no benefit for the pulsar itself from this type of setup, but my own experiences in Cubase and Nuendo have shown that the additional cpu helps a great deal, something which I also know from my backgrounds as both a 3d animator and an application developer. At this point, I'm faced with needing another machine dedicated entirely to the Pulsar, which I know is a path that several people have taken. However, that effectively doubles the cost of a Pulsar 2. I am NOT sure that a Pulsar 2 wouldn't fix the problems entirely even on my current dual xeon, however. I have no idea whether they use the pci bus more efficiently as has been suggested by a few posters on this forum before.
Basically, I've found the pulsar to be extremely stable (once a project is loaded and has passed the copy-protection acid test) when used by itself or as the foreground app with very little interaction. But once I begin to multitask, loading or deleting modules when playing back audio, or even just turning knobs onscreen or driving them with midi automation, I run the risk of a pci error dialog asking for a reset of the pulsar's dsp's.
