My colleague did some experiments on gstreamer alsasrc and osssrc plugins and he found that alsasrc consume lots of cpu resource (around 16% on the chip we use). He asked me why the test tool that provided from chip vendor is quite efficient (around 1~2%). It was a big gap to me and I started to find why is that.
After hours checking, I found that the plugin may cause a busy wait in a while loop when the parameters set to non-blocking mode. I do a simple code modification and execute again but the cpu rate just lower to 12%. I’m a little frustrated about it but still had some enhancement.
So I started to try different parameters combination because he told that he found three differences from alsasrc plugin and the test code.
- The setting of alsasrc is non-block mode but the test code is set to block mode.
- The channels setting of alsasrc is 1 but the test code is set to 2.
- The buffer size is limit in test code but alsasrc do not have that limit.
For 1: I thought the non-block mode should be much more efficient but the busy wait should change. For 2: This is really weird because when I set the channels to be 2 in alsasrc plugin, the cpu rate become quite low. So I start to wondering if this is the characteristics of the I2S bus. I googled on the internet but did not find any information to describe that we have to set the channels parameter to be 2 in alsasrc plugin of gstreamer when the audio data bus is I2S. So I’ll confirm it later. For 3: I think it’s reasonable to limit the buffer size.