S#!$ j'avais fait one longue réponse hier et elle n'est pas passée, j'ai un peu de mal à faire passer le test du vilain spammeur à Opéra, si je publie directement, l plupart du temps ma réponse est fausse. Je dois être vraiment très mauvais en lecture de chiffres.
Sionon j'expliquais que le gars qui a fait la RF et tuxaudio (dont la gestion de la flash) est parti et je reprends ses codes. Et ce que tu décris là m'a bien fait rire, c'est typique de sa façon de programmer. Enfin, y'a du boulot quoi.
Juste pour t'expliquer 2,3 trucs si je me souviens bien, l'écriture dans la flash utilise le même canal RF que quand on envoie du son au HP. Et tant que l'index de fin n'est pas atteint, elle attend les échantillons, pas de timeout ni gestion d'erreur, rien. Donc si la RF perd quelques trames, ton tux est bloqué. Pour contrer ça, la solution (très très élégante) a été de rajouter du blanc à la fin des samples, donc si des échantillons sont perdus, le début d'un son se retrouve à la fin du précédent mais au moins ça ne bloque pas. Ca doit expliquer le 0.07 et le blanc quelque part.
Les 10 secondes, c'est pour attendre l'effacement de la flash. Ca prends moins de temps que ça en général, mais comme on n'a aucun feedback, on attend. Qu'est-ce qu'on ne ferait pas pour la beauté de l'implémentation
0x400, ça doit être l'index du premier échantillon, le début de la flash étant réservé pour les indexes.
Enfin, j'espère que ça t'aidera un peu. La prochaine fois contacte moi (par email ou autre) et j'essaierai de t'aider au mieux pour t'éviter de perdre du temps pour des bêtises. Sinon on a prévu de revoir la programmation de la flash pour améliorer ça, mais je ne sais pas quand on aura le temps de le faire.
S#!$ j'avais fait one longue réponse hier et elle n'est pas passée, j'ai un peu de mal à faire passer le test du vilain spammeur à Opéra, si je publie directement, l plupart du temps ma réponse est fausse. Je dois être vraiment très mauvais en lecture de chiffres.
Sionon j'expliquais que le gars qui a fait la RF et tuxaudio (dont la gestion de la flash) est parti et je reprends ses codes. Et ce que tu décris là m'a bien fait rire, c'est typique de sa façon de programmer. Enfin, y'a du boulot quoi.
Juste pour t'expliquer 2,3 trucs si je me souviens bien, l'écriture dans la flash utilise le même canal RF que quand on envoie du son au HP. Et tant que l'index de fin n'est pas atteint, elle attend les échantillons, pas de timeout ni gestion d'erreur, rien. Donc si la RF perd quelques trames, ton tux est bloqué. Pour contrer ça, la solution (très très élégante) a été de rajouter du blanc à la fin des samples, donc si des échantillons sont perdus, le début d'un son se retrouve à la fin du précédent mais au moins ça ne bloque pas. Ca doit expliquer le 0.07 et le blanc quelque part.
Les 10 secondes, c'est pour attendre l'effacement de la flash. Ca prends moins de temps que ça en général, mais comme on n'a aucun feedback, on attend. Qu'est-ce qu'on ne ferait pas pour la beauté de l'implémentation
0x400, ça doit être l'index du premier échantillon, le début de la flash étant réservé pour les indexes.
Enfin, j'espère que ça t'aidera un peu. La prochaine fois contacte moi (par email ou autre) et j'essaierai de t'aider au mieux pour t'éviter de perdre du temps pour des bêtises. Sinon on a prévu de revoir la programmation de la flash pour améliorer ça, mais je ne sais pas quand on aura le temps de le faire.
A+,
David