Какой плеер самый экономичный?

На моем нетбуке с Интел Атом mpd кушает 10-15% процессорного времени воспроизводя mp3. Пробовал собирать разными компиляторами, включая интеловский с разными СFLAGS с разными бэкэндами. Разумеется, бэкэнды (ffmpeg, libmad etc.) тоже пересобирал. Меньше 10% эта цифра не опускалась. Кстати, gcc-4.5, который должен поддерживать атомы показал самую худшую производительность при прочих равных условиях, но возможно стоит покурить насчет СFLAGS. При этом, казалось бы, тяжелый Amarok на движке xine ест всего 3-7% процессора. В чем может быть дело? mpd нельзя собрать с поддержкой xine, поэтому не могу сравнить, может это xine так эффективен? И раз уж на то пошло, то предложите плеер для аудио и для видео, такие, чтобы не шибко нагружали процессор.

Для аудио использую deadbeaf. Он всего 6% процессора ест.
Для видео SMPlayer (а когда подглючивает, то и чистый mplayer можно).

Самый, консольный mplayer.

Видео - mplayer, аудио - mpd. Mplayer тоже можно использовать для аудио, но mpd все ж кошернее.

neko259, прочтите пост внимательнее, а потом вопрос =)

Н-да, спасибо, elve, как я уже говорил, mpd на удивление сильно грузит мой процессор. Если кто-нибудь подскажет, как это побороть или, хотя бы, в чем может быть причина этого буду несказанно рад, ибо на десктопе юзаю mpd и привык к нему. Я полагаю, причина все же в бэкэнде mpd, ведь он не сам декодирует звук, а использует сторонние библиотеки. Так, для декодирования mp3 он может использовать libmad, который сразу отпадает, поскольку эта библиотека написана с использованием только целочисленной арифметики, а SSE инструкции, которые держит Atom грех не использовать, т.к. это немалый выйгрыш в производительности. Но вот отчего же ffmpeg так сильно грузит процессор, я не понимаю.
Вообще, я выяснил, что наиболее выгодно использовать mpg123, но его интерфейс, точнее полное отсутсвие последнего делают его не вполне юзабельным... собираю deadbeaf.

bobr, а если закрыть "морду" после запуска? Все равно грузит?

Да, все равно грузит. Как "морду" для mpd использую ncmpcpp. То-есть вряд-ли она грузит процессор.

deadbeef на моем нетбуке загружает процессор на 11%. Насколько я понял, он тоже использует libmad, как и mpd. Подумываю о том, чтобы написать плеер с использованием libmpg123. Уже набросал модуль для Python, правда пока очень ограниченный.

ну для того что бы выбирать менее прожорливый плеер нужно знать на каких библиотеках ваша ДЕ работает, так как это сокращает ресурсы потребляемые им.

У меня практически все плейеры аудио дают не менее 15% загрузки.
Пытался пробовать когда-то mpd в связке с ещё чем-то - не пошло.
В упор не видело муз. коллекцию на жёстком :(

$ ps uax |grep "auda"
doc       3204  5.8  3.5  59264  8824 ?        Sl   13:24   8:52 audacious
doc       4452  0.0  0.3   2416   880 pts/0    S+   15:56   0:00 grep --color auda

$ uname -a
Linux bx 2.6.29.6-smp #2 SMP Mon Aug 17 00:52:54 CDT 2009 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux

вопрос закрыт? руки.sys?

drBatty написал:

вопрос закрыт? руки.sys?

Может всё-таки поаккуратнее в высказываниях? oO
Системы у всех разные, железо тоже... :rolleyes:

Думаю вам следует обратить внимание на мой пост выше сначала!

enslaver написал:

ну для того что бы выбирать менее прожорливый плеер нужно знать на каких библиотеках ваша ДЕ работает, так как это сокращает ресурсы потребляемые им.

Думаю, вы неправы, в таком утверждении, или не вполне правы. Как насчет mpd? Он тоже от ДЕ зависит? Кроме того, декодирование mp3 - куда более ресурсоемкий процесс, чем отображение GUI. Так, что библиотеки, на к-рых ДЕ работает - если не последний, то один из последних факторов, над которыми стоит задумываться.

root@asus:~# ps aux | grep [d]ead
1000 2089 5.8 5.7 170716 21860 tty1 SLl 16:01 0:06 /usr/bin/deadbeef
root@asus:~#

root@asus:~# grep "model name" /proc/cpuinfo
model name : Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
root@asus:~#

это простите даже не Атом.
bobr, ваши измышления насчёт каких-то целочисленных вычислений не верны изначально.
всё дело в кривой оптимизации.

system-root, очень даже может быть, поскольку это действительно только лишь мои измышления. Но меня все же больше волнует не вопрос "кто виноват?", а " что делать?". Просто перебором испробовал все доступные компиляторы едва ли не со всеми возможными флагами. Как оптимизировать? И если можно, поподробней о этой самой кривой.

bobr, попробуйте в chroot окружении собрать сам gcc и тот же deadbref со всеми вытекающими просто -pipe -fomit-frame-pointer и упаси боже не -O3, а -O2.
всё, три флага которых достаточно для всего на свете.

Попробую. Сейчас я не дома, так что о результатах через пару недель. А -march= что писать? кто-то советует core2, кто-то prescott советует. Может -march=i686 попробовать?

bobr написал:

А -march= что писать?

native, это же ноутбук.