Plantage d'un programme SFML

Résolu/Fermé
MemeTech Messages postés 88 Date d'inscription mercredi 14 août 2019 Statut Membre Dernière intervention 7 janvier 2021 - Modifié le 19 nov. 2019 à 11:52
MemeTech Messages postés 88 Date d'inscription mercredi 14 août 2019 Statut Membre Dernière intervention 7 janvier 2021 - 7 mai 2020 à 00:40
Bonjour !

Je viens demander de l'aide ici car mon enregistreur audio fait avec SFML me pose une colle :
depuis que je suis obligé de bidouiller les tableaux de samples, je remarque un drôle de bug qui semble survenir de façon plus ou moins aléatoire...
En effet, quand je lance un enregistrement, il fonctionne normalement neuf fois sur dix : parfois, le programme plante purement et simplement !

J'ai bien essayé de chercher : quel que soit le format d'enregistrement, la fréquence d'échantillonage, rien n'y fait, je retrouve toujours cette chose.

A force de regarder à droite et à gauche, j'ai fini par trouver où se situe le problème : ça coince sur le moment ou l'enregistrement démarre :
recorder->start (rates[iRate]);

rates[iRate] est simplement la fréquence d'échantillonage choisie par l'utilisateur.

Je n'en sais pas plus sur ce bug, après un certain temps de recherches, je ne trouve rien...

Voilà l'archive complète de mon programme (Je ne le mets pas en balises code, il fait pas loin de 800 lignes :-D et je ne sais pas où peut être le problème de base):

https://www.mediafire.com/file/qdbbn77hv3evbj4/MRecorder.zip/file

J'explique rapidement le fonctionnement de mon programme pour éviter de vous perdre dans ce long truc compliqué : il se compose d'une classe principale (MRecorder) qui s'initialise avec les membres :


   initSplash ();  //  Le splash screen se charge de vérifier si tout est en ordre dans les fichiers de l'appli
   splash ();       //
   init_0 ();  //  Se chargent de régler les poaramètres de l'appli,
   init_1 ();  //  initialiser les textures et tout le reste



Le tout appelé et coordonné par le contructeur.

L'appli fonctionne sinon simplement : l'utilisateur appuie sur R pour commencer son enregisrement, espace pour suspendre et de nouveau R pour le stopper complètement.

Il peut configurer l'application en changeant le codec et la fréquence d'échantillonage.
Ces deux paramètres sot gérés par les fonctions changeFormat () et changeRate ().

La boucle évènementielle est découpée en deux : une partie pour gérer les évènements pendant l'enregistrement (keyEventRecordring ()) et l'autre pour les évènements sur le menu principal (keyEvent ()).

Au passage, je programme sur Code::Blocks avec SFML 2.5.1 sur Window$ 10.
PS : désolé j'ai commenté mon code entièrement en Anglais...

En espérant avoir été assez clair, merci d'avance pour votre aide !

2 réponses

MemeTech Messages postés 88 Date d'inscription mercredi 14 août 2019 Statut Membre Dernière intervention 7 janvier 2021 1
24 janv. 2020 à 20:30
En y regardant de plus près, j'ai l'impression que ce bug est dû à une mauvaise gestion de la mémoire : quand le programme tente de supprimer l'enregistrement précédent, il plante car le fichier est trop gros...
Comment supprimer proprement l'enregistrement précédent pour éviter un plantage ?
Merci !
0
MemeTech Messages postés 88 Date d'inscription mercredi 14 août 2019 Statut Membre Dernière intervention 7 janvier 2021 1
7 mai 2020 à 00:40
En faisant hériter ma classe principale de sf::SoundRecorder, j'ai réussi à bidouiller les samples comme il faut, le bug a disparu, sujet résolu !
0