notaz
Certified Guru
While looking at DraStic profiles I saw libasound is taking quite a lot, it turned out to be using ~2% CPU steadily. For this reason I usually used OSS for my emulators as figuring out where performance goes with ALSA lib looked too much work.
Finally I took a stab at it this weekend (with some help of Exophase) and it turned out it's mixing several shared memory buffers in some inefficient way, even if only single program is playing sound in the system. After diving into the code I've found a way to detect if there is one playing process or more and use much more efficient path if there is only one, plus implement all mixing with NEON.
After this the mixing is > 10 times faster and those 2% CPU become something barely measurable. The CPU usage when playing MP3s on mplayer go down from ~8% to 6% (5->3% when overclocked) and there is like ~1-2mA reduced current draw.
The new code is already in the feeds and all ALSA using programs (i.e. most of them) should be slightly faster after running OS update.
Finally I took a stab at it this weekend (with some help of Exophase) and it turned out it's mixing several shared memory buffers in some inefficient way, even if only single program is playing sound in the system. After diving into the code I've found a way to detect if there is one playing process or more and use much more efficient path if there is only one, plus implement all mixing with NEON.
After this the mixing is > 10 times faster and those 2% CPU become something barely measurable. The CPU usage when playing MP3s on mplayer go down from ~8% to 6% (5->3% when overclocked) and there is like ~1-2mA reduced current draw.
The new code is already in the feeds and all ALSA using programs (i.e. most of them) should be slightly faster after running OS update.