Zynewave's Forum Page

Have you a SATA ?

My system has a single drive/single partition Seagate Barracuda 160GB using SATA interface.

The problems which I have described happends after several minutes playing.

For 1.64 I have fixed an issue that caused progressively slower performance when playing several minutes into a wave file. It was not a big issue, but it may be the cause for the problem you see.

Does a shorter latency is better for streaming ?

No.

Hi Peter,

Currently I have no plans of supporting more than one plugin per track. Since the last time you posted I have made some track organization enhancements, which allows hiding track lanes and hiding tracks within a group. Also drag and drop is enhanced so that you can drag an effect plugin mapping onto the first part of a track header to insert that effect in the chain. Are you aware of those enhancements? I hope soon to find the time for putting together a tutorial that demonstrates this.

@acousmod wrote:

Tests with 18 channels / 32 bits / 48 kHz files, no plugin, RME driver beta 3, latency set to 1024, P4 HT 3,2 GHz, 1 Gb RAM, multithread not activated, 7200 t internal IDE drive.

…

Podium 1.63
– 1 file : File indicator arround 0 % at the begining, but goes progressively up to 10 % after a few minutes. Moving files (that are not playing) during playback is slower than before (can take two seconds between the mouse drag and the refresh)
– 2 files : 0/1 % at begining, but can go up to 50 % or more in a irregular manner after a few minutes and can even freeze
– 3 files : 0/2 % at begining, but can go up to 50 % or more in a irregular manner with sudden bursts and drop outs after a few minutes and freeze
– 4 files : also freeze after several minutes playing.
When this happends, the sound is cut and the interface is VERY slow : it can take 20 seconds to stop Podium’s engine and Windows can become to be very slow too until I quit Podium.
RAM : the RAM used by Podium in the task manager is about 340 Mo at start but decreases during playback down to about 90 %.

I’m continuing with further optimizations on file streaming for the 1.64 release. I made a multi-channel arrangement similar to your description above, but with latency set to 256 and 2 GB RAM. I can play 8 18 channel 32-bit files at 48kHz, which equals a data throughput of 28 MB/second. I need to work more on the timing of the disk reads to make it more stable.

It is 82 wave files playing but 81 of them are copies. Each on thier own track. Would this make any radical difference or any at all?

If you have 82 imported wave files, then it doesn’t matter that 81 of them are file copies.

If you had 1 imported file, and placed 82 phantom event copies on tracks, then of course the one file is streamed only once.

Since it plays and I can hear the first 12 channels of the 18 channels files, I suppose that all the interleaved files are read ?

Yes, all channels are read from file. Nuendo probably saves some CPU by not pushing channels 13-18 through the engine.

Although, the “0” percents seems to be inaccurate !

Perhaps not. It sounds like Nuendo uses a HD indicator similar to the one I implemented in Podium. I show only the CPU amount that the mixer engine is blocked while waiting for file read commands to complete. In 1.63 I’ve added a separate preload thread that receives file read commands from the mixer engine thread. If the preload thread manages to load all files before the mixer engine requests the data from the files, then the file CPU indicator shows 0%.

While I was unable to find any specific ‘track count sites’ you could easily send us a test project and have a more accurate process of measuring performance on each of our systems.

The test project I have uses 3GB of wave files. Should I email it to you? 😉

I just ripped some of my CDs to wave files, and dragged those onto tracks. To test the true file streaming capacity it is important to let the arrangement play long enough so that the Windows cache manager and Podiums memory buffering of wave files are flushed. When you import a new sound file, it will be profiled for the miniature waveforms, which means that the sound file will reside in the cache.

This happens because the rounding errors are different depending on whether the resized wave display is even or odd pixels in height. The ideal solution to this would be to draw anti-aliased waveforms, but this will have a big impact on the graphics update speed. Perhaps within a couple of years a standard computer system will be sufficiently fast so that I can substitute much of my graphics code with true anti-aliased drawing. Another hack solution would be to always restrict channel heights to an odd pixel count, which on the other hand would result in less fluent zooming.