Logicielsmoto.com

Nous sommes le 19 Juil 2019, 00:30

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 52 messages ]  Aller à la page Précédente  1, 2, 3, 4  Suivante
Auteur Message
 Sujet du message:
MessagePosté: 07 Juil 2012, 11:01 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
Donc le filtre logiciel réduit l'usage CPU. C'est surprenant.

Non, ce que je fais, c'est :
- S'il y a du son à générer, je fais une rampe de 0 vers la nouvelle donnée son.
- Une fois que le buffer son est plein la routine son est appelée. Ensuite, tant qu'il y a du son à générer, la routine son est appelée.
- Dès que le son n'est plus sollicité, je fais une rampe de la dernière donnée vers 0. Le son (silencieux) est généré.
- Quand le son est arrivé à 0, je ne fais plus d'appels à la routine de son, et le timer prend le relai.

Tout ça sur Linux pour l'instant.

Samuel Devulder a écrit:
Sais tu si le code ci-dessus fait du bruit sur un vrai TO ou si comme je le suppose il est (relativement) silencieux?
[...]
Que dit une vraie machine, buzz ou pas Buzz?

Buzz. Et le volume du bruit dépend de la valeur contenue dans $E7CD, $3F étant le plus fort. Étrangement, mettre $00 dans $E7CD génère du bruit aussi.

Samuel Devulder a écrit:
Donc as tu retiré le filtre?

Les filtres passe-bas et passe-haut ne sont que sur la version 1.8.1 (et seulement sous Linux).
Pour les versions 1.8.0 et inférieures, le buzz est reproduit très fidèlement. Le problème étant qu'il nécessite que la routine son soit invariablement appelée, ce qui fait monter l'usage CPU au plus haut. Il va falloir peut-être choisir entre le mieux du pire et le pire du mieux.

Samuel Devulder a écrit:
Citation:
Samuel, es-tu d'accord pour intégrer l'équipe de Teo sur SourceForge ?

Pourquoi pas, mais j'avoue ne pas trop savoir quoi faire, n'ayant pas de TO8 pour comparer.

Il y a des choses que tu sais et qui seraient bien utiles, pourtant. Notamment en ce qui concerne ce sujet.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 08 Juil 2012, 17:41 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
Samuel Devulder a écrit:
Donc le filtre logiciel réduit l'usage CPU. C'est surprenant.

Non, ce que je fais, c'est :
- S'il y a du son à générer, je fais une rampe de 0 vers la nouvelle donnée son.
- Une fois que le buffer son est plein la routine son est appelée. Ensuite, tant qu'il y a du son à générer, la routine son est appelée.
- Dès que le son n'est plus sollicité, je fais une rampe de la dernière donnée vers 0. Le son (silencieux) est généré.
- Quand le son est arrivé à 0, je ne fais plus d'appels à la routine de son, et le timer prend le relai.

Ah oui c'est pas du tout un filtre linéaire. Ces dernier sont hyper simples et s'appliquent à tous les échantillons en appliquant uniformément la même formule (donc pas de tests dans le code pour savoir si la valeur a changée ou pas). Typiquement, ajouter un filtre du 1er ordre (-6db/octave donc) sur un signal échantilloner x, revient à considérer y += (x - y)*coef) (y = signal filtré, x = valeur échantillonnée, coef un coefficient qui dépend de la fréquence de coupure du filtre; plus il est proche de 1 plus la bande passante est élevée). Quelque part le filtre linéaire lisse les variation du signal et effectue naturellement les rampes dont tu parles sans test ni code spécifique à l'apparition d'un échantillon de nouvelle valeur.

filtrage avec coef=0.5:
Image

Dans l'algo que tu utilises, sais tu ce qui prend du temps avec la dernière version d'ubuntu? Est la détection d'un nouveau signal à générer et la remise en route de l'envoi des échantillons à la carte son?

En principe quand le buffer circulaire du son contient la même valeur de bout en bout, plus aucun bruit ne doit sortir sans avoir besoin de couper temporairement le driver audio. Si je me souviens bien, dans la version primitive de TEO (ou était-ce Emuto7) que j'avais porté sur amiga le son marchait ainsi en tournant à vide sur la même valeur quand personne ne l'utilise et cela ne consommait pas tellement de resources (il le fallait bien avec les maigres Mhz de l'amiga). Qu'est-ce qui a changé depuis?


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 08 Juil 2012, 20:28 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 415
Localisation: France
J'ai jeté un oeuil rapide au code de Teo pour Linux.
Je constate que le son est généré à 44100Hz. Or, les cartes son modernes sont plutôt à 48000Hz. Cela a deux avantages :
* On peut générer du son jusqu'à 24KHz sans être embêté, ce qui laisse de la place pour mettre un filtre qui coupe entre 20 et 24KHz (la fréquence de coupure d'un filtre n'est pas complètement verticale)
* Le PPCM entre 48000 et la fréquence d'horloge du TO8 est plus petit que entre 44100 et cette même fréquence, ce qui limite la plupart des effets d'antialiasing.

Comme le resampling ALSA est actif, je pense que le son est rééchantilloné par ALSA pour retomber sur la fréquence de la sortie son. Ce resampling doit être fait au moins avec une interpolation linéaire, ce qui demande un peu de CPU (ou ça peut être un truc plus compliqué pour limiter au mieux l'aliasing).

Le fait de couper la génération du son en arrêtant simplement d'envoyer des échantillons n'est pas la bonne façon de procéder non plus. On tombe dans un cas d'erreur de ALSA (buffer overrun) et il faut relancer le flux quand la génération du son reprend. En particulier, le filtre de rééchantillonage contient encore la mémoire du dernier son généré, donc il y a une sorte d'écho de ce son qui vient se superposer au son suivant... ça peut marcher par contre si la fréquence est la même entre l'émulateur et la carte son : dans ce cas il n'y a pas de filtre entre les deux. Mais il faut écrire du code capable de gérer plusieurs fréquences pour s'adapter à toutes les cartes son...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Juil 2012, 14:21 
Hors ligne

Inscription: 27 Avr 2006, 09:04
Messages: 101
Beaucoup de jolis graphiques sympatoches...

A part ça, je me demandais quelle était la fréquence de sortie maxi du buzzer, bicoz j'avais pris connaissance quelque part de sa limitation, mais je ne sais plus si c'était 8 ou 16Khz.
Maintenant que sam me fait réfléchir un peu, je pense que ce doit être 16Khz. 8, c'est trop peu, en effet.

En gros, vous pouvez bourrer e7c1 autant que vous voulez, le résultat ne sera pas meilleur au delà de cette limite. Enfin si... il se passe un truc intéressant passée cette fréquence... Et sam va sûrement le découvrir s'il choppe les sources de Tomix avant le 21 décembre de cette année.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Juil 2012, 15:27 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
PulkoMandy a écrit:
Le fait de couper la génération du son en arrêtant simplement d'envoyer des échantillons n'est pas la bonne façon de procéder non plus. On tombe dans un cas d'erreur de ALSA (buffer overrun) et il faut relancer le flux quand la génération du son reprend.

J'attendais que quelqu'un m'en dise plus long, justement :D

PulkoMandy a écrit:
ça peut marcher par contre si la fréquence est la même entre l'émulateur et la carte son : dans ce cas il n'y a pas de filtre entre les deux. Mais il faut écrire du code capable de gérer plusieurs fréquences pour s'adapter à toutes les cartes son...

... ou alors peut-être refermer le driver... pour le rouvrir dès qu'il est nécessaire ?


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Juil 2012, 15:40 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
Dans l'algo que tu utilises, sais tu ce qui prend du temps avec la dernière version d'ubuntu? Est la détection d'un nouveau signal à générer et la remise en route de l'envoi des échantillons à la carte son?

Oui. Dès que le son est sollicité, l'usage CPU monte en flèche. Quand il n'est pas sollicité, l'usage CPU descend à 5%/6%.

Samuel Devulder a écrit:
En principe quand le buffer circulaire du son contient la même valeur de bout en bout, plus aucun bruit ne doit sortir sans avoir besoin de couper temporairement le driver audio.

Je serais assez d'accord pour que ça fonctionne comme ça. Malheureusement, ça n'est pas le cas. Même si la courbe son est plate, l'usage CPU est le même que quand un son audible est généré.

Samuel Devulder a écrit:
Qu'est-ce qui a changé depuis?

Aucune idée. Ce que je sais, c'est que ça n'a pas forcément changé en bien.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Juil 2012, 17:04 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 415
Localisation: France
Prehisto a écrit:
PulkoMandy a écrit:
... ou alors peut-être refermer le driver... pour le rouvrir dès qu'il est nécessaire ?


J'ai vu passer une fonction "snd_pcm_pause()", qui pourrait éventuellement convenir. Je vois deux problèmes :
* Cette fonction n'est pas supportée par tout les pilotes de cartes son (en tout cas c'est ce que dit la doc de ALSA),
* Fermer et ouvrir le flux peut aussi prendre du temps (je ne sais pas ce qui doit être réinitialisé en interne de ALSA)

Je pense que l'occupation du CPU à 100% pour jouer du son n'est pas normale, et donc il me semble plus intéressant de trouver la source du problème que de le contourner. Je peux essayer de compiler tout ça et de tester chez moi, mais ça va être un peu compliqué à mettre en place (PC linux serveur sans écran, il va falloir faire du remote X sur une machine FreeBSD pour lancer l'émulateur je suppose...)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Juil 2012, 17:28 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
PulkoMandy a écrit:
J'ai vu passer une fonction "snd_pcm_pause()", qui pourrait éventuellement convenir. Je vois deux problèmes :
* Cette fonction n'est pas supportée par tout les pilotes de cartes son (en tout cas c'est ce que dit la doc de ALSA),

Tout à fait. Ce qui amène à la réticence.

PulkoMandy a écrit:
* Fermer et ouvrir le flux peut aussi prendre du temps (je ne sais pas ce qui doit être réinitialisé en interne de ALSA)

Faut voir.

PulkoMandy a écrit:
Je pense que l'occupation du CPU à 100% pour jouer du son n'est pas normale, et donc il me semble plus intéressant de trouver la source du problème que de le contourner.

Mon ordinateur est peut-être sur le point de me lâcher, il commence à dater :L Ou devrais-je faire un réinstallation complète : j'ai installé tellement de choses qui n'ont plus d'utilité...

PulkoMandy a écrit:
Je peux essayer de compiler tout ça et de tester chez moi

J'attends tes résultats avec impatience.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 18:16 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 415
Localisation: France
Après un peu de temps à installer tout ça (j'ai du patcher un client VNC pour arriver à voir l'émulateur...), je constate que je n'ai pas de problèmes d'occupation CPU quand il y a du son...

J'ai essayé la démo Chinese Stack.
Sur l'écran titre qui lit un sample en boucle le CPU est faiblement utilisé. Par contre sur les écrans en "multicouleur" j'ai à peu près un coeur d'utilisé.

La machine de test est un Core 2 Duo, en 64 bits, avec une Debian "sid" à peu près à jour et dans une configuration assez minimale. La carte son est une intel HDA, assez classique. Si tu veux faire des essais, je peux rendre le VNC accessible de l'extèrieur.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 19:40 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
PulkoMandy a écrit:
je constate que je n'ai pas de problèmes d'occupation CPU quand il y a du son...
J'ai essayé la démo Chinese Stack.
Sur l'écran titre qui lit un sample en boucle le CPU est faiblement utilisé.

Ben oui. Incompréhensible. Je dois avoir un problème matériel.

PulkoMandy a écrit:
Si tu veux faire des essais, je peux rendre le VNC accessible de l'extèrieur.

Si il n'y a pas de problèmes côté son, je vais donc revenir à la routine de la version 1.8.0. Mais bon, chez moi, ça bouffe.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 20:37 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
Mais bon, chez moi, ça bouffe.


J'y connais plus grand chose en linux (j'me fait vieux), mais n'y aurait-il pas un utilitaire pour voir ce qui prends du temps sous linux? Je crois que systrace (strace?) peut tracer les appels à l'OS. On peut peut-être voir quel appel au juste prend du temps cpu.

Sinon, si ca se trouve le code rame ailleurs que là où l'on croit. Que donne un simple profiling avec gprof ?

J'ai trouvé sur la page http://www.pixelbeat.org/programming/profiling/ plein d'outils intéressants, dont un certain "perf" qui permet entre-autre de profiler un programme particulier. Il permet même de voir les pbs de cache-miss et autres trucs bas-niveau.


Dernière édition par Samuel Devulder le 11 Juil 2012, 21:43, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 20:52 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 415
Localisation: France
htop permet d'afficher la consommation cpu par processus mais je doute que ce soit très intéressant.

Il y a valgrind qui permet de faire du profiling (avec l'option "callgrind"), et kcachegrind qui permet de visualiser les résultats.

Un test simple : est-ce que "aplay /usr/share/sounds/alsa/Front_Center.wav" (ou un autre fichier wav :) ) occupe aussi tout le CPU ?

Mh... je vois que tu es passé à Ubuntu 12.04. Sur cette version, ALSA est intercepté pour passer par pulseaudio, c'est probablement là que se trouve le problème, et les plaintes à ce sujet ne manquent pas sur internet... Sur ma machine j'utilise directement ALSA (le vrai), et tout se passe bien.
Je te conseille de désinstaller pulseaudio pour voir si cela règle le problème.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 20:55 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
J'y connais plus grand chose en linux (j'me fait vieux), mais n'y aurait-il pas un utilitaire pour voir ce qui prends du temps sous linux?

Il y a la commande 'top', à lancer dans un Terminal. Elle affiche tous les processus en cours, avec leur nom, leur temps d'occupation CPU, mémoire, etc...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 20:58 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
PulkoMandy a écrit:
Je te conseille de désinstaller pulseaudio pour voir si cela règle le problème.

Oui, j'ai cru voir effectivement ce conseil quelque part sur un forum. Je vais enlever PulseAudio, j'espère que ça ne va pas crasher mon OS...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 21:11 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Tu m'étoooooooooooonnes !!!! Je viens de retrouver Linux comme je l'aime ! Les vidéos sont bien plus fluides sans PulseAudio. Bon ben voilà un problème résolu, je pense.


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 52 messages ]  Aller à la page Précédente  1, 2, 3, 4  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 4 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com