A colleague recently observed a significant discrepancy in CPU usage while testing the GStreamer alsasrc and osssrc plugins. On our hardware platforms, alsasrc was consuming about 16% of CPU resources, whereas the vendor-provided test tools achieved the same task with only 1~2% overhead. This massive gap in efficiency piqued my curiosity, and I decided to investigate the root cause.
After several hours of deep diving into the code, I discovered that when the plugin is set to “non-blocking mode,” it can trigger a busy-wait condition within a while loop, needlessly spiking CPU cycles. After a quick patch to optimize this behavior, I managed to bring the CPU usage down to 12%. While an improvement, it still felt far from the vendor tool’s efficiency.
We then compared the alsasrc configuration against the vendor test tool and found three key differences:
alsasrcwas in non-blocking mode; the test tool used blocking mode.alsasrcwas configured for 1 channel (Mono); the test tool used 2 channels (Stereo).- The test tool explicitly limited the buffer size;
alsasrcdid not.
My initial thought was that non-blocking mode should inherently be more efficient for an event-driven system, provided the busy-wait is handled correctly. However, the second point was the most intriguing: when I switched alsasrc to 2 channels, the CPU usage dropped drastically. This led me to suspect a hardware-specific trait of the I2S bus. Curiously, I couldn’t find any documentation online stating that “audio buses utilizing I2S must be configured for 2 channels in GStreamer’s alsasrc.” I intend to confirm this hardware dependency in further tests. Lastly, limiting the buffer size is a standard optimization that definitely warrants implementation in our production pipeline.
Comments & Feedback