Topic: audio dropouts

57 Tracks with 57 instances of the Kjearhus classic compressor looped over two bars with a 16 bit wave file on each of the 57 Tracktion tracks.

I reached 47 tracks before hitting 100% in 1.63. 47 instances of the classic compressor were used with 47 16bit wave files on each track.

The CPU percentages you mention are the Mix% and not the File%, right?

If you are only looping over two bars, then all wave files are probably memory buffered in Podium. So this concerns a different kind of optimization issue, rather than the actual file streaming code that was optimized in 1.63.

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.

@Conquistador wrote:

If you have other hosts, it would be interesting to know how they compare to this Podium release.

Ok…

I can get up to 57 tracks in Tracktion 2 using the exact same test I used in 1.63 (multiprocessing off).

CPU usage in Tracktion is about 90 – 95%

57 Tracks with 57 instances of the Kjearhus classic compressor looped over two bars with a 16 bit wave file on each of the 57 Tracktion tracks.

I reached 47 tracks before hitting 100% in 1.63. 47 instances of the classic compressor were used with 47 16bit wave files on each track.

It’s been a while since I tried Tracktion: Do you have a level meter on each of the 57 tracks? If not, how much does it affect the CPU usage if you add the 57 level meters?

@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.

@acousmod wrote:

I can play 8 18 channel 32-bit files at 48kHz, which equals a data throughput of 28 MB/second.

Very impressive !!

If Acousmod only managed 4, 18 channel files, (max) in his tests then to now be able to play twice as many,… 8, 18 channel files is pretty good going Frits.

Especially considering the kind of problems Acousmod had with 4, 18 channel files. 1.64 is shaping up very nicely already. 🙂

@Zynewave wrote:

@Conquistador wrote:

@acousmod wrote:

I can play 8 18 channel 32-bit files at 48kHz, which equals a data throughput of 28 MB/second.

Very impressive !!

If Acousmod only managed 4, 18 channel files, (max) in his tests then to now be able to play twice as many,… 8, 18 channel files is pretty good going Frits.

Especially considering the kind of problems Acousmod had with 4, 18 channel files. 1.64 is shaping up very nicely already. 🙂

It is with 1.63 that I can play 8 files.

So how come you guys are getting such radically different results? Ram or CPU differences maybe?

Are you running Windows XP pro, acousmod?

Yes.
No other app or special task running in the background (no Internet on this computer).
But only a IDE drive, only 1 Gb Ram and only a single 3,2 GHz CPU…
Have you a SATA ?

The problems which I have described happends after several minutes playing. The files are around 1 GB each, and of course are different and they are not looping.
I use VoptXP as a defragmenter and the partition is not fragmented.
But the drive is the same as the system and the swap file (only different partitions).

Does a shorter latency is better for streaming ?
I generally use 1024 because when using plugins it takes less CPU.

@Conquistador wrote:

@Zynewave wrote:

It’s been a while since I tried Tracktion: Do you have a level meter on each of the 57 tracks? If not, how much does it affect the CPU usage if you add the 57 level meters?

Level meters are added by default to every new track created in Tracktion. 😐 Level meters were definitely on each track during the test.

I used an arrangement like yours as test scenario for doing some optimizations on the engine. I have spent a couple of days profiling and experimenting with e.g. SSE optimizations. I’ve now managed to squeeze another 5% performance out of the engine when working with a large number of audio channels/plugins.

I can get close to 60 classic compressor tracks, with a buffer size of 512 and a Pentium D 2.8 (multiprocessing disabled). What buffer size and CPU are you using?