ALSA capture causes high CPU usage

1
votes

I write a full-duplex ALSA program and run it on a linux-based embedded system. Its sound configurations are:

  • Sample rate: 16Hz
  • Channels: 1 (mono)
  • Format: S16_LE
  • min avail: 160 (frames)

For real-time application, I need to capture sound every 10ms, so I set the min avail to 160.

My problem is: While the program is running, the CPU usage is very High which might be 99.9% (by top command). Sometimes the CPU load is low, but once it gets up to 99.9%, then it can not go back to low CPU usage.

I found out that it might be configuration problem. In asound.conf file (see it in the followed code), I have created a asym type card named "asym0" to choose two different slave cards for playback and capture.

Originally, I use the "primary" as capture device, but it cause high CPU usage. Then I created a rate type card named "rate0", and set it as capture device. The CPU usage becomes lower which floats between 20%~60%, but the captured sound sounds bad. I 've heard some "po po po" in my voice if I test the Mic(capturing).

So...

  • If I choose "primary", CPU usage is high, but no "po po po" sound.
  • If I choose "rate0", CPU usage is lower, but has "po po po" sound.

What are the different from "type hw" and "type rate"?
Is the effect caused by the different interrupt frequency?

asound.conf file:

pcm.primary { type hw card mycard } pcm.rate0 { type rate slave { pcm "primary" rate 16000 } } pcm.asym0 { type asym playback.pcm "primary" capture.pcm "primary" or "rate0" }

Please anyone help me to solve this problem. Thank you!!!

1
clinuxaudioalsalibasound
What formats/channels/rates does your hardware actually support? – CL.
It supports sample width in 16/24 bit linear, mono Left/Right or stereo channels and 16kHz and 48kHz. – Tobby
Please show the output of both arecord -v -fdat -c1 -D primary something.wav and arecord -v -fdat -c1 -D rate0 something.wav. – CL.

1 Answers

0
votes

Sound capture should be a very trivial task for the CPU because most of it is happening in silicon hardware and occasionally it needs to fire up the thread to handle input audio. Typically if your periods or buffers are very small it will require more CPU attention and is likely to have overruns. Overruns may be where your signal dropouts are occuring.

If your sample rate is 16 kHz, and you capture every 10ms, that is indeed 160 frames.

Some things to look at are whether your period is smaller then 10ms, whether you are doing processing which is very heavy in your thread.

To help you, there is some code in gtkIOStream which implements a C++ OO ALSA hierarchy. You can look at this ALSAFullduplex.C test application as a reference and test it to see if it suffers the same problems you are suffering.

Information on building gtkIOStream is given in this email : https://lists.audioinjector.net/pipermail/people/2020-March/000028.html