Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: STDOUT decoding buffering issue? (Read 4716 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

STDOUT decoding buffering issue?

I have a dual core CPU and ran some decoding | encoding pipelines under linux for testing. I used taskset(1) in order to assign core #0 to the decoding process and core #1 to the encoding process, so that I could monitor the CPU usage of each more closely. In such a setup, it is expected that the faster process will use only a fraction of the CPU core that was assigned to it, while the slower process would use 100% of its own CPU core (i.e. the faster process waits for the slower process so that it can either output new data to it, or read new data from it).

With wvunpack as the decoder however, the encoding CPU usage is much less than 100% when using a fast encoder (such as flac -6 for instance, 54% with that setting), while the CPU usage of wvunpack itself is nowhere near 100% (60% with flac -6 as the encoder). I've tried with other decoders (flac, oggdec), and the encoder always reached 100%. I also removed taskset from the pipelines, yielding the same results.

The problem doesn't show when using wvunpack alone (decoding to a file instead of stdout), so I can only assume it lies somewhere within the stdout code? Running strace on wvunpack produced a ~500 KiB log file, while strace on flac (still as a decoder, on the same audio piece) generated a 5.6 MiB log file, with a hell of a lot more read() and write() calls. I have also noticed that the more demanding the encoder was (with wvunpack as the decoder), the less the bottleneck effect would show (reaching 85% with flac -8, nearly 100% with oggenc or lame).