Topic: audio dropouts

Viewing 15 posts - 61 through 75 (of 82 total)
  • #7106
    Zynewave
    Keymaster

    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.

    #7107
    Conquistador
    Participant

    @Zynewave wrote:

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

    Yes Mix (above) not File (below)

    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.

    I will play the same project over 3 minutes at least this time.

    #7108
    Zynewave
    Keymaster

    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.

    #7109
    Conquistador
    Participant

    @Zynewave wrote:

    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.

    Ok…

    Did the test again but this time I used 47 different wave files (47 imported files) and the results were interesting…

    85% CPU, 70% of the time (roughly), peaking to 91% every so often. That is at least 10% better than in my previous test with 1 audio file and 46 copies on each of the remaining 46 tracks.

    I played the project through for 3 minutes this time.

    Even when I tried looping it for only two bars the CPU usage remained the same as above.

    So using different wave files made a massive difference. I did not think it would make that much of a difference.

    So how many tracks before hitting 100% now?…not much more, but about 50 ish.

    Multiprocessing was off.

    Switched on, CPU is about half at 56%.

    About 50 instances of the Classic compressor were used.

    #7112
    Zynewave
    Keymaster

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

    #7113
    Conquistador
    Participant

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

    #7114
    Zynewave
    Keymaster

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

    #7115
    acousmod
    Participant

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

    Very impressive !!

    #7116
    Conquistador
    Participant

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

    #7117
    Zynewave
    Keymaster

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

    #7118
    Conquistador
    Participant

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

    #7120
    Zynewave
    Keymaster

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

    Amount of available RAM can have an effect. Fragmentation of sound files. Other applications or utilities running which performs periodical file access.

    Are you running Windows XP pro, acousmod?

    #7121
    acousmod
    Participant

    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.

    #7122
    Zynewave
    Keymaster

    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.

    #7128
    Zynewave
    Keymaster

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

Viewing 15 posts - 61 through 75 (of 82 total)
  • You must be logged in to reply to this topic.
© 2021 Zynewave