J'ai pensé de même à un débordement de tampon. En lisant l'API ( http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.(...) ): dans l'exemple http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2latenc(...) , snd_pcm-readi() est appelée avec un char* pour deuxième paramêtre. Or un short n'a pas la même taille qu'un char (pourtant on a sizeof(short) >= sizeof(char) (et sizeof(char) == 1), donc remplacer short par char dans ce code ne résoudra pas ce problème. Mais c'est un indice...)
Mais il faudrait quelqu'un qui connaît mieux l'API pour savoir d'où vient le problème... Dans l'API de snd_pcm-readi(), ils parlent aussi bien de frames que de bytes.
Si le paramètre size correspond à un nombre de bytes, alors il est préférable de définir le buffer comme un char[LEN] (ou char* avec malloc) et de passer sizeof buf (ou la longueur passée à malloc) comme troisième paramètre.
Si le paramètre size est un nombre de frames, alors je ne sais pas, il faut voir comment ALSA définit une frame (peut-être la taille d'une frame dépend-elle de la qualité du son, i.e. bitrate ?). Pour info, un short contient au moins 16 bits (une implémentation peut avoir un short plus grand, mais ce n'est pas garanti).
En tout cas, je suis d'accord avec ton diagnostic, c'est un simple débordement de tampon. Reste à savoir d'où il vient.
(en passant, j'ai des gros doutes sur les lignes d'include:
#include "string.h";
On inclut un en-tête de la bibliothèque standard avec les crochets < > au lieu des guillemets, et on ne place pas de ; à la fin de la ligne:
#include <string.h>
Ca me semble étonnant qu'une telle syntaxe soit acceptée par un compilateur C, ça doit être une extension...)
[^] # Re: valgrind ou electric fence
Posté par alf . En réponse au message incompréhensible - utilisation d'ALSA. Évalué à 1.
Mais il faudrait quelqu'un qui connaît mieux l'API pour savoir d'où vient le problème... Dans l'API de snd_pcm-readi(), ils parlent aussi bien de frames que de bytes.
Si le paramètre size correspond à un nombre de bytes, alors il est préférable de définir le buffer comme un char[LEN] (ou char* avec malloc) et de passer sizeof buf (ou la longueur passée à malloc) comme troisième paramètre.
Si le paramètre size est un nombre de frames, alors je ne sais pas, il faut voir comment ALSA définit une frame (peut-être la taille d'une frame dépend-elle de la qualité du son, i.e. bitrate ?). Pour info, un short contient au moins 16 bits (une implémentation peut avoir un short plus grand, mais ce n'est pas garanti).
En tout cas, je suis d'accord avec ton diagnostic, c'est un simple débordement de tampon. Reste à savoir d'où il vient.
(en passant, j'ai des gros doutes sur les lignes d'include:
On inclut un en-tête de la bibliothèque standard avec les crochets < > au lieu des guillemets, et on ne place pas de ; à la fin de la ligne:
Ca me semble étonnant qu'une telle syntaxe soit acceptée par un compilateur C, ça doit être une extension...)