SFP's Mixers' GUI eating CPU
I've noticed that since long on my system, but is this normal? Is there something wrong with CW's level's GUI? Is it my videocard or it's settings?
Ie. Reason's playing a song using 12% CPU. When I open a view for one of the mixers in SFP, CPU usage goes to 50-60%. My full setup is here.
Ie. Reason's playing a song using 12% CPU. When I open a view for one of the mixers in SFP, CPU usage goes to 50-60%. My full setup is here.
more has been done with less
https://soundcloud.com/at0m-studio
https://soundcloud.com/at0m-studio
I' ve noticed the same behavior. I have an intel agp graphic card (8 meg memory) and when my cpu at cubase is at 50% the system get a little jerky when the mixer is opened and the mouse pass over it.. (thats on a 1024x768 24bit disply-if i use 16 bit the problem is bigger! i don't know if it is a graphic card problem (maybe we should take off the harware accelaration in graphic display properties (i haven't tried it) if u find a solution (a better card maybe?) please inform me...
For some reason our Microsoft friends asume that all the PC users want perfect video resolution, over another things like System stability (little detail).
The result is that video has more than REAL TIME actualization, and of course absolutely priority.
If you push your PC to the limit, you´ll notice that the AUDIO can be cut, or bad heard, but the level metters will never stop moving...
Thats one (there are a lot more) of the things that show us that no one Windows version was made for professional Digital Audio processing.
What Microsoft calls "Multimedia" means using ICQ and a webcam, at the same moment that we hear some MP3 with Winamp.
A solution can be geting smaller Video cards, like 8 MB or 16MB ones...1X AGP...
DJATWORK
The result is that video has more than REAL TIME actualization, and of course absolutely priority.
If you push your PC to the limit, you´ll notice that the AUDIO can be cut, or bad heard, but the level metters will never stop moving...
Thats one (there are a lot more) of the things that show us that no one Windows version was made for professional Digital Audio processing.
What Microsoft calls "Multimedia" means using ICQ and a webcam, at the same moment that we hear some MP3 with Winamp.
A solution can be geting smaller Video cards, like 8 MB or 16MB ones...1X AGP...
DJATWORK
Luis Maria Gonzalez Lentijo
DjatWork! Optimizaciones
Buenos Aires
Argentina
DjatWork! Optimizaciones
Buenos Aires
Argentina
The bus mastering thing of AGP cards is very important. A bus master can transfer over a bus as long as it needs. Other devices will have to give priority. Matrox allows their cards to be set to be no bus master, which decreases video performance but improves stability on other devices.
DJATWORK, if you'd take a 1x AGP card, it would have a lower tx rate and will occupy busses longer, not? I always thought AGP 4x could transfer data 4 times as quick as AGP 1x, thus making more available for other devices on the PCI bus.
About video memory: The Bigmixer took up to 64-80MB of RAM, depending on how much of the panels were cached into the RAM. It's cached into RAM from a drive, and into video memory from the RAM. Video RAM is much more efficient because dedicated for the video DSP, but I have no monitoring possibilities for video RAM (ie. onboard Matrox G450). So the more (very expensive compared to RAM) video RAM you have, the less your video RAM will need to be updated. The less PCI traffic. The more stability, and the lower the latency can be set of ie. audio drivers.
DJATWORK, if you'd take a 1x AGP card, it would have a lower tx rate and will occupy busses longer, not? I always thought AGP 4x could transfer data 4 times as quick as AGP 1x, thus making more available for other devices on the PCI bus.
About video memory: The Bigmixer took up to 64-80MB of RAM, depending on how much of the panels were cached into the RAM. It's cached into RAM from a drive, and into video memory from the RAM. Video RAM is much more efficient because dedicated for the video DSP, but I have no monitoring possibilities for video RAM (ie. onboard Matrox G450). So the more (very expensive compared to RAM) video RAM you have, the less your video RAM will need to be updated. The less PCI traffic. The more stability, and the lower the latency can be set of ie. audio drivers.
more has been done with less
https://soundcloud.com/at0m-studio
https://soundcloud.com/at0m-studio
Thats theory. In the practice, the newest Video Card, the more colors, millions of triangles, etc etc etc... They ask more from DX drives, and all that modern and fast improvements are compensated wit better video quality and more PC compensating...
with a 4 or 8 MB graphics card, I could see all the colors that I needed...
other good thing is choosing 16 bits display and no more.
Sometimes theory does not correspond with reality.
For example, I had better results in a lot of PCs under win 98, with less or none video acceleration. The display was very slow, and the actualization bad, but I had more channels in Cubase without clicks, craps or digital error noises... (IE: intel 815, celeron 1ghz, 8mb video card)
DJATWORK
with a 4 or 8 MB graphics card, I could see all the colors that I needed...
other good thing is choosing 16 bits display and no more.
Sometimes theory does not correspond with reality.
For example, I had better results in a lot of PCs under win 98, with less or none video acceleration. The display was very slow, and the actualization bad, but I had more channels in Cubase without clicks, craps or digital error noises... (IE: intel 815, celeron 1ghz, 8mb video card)
DJATWORK
Luis Maria Gonzalez Lentijo
DjatWork! Optimizaciones
Buenos Aires
Argentina
DjatWork! Optimizaciones
Buenos Aires
Argentina
There are no differences between agp 1x & 4x for working in audio apps, they only differ in methods for transferring textures and geometry information to the cards (which isn't YET used in MS OS's). A 4x card MAY be preferable from the standpoint of driver stability however.
AGP does help PCI bandwidth tho in that it has it's own 66mhz connection to the "North" or "ICH-1" chip, bypassing the PCI bus (and the "South"/"ICH-2" chip) completely. On SOME (old) systems clocking your card down to AGP-1 seems to clock the AGP bus down to 33mhz, even if it's only due to the card not being able to recieve data any faster than that.
AGP Bus Mastering is indeed the culprit if you're having problems as a result of your gfxcard, and disabling it can help tremendously if your card is causing problems. Unfortunately most manufacturers don't offer the ability to do this anymore (and the ones that do like Matrox use settings in win.ini and the like, I'm not sure if these apply any longer.)
Running your gfxcard in 16bit mode helps, as does picking a resolution that offers enough space to work in, while still keeping performance in check. Personally on a 1.8Ghz machine I'm able to run 1600x1200 or higher @32bit on an older Geforce2 Ultra without any noticeable problems, but I DO notice that when switching over to SFP from Logic or EXPECIALLY Cubase SX it takes a while for SFP to 'catch up' with what's going on. I'm generally only running ~300+ MB ram usage when I work on tunes, but I'm wondering if splurging on another half gig of ram would stop SFP's interface from being cached....
AGP does help PCI bandwidth tho in that it has it's own 66mhz connection to the "North" or "ICH-1" chip, bypassing the PCI bus (and the "South"/"ICH-2" chip) completely. On SOME (old) systems clocking your card down to AGP-1 seems to clock the AGP bus down to 33mhz, even if it's only due to the card not being able to recieve data any faster than that.
AGP Bus Mastering is indeed the culprit if you're having problems as a result of your gfxcard, and disabling it can help tremendously if your card is causing problems. Unfortunately most manufacturers don't offer the ability to do this anymore (and the ones that do like Matrox use settings in win.ini and the like, I'm not sure if these apply any longer.)
Running your gfxcard in 16bit mode helps, as does picking a resolution that offers enough space to work in, while still keeping performance in check. Personally on a 1.8Ghz machine I'm able to run 1600x1200 or higher @32bit on an older Geforce2 Ultra without any noticeable problems, but I DO notice that when switching over to SFP from Logic or EXPECIALLY Cubase SX it takes a while for SFP to 'catch up' with what's going on. I'm generally only running ~300+ MB ram usage when I work on tunes, but I'm wondering if splurging on another half gig of ram would stop SFP's interface from being cached....
I think that here we have two branches...
AGP/Graphics etc or...
CW GUI.
I think using the common sense that if Steinberg can make a "mixer" with 30 level meters along my 2 screens, so CW SHOULD be able to do something like that.
May be the resolution or the real time level reaction is not the best in Nuendo or any other software, but trully is not a big problem for me. I only want to know if i´m close to a clip in each channel.
AGP/Graphics etc or...
CW GUI.
I think using the common sense that if Steinberg can make a "mixer" with 30 level meters along my 2 screens, so CW SHOULD be able to do something like that.
May be the resolution or the real time level reaction is not the best in Nuendo or any other software, but trully is not a big problem for me. I only want to know if i´m close to a clip in each channel.
While I'd agree that the SFP Gui still leaves a bit to be desired, the metering issue has come up before on these forums & it's not just an issue of the speed of their gfx libs.
A sequencer has the ability to pre-process a great deal of data to make sure it's all 'aligned' at the time it exits the program, and the meters are a part of this game. Creamware currently doesn't have the same luxury (access to the data before it has to crunch on it).
A better comparison might be with the speed of the input monitoring in SX or Logic (or sonar). After doing that I can still tell it's lacking, but there's more to it still than latency issues & creamware's gui. Also seems like it's taking occasional 'samples' of the current levels and using that to drive the meter display. In other words, the updates tend to be 'jerky' & 'spaced out' a bit.
--
For solutions to the overall speed of the metering in SFP mixers?
-
Increase the speed of the creamware gui. They've already made strides in this direction but still have a ways to go. At the risk of being hopelessly redundant I will agree that we continue to discuss this often. Let's hope they get it worked out sooner rather than later.
Second, I'm Just Guessing, but based on the amount of modern "geer-hoors" touting latency figures rather than vintage synth kit lists latency is generally an indesirable thing. The pulsar doesn't have the same access to memory that Steinberg does (remember those pesky pci bus issues?), but I would hazard a guess that it's possible to have an option to 'increase meter accuracy'--ie, precache more data to allow the meters to be precalculated and displayed as needed at the cost of even more pci bandwidth. Not sure how desirable this is tho...?
As for the 'jerky' updating (sampling rate that I can see with my eye), having another option to increase 'sampling rate' or 'meter precision' could work. Since it might be possible to achieve this without resorting to any caching of data (and it should-tho it might cost in dsp) this would be the most likely candidate to increase the performance of the meters next to just speeding up the overall gui. Since it costs in dsp much like the SFP mixer option to 'PhaseComp'ensate, it could also be an option to be enabled on demand where needed. Of course this might be a total pain to impliment and screw up the timing of many current atoms for sfp but I know nothing about that end of things.
A sequencer has the ability to pre-process a great deal of data to make sure it's all 'aligned' at the time it exits the program, and the meters are a part of this game. Creamware currently doesn't have the same luxury (access to the data before it has to crunch on it).
A better comparison might be with the speed of the input monitoring in SX or Logic (or sonar). After doing that I can still tell it's lacking, but there's more to it still than latency issues & creamware's gui. Also seems like it's taking occasional 'samples' of the current levels and using that to drive the meter display. In other words, the updates tend to be 'jerky' & 'spaced out' a bit.
--
For solutions to the overall speed of the metering in SFP mixers?
-
Increase the speed of the creamware gui. They've already made strides in this direction but still have a ways to go. At the risk of being hopelessly redundant I will agree that we continue to discuss this often. Let's hope they get it worked out sooner rather than later.
Second, I'm Just Guessing, but based on the amount of modern "geer-hoors" touting latency figures rather than vintage synth kit lists latency is generally an indesirable thing. The pulsar doesn't have the same access to memory that Steinberg does (remember those pesky pci bus issues?), but I would hazard a guess that it's possible to have an option to 'increase meter accuracy'--ie, precache more data to allow the meters to be precalculated and displayed as needed at the cost of even more pci bandwidth. Not sure how desirable this is tho...?
As for the 'jerky' updating (sampling rate that I can see with my eye), having another option to increase 'sampling rate' or 'meter precision' could work. Since it might be possible to achieve this without resorting to any caching of data (and it should-tho it might cost in dsp) this would be the most likely candidate to increase the performance of the meters next to just speeding up the overall gui. Since it costs in dsp much like the SFP mixer option to 'PhaseComp'ensate, it could also be an option to be enabled on demand where needed. Of course this might be a total pain to impliment and screw up the timing of many current atoms for sfp but I know nothing about that end of things.
Hi all!
I wonder why creamware does provide it's own gui. All other programs (logic, cubase etc) use the windows gui, just normal and they work far more better and faster. It would make the platform os much faster and look more "pro". btw I hate the BMP's used for scopemixers...you see artifacts etc...bad,bad,bad.
CW .,why ?????
I wonder why creamware does provide it's own gui. All other programs (logic, cubase etc) use the windows gui, just normal and they work far more better and faster. It would make the platform os much faster and look more "pro". btw I hate the BMP's used for scopemixers...you see artifacts etc...bad,bad,bad.
CW .,why ?????
I bought a new graphic card lately (Geforce 4, 64 MB). Hardware acceleration is always at maximum. I also switched on the bios option "AGP direct write". Since then, the CW GUI is very responsive and does not seem to affect the cpu performance at all. But apart from that I agree that it would be very nice to have the CW software integrated in the Windows GUI.
-
- Posts: 2464
- Joined: Tue Jun 05, 2001 4:00 pm
- Location: Warsaw to Szczecin, Poland
- Contact:
I think it is because they wanted it to be cross-platform (the same engine for both PC & Mac). This way devices, presets, projects (unfortunately you can't open a Mac project on a PC - but that's another story) and modules can be shared between users of PCs and Macs. They expected better results on newer machines (newer graphics card standards, more VRAM etc.) but smething went wrong...On 2002-11-25 09:06, Michiel de Jonge wrote:
I wonder why creamware does provide it's own gui.
-
- Posts: 1544
- Joined: Fri Apr 13, 2001 4:00 pm
- Location: the Netherlands
- Contact:
I actually had little problems with the speed on Win 98, but ever since I upgraded to XP it seems much slower and less responsive, which is a shame.
And about the level meters, has everyone seen the level meters in that free D-Compressor device? They seem to have no problems at all and look really good as well. How come CW can't do the same on their own devices?
Hmmm, at some point they may have to abandon using their own interface and just go for seperate windows/mac interfaces.
And about the level meters, has everyone seen the level meters in that free D-Compressor device? They seem to have no problems at all and look really good as well. How come CW can't do the same on their own devices?
Hmmm, at some point they may have to abandon using their own interface and just go for seperate windows/mac interfaces.