AIMP Forum
AIMP for PC => Предложения / Suggestions => Topic started by: rdykly on September 23, 2026, 16:41:33
-
J'utilise maintenant la version beta 6 sous Ubuntu 26.04
Cela fonctionne bien mais j'ai juste une appréhension sur l'usage CPU
Je t'invite à voir ce retour d'analyse et si possible d'améliorer.
suis déjà sur ALSA : default
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ------------------
27.50 2.724607 547 4981 230 futex
26.97 2.671163 82 32351 poll
20.72 2.052339 2799 733 nanosleep
16.97 1.680743 183 9168 epoll_wait
2.78 0.275664 13 20542 write
2.16 0.213977 6 33851 29712 recvmsg
1.61 0.159727 7 21293 4575 read
1.00 0.099121 8 11121 clock_gettime
0.24 0.023803 9 2383 writev
0.02 0.002256 90 25 select
0.01 0.001007 13 75 open
0.01 0.000594 7 75 close
0.00 0.000452 6 75 sched_getaffinity
0.00 0.000216 72 3 restart_syscall
0.00 0.000154 6 25 gettimeofday
0.00 0.000080 26 3 lseek
0.00 0.000016 16 1 timerfd_settime
0.00 0.000010 10 1 sendmsg
0.00 0.000001 1 1 epoll_ctl
0.00 0.000000 0 1 recvfrom
------ ----------- ----------- --------- --------- ------------------
100.00 9.905930 72 136708 34517 total
C'est très parlant. Regarde la répartition : futex + poll + nanosleep + epoll_wait = 92% du temps, et quasi rien sur les vrais appels de décodage/écriture audio (write ne pèse que 2.78%). Ça confirme le diagnostic : AIMP ne "travaille" quasiment pas, il tourne en boucle d'attente inefficace.
Ce que chaque ligne raconte :
poll (27%, 32 351 appels) et epoll_wait (17%, 9 168 appels) — deux mécanismes différents pour surveiller des sockets/fds, utilisés en parallèle. C'est le signe d'un event loop mal unifié : probablement un mix entre la boucle GTK (qui utilise plutôt poll/epoll en interne) et un backend audio ou IPC (D-Bus, MPRIS ?) qui poll séparément au lieu de partager la même boucle d'événements.
recvmsg (33 851 appels, 29 712 en erreur) — c'est le détail le plus révélateur. Un taux d'erreur de 87% sur recvmsg correspond typiquement à des lectures non-bloquantes sur un socket (EAGAIN : "rien à lire pour l'instant") appelées en boucle plutôt que d'attendre passivement un événement. Ça sent le polling actif sur une socket D-Bus ou PipeWire au lieu d'un vrai listener événementiel.
futex (27.5%, 4 981 appels, 230 en erreur) — contention de locks entre threads. Plusieurs threads d'AIMP (UI, décodage, I/O) se disputent des mutex plus souvent que nécessaire, ce qui gaspille du CPU en réveils/endormissements inutiles plutôt qu'en travail utile.
nanosleep (21%, seulement 733 appels mais 2.8s cumulées) — un thread qui dort puis se réveille très régulièrement (~2.8ms par appel en moyenne), typique d'un polling à intervalle fixe plutôt que d'un vrai callback événementiel.
Verdict : ce n'est pas un problème de "trop de calcul audio", c'est un problème d'architecture du portage Linux — trop de threads qui se réveillent inutilement, du polling actif là où un design événementiel propre suffirait. Ça colle exactement avec les critiques vues sur les forums ("développeur qui ne maîtrise pas les spécificités Linux").
Pistes concrètes à tester :
Désactive tout ce qui pourrait causer du trafic D-Bus inutile : intégration MPRIS (contrôle média depuis le bureau), notifications système, tray icon / AppIndicator. Un par un, en observant si recvmsg chute.
Si tu as une visualisation ou un spectre animé actif, coupe-le — mais vu que write/rendu graphique ne pèse presque rien ici, ce n'est probablement pas la cause principale cette fois.
Remonte ce strace tel quel sur leur forum (aimp.ru/forum) avec ton build number — c'est un rapport de bug bien plus exploitable pour eux qu'un simple "ça consomme trop", et ça leur montre précisément où chercher (event loop / D-Bus polling).
-
recvmsg (33 851 appels, 29 712 en erreur) — c'est le détail le plus révélateur. Un taux d'erreur de 87% sur recvmsg correspond typiquement à des lectures non-bloquantes sur un socket (EAGAIN : "rien à lire pour l'instant") appelées en boucle plutôt que d'attendre passivement un événement. Ça sent le polling actif sur une socket D-Bus ou PipeWire au lieu d'un vrai listener événementiel.
Plusieurs threads d'AIMP (UI, décodage, I/O) se disputent des mutex plus souvent que nécessaire, ce qui gaspille du CPU en réveils/endormissements inutiles plutôt qu'en travail utile.
nanosleep (21%, seulement 733 appels mais 2.8s cumulées) — un thread qui dort puis se réveille très régulièrement (~2.8ms par appel en moyenne), typique d'un polling à intervalle fixe plutôt que d'un vrai callback événementiel.
We don’t work with sockets directly anywhere in the code; the application uses the API provided by GTK/GDK or other external libraries like PortAudio, Sqlite and etc. So, I've no idea how I can fix that on my side.
Verdict : ce n'est pas un problème de "trop de calcul audio", c'est un problème d'architecture du portage Linux — trop de threads qui se réveillent inutilement, du polling actif là où un design événementiel propre suffirait. Ça colle exactement avec les critiques vues sur les forums ("développeur qui ne maîtrise pas les spécificités Linux").
In that case, I can recommend to you to use the WINE-based version of the player for Linux.