Salut,
Ca pourrait se passer si par exemple tu passes un mauvais timestamp (genre dans le futur), a ce moment rtp_session_send_with_ts() bloque en attendant que ce timestamp arrive... Par exemple si ton timestamp est un int32 au lieu d'un uint32 je ne sais pas ce qui va se passer lorsque lors d'un +=160 ton int32 va devenir negatif. Ceci dit le probleme peut etre a l'interieur d'oRTP ! J'avoue ne jamais avoir teste les sessions de 6h. C'est quoi le clockrate de ton payload audio ? J'aimerais pouvoir verifier.
Tout d'abord merci beaucoup, tu as tapé juste avec les timestamps. J'avais bien pensé aux dépassements de capacités pour l'horloge de ma synchro manuelle, mais bêtement oublié le timestamp. C'était un entier de 31 bits, signé ! Car je le stockais bêtement dans un entier OCaml... Bref, c'est corrigé et ça va mieux... Bien sûr, je continue de faire les synchro manuellement, le passage aux vrais uint32 ne fait pas disparaitre le problème. De toutes façon, pour des raisons relatives à l'interface avec Caml, c'est bien que je puisse faire la synchro moi-même, comme ça les recv/send sont non bloquants...
Pour info on fait du WAV à 44100Hz, 16bits en stéréo, par blocs de 32kB... Le freeze de l'encodeur à 7h collait pile poil avec le dépassement de capacité des entiers caml.
Avant de passer à la suite, précisons. J'ai corrigé ce bug de type du timestamp, c'est tout. L'émetteur se porte bien, mais le recepteur fini toujours par avoir de la donnée supplémentaire, entre autres symptomes étranges. Lors de la dernière expérience, je ne tente pas de vider ces données supplémentaires, et affiche juste un warning. Ca me permet de constater que havemore revient à 0 au bout d'un certain temps. Peut être qu'un chronométrage précis aiderait..
Normalement cela arrive uniquement si justement l'emetteur a emis des paquets plus gros...
Have_more signifie qu'il ya plus de données pour le timestamp donné seulement, ou est il possible que cela signale l'arrivée de nouvelles données sur un timestamp antérieur ? Je dis ça parce que, oui mes timestamps étaient mal gérés, et ils bouclent toujours. Mais je crois que cela ne devrait pas poser de problème, j'envoie quand même à intervalles très larges deux fois des données sur un même timestamp.. Car je peux te garantir que j'envoie toujours la meme taille à un timestamp donné, et que j'oublie pas d'incrémenter ensuite.
Le fait d'utiliser rtp_session_recvm_with_ts() au lieu de rtp_session_recv_with_ts() pourrait t'en dire plus.rtp_session_recvm_with_ts() retourne un mblk_t* Pour avoir les donnees, il faut acceder a: mblk_t *mp; mp->b_cont->b_rptr, la fin du buffer etant marquee par mp->b_cont->b_wptr . mp->b_rptr pointe vers le header, mais normalement tu t'en fous.
Faudra que je regarde, mais pas tout de suite... C'est vrai que ça pourrait me donner une idée, la taille du buffer dispo.
Merci. D'ailleurs je ne sais pas quelle version vous utilisez, mais je viens de mettre une 0.7.0 toute neuve. Mais si vous etes dans la meme equpie que Samuel Thibault je crois que vous avez deja un oRTP top recent (cvs).
On bosse effectivement avec Samuel Thibault, oui. Donc on est à jour.Je te tiens au courant de nouvelles remarques. Si jamais tu changes du code pour passer le cap des 6h, préviens moi je testerais aussi.
Merci pour ton boulot et ta réponse. -- David
signature.asc
Description: OpenPGP digital signature
