Streaming et libération de mémoire
Bonjour,
J'ai écrit en récupérant le code fourni en annexe une appli iphone qui fait du streaming audio sur une web radio.
Tout fonctionne à merveille seulement pendant 1 mn. L'application continue de tourner mais je n'ai plus de son.
Par les outils d'analyse, je m'aperçois que je stocke beaucoup de CFDATA. Je pense que cela viens de là .
Je ne suis pas très fort en OBJ-C alors si vous pouviez me filer un coup de main cela serait sympa.
Merci d'avance.
Alexandre.
J'ai écrit en récupérant le code fourni en annexe une appli iphone qui fait du streaming audio sur une web radio.
Tout fonctionne à merveille seulement pendant 1 mn. L'application continue de tourner mais je n'ai plus de son.
Par les outils d'analyse, je m'aperçois que je stocke beaucoup de CFDATA. Je pense que cela viens de là .
Je ne suis pas très fort en OBJ-C alors si vous pouviez me filer un coup de main cela serait sympa.
Merci d'avance.
Alexandre.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est gentil à toi de t'interresser à mon sujet. Et effectivement je ne suis pas très précis dans ma question.
Avec le code fourni dans le premier post, j'ai fait une appli iphone (dans le point h j'ai remplace le cocoa.h par uikit.h, j'appelle le start internal sans passer par le NSThREAD et j'ai enlevé le NSALERT).
Tout fonctionne trés bien pendant, une minute et puis le son se coupe. Cela ne se passe pas sur l'appli original qui tourne en sous OS X 10.5 (elle fonctionne très bien). Avec le monitoring le chargement de DATA du streaming fonctionne toujours, je vois la quantité de CFDATA en engistré augmenter sans cesse.
Je me pose donc la question pourquoi lorsque je passe cette appli sous iphone, cela se produit. On a l'impression que la queue n'est plus lue, ou qu'il n'y a pas assez de ressource pour produire le son.
Une autre indication : sur les constantes définies sur le point h, j'ai l'impression que quand j'augmente le nombre de buffers la durée de l'écoute est plus longue (pas suffisante mais plus longue). Est-ce que dans le code fourni, on libère bien les buffers et qu'on les recharge pour les relire.
Voilà .
Je n'ai pas d'autre pistes.
Je vous remercie d'avance pour votre aide.
Alexandre.
De plus le code que tu as posté contient beaucoup d'instructions faisant référence à l'utilisation d'un thread. Tu as aussi supprimé toutes ces instructions ?
Merci.
Il me fait une erreur
[23:58:13.064 <0x859a00>] could not find audio decoder component 00000000 for registration
[23:58:13.065 <0x859a00>] could not find audio encoder component 00000000 for registration
AudioQueueNewOutput err tmf! 560360820
[Switching to thread 12035]
AudioQueueNewOutput err tmf! 560360820
[Switching to thread 13571]
[Switching to thread 13571]
Program received signal: “EXC_BAD_ACCESSâ€.
Current language: auto; currently objective-c
alors que quand je le passe avec le [self startInternal], il ne fait pas l'erreur mais il stop au bout de 3O secondes.
Alexandre.
ça ce n'est pas une erreur dûe au thread ... Il faut localiser cette erreur dans le code et consulter la doc Audio Queue Services Programming Guide de l'iPhone.
La doc du SDK (si oui donne la référence de la doc) ? ou un essai d'exécution ?
Parce qu'à l'exécution, ce serait plus logique que cela plante sur une allocation que sur une recopie mémoire memcpy() , à moins que l'un des arguments de ce memcpy() soit NULL.
Effectivement cela parait bizare, mais la fonction :
OSStatus err = AudioFileStreamOpen(self, MyPropertyListenerProc, MyPacketsProc,
fileTypeHint, &audioFileStream);
fait plein de choses à la fois, pendant qu'elle queue (MyPropertyListenerProc) elle traite le paquet MyPackets Proc.
Je ne sais donc pas exactement là ou cela plante. Faut-il suivre pas à pas ?(Je ne peux pas le faire actuellemet, je suis au boulot, je verrais ce soir), ou il y a un autre moyen avec le SDK et la console par exemple.
Alexandre.
AudioQueueBufferRef fillBuf = myData->audioQueueBuffer[myData->fillBufferIndex];
En effet en retour fillBuf est renseigné avec 0x0.
Euh, les memcpy sont bien plus souvent vecteurs de crash de ce genre que l'allocation hein
Il suffit que le buffer de recopie soit plus petit que la taille indiquée et on arrose !
PS: Mets tu a jour le source en téléchargement dans un précédent post?
En général oui, mais ici j'en doute parce que le problème de taille des buffers est réglé par les fonctions appelées, et parce que cela ne crashe qu'au bout d'un certain nombre d'exécutions.
On a plutôt l'impression d'un engorgement de la zone mémoire attribuée à l'application, dû à certaines désallocations non effectuées : c'est une hypothèse qui expliquerait la différence de comportement entre les deux plate-formes .
Maintenant ces désallocations viennent-elles du code initial ou du mini-code iPhone de al33er ?
A moins que ... ce ne soit pas les bonnes fonctions qui sont utilisées.
As-tu utilisé les frameworks de l'iPhone SDK ou ceux qui sont présents dans le code de Gallagher, qui eux sont pour la plate-forme Mac OS X ?
J'ai essayé de diminuer les allocations mémoires ce matin avant de partir au boulot et j'ai le même souci. J'ai mis 16*128.
PS : Non je ne mets pas à jour le code du premier post. Ce n'est pas le mien.
J'ai bien utilisé le framework iphone de la 2.1.
J'ai essayé de ne pas passer par le NSTHREAD en appelant directement [self stratinternal]. Cela fonctionne mieux , ça ne plante plus, mais au bout d'une trentaine de seconde, il n'y a plus de son.
J'ai donc essayé de diminuer le nombre de kAQMaxPacketDescx et là :adios!: j'ai l'impression que cela fonctionne.
Merci à tous je reviendrai vers vous si je rencontre d'autre soucis.
Alexandre.