[Alsaplayer-devel] Problems with CPU use, realtime privileges and polling

Frank Baumgart frank.baumgart at gmx.net
Sat Oct 24 20:40:50 BST 2009

> I would specifically like to interact with the developers who are
> responsible for the code relating to
> 1) The --realtime switch and the code which set up the SCHED_FIFO
> priorities
> and memory locking.
> 2) The excessive CPU use by alsaplayer (which may be in part due to
> improper
> "polling" of various file handles).

Hi Robert,

first, alsaplayer is (almost) dead.
Almost means: I still use it in an embedded environment and spent quite some time several years ago to make it work without any stuttering or long latencies on low-end embedded machines. At that time, it was way ahead of mplayer and any other remote controlable multi-format player on resource usage but I never used the alsaplayer internal GUI nor do I have anything to do with the realtime work.
I integrated those parts of my patches that were of common interest but the "rest" is very specific to my needs and eliminates some features of alsaplayer that cost too much CPU cycles. Software mixer, volume and floating point elimination come to my mind.

Still, text mode should be quite fast, please try for comparison.

"dead", among missing contributions also means that I fixed several exploits in my private sandbox only. Merging those with the repository would require regaining my account/access and separating the stuff. I never found the time to do this but if there is real interest I might think about that again.

If I had to start today I would consider MPD which is similar in concept to alsaplayer although its design is not more "sound" to me and has its own deficiencies. YMMV.
Last time I looked it still lacked a proper asynchronous notification scheme and clear separation between Database and Player. I would recommend to check the current status though.



Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben!

More information about the alsaplayer-devel mailing list