AIMP for linux version Beta

[rdykly]

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).