My colleague did some experiments on GStreamer alsasrc and osssrc plugins and found that alsasrc consumes a lot of CPU resource (around 16% on the chip we use). He asked me why the test tool provided by the chip vendor is quite efficient (around 1~2%). It was a big gap and I started to investigate why.
After hours of checking, I found that the plugin may cause a busy wait in a while loop when the parameters are set to non-blocking mode. I made a simple code modification and the CPU rate dropped to 12%. Still frustrating, but some improvement.
So I started trying different parameter combinations based on three differences he noted between the alsasrc plugin and the test code:
- alsasrc is in non-block mode — the test code is in block mode.
- alsasrc channels = 1 — the test code sets channels = 2.
- Buffer size is limited in the test code but not in alsasrc.
For issue 1: I thought non-blocking mode should be more efficient, but the busy wait needs to change.
For issue 2: This is really weird — when I set channels to 2 in the alsasrc plugin, the CPU rate drops significantly. This makes me wonder if it’s a characteristic of the I2S bus. I searched the internet but couldn’t find any information confirming that channels must be set to 2 for the alsasrc GStreamer plugin when the audio data bus is I2S. I’ll confirm this later.
For issue 3: I think limiting the buffer size is reasonable.
Comments & Feedback