Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
4 février 2009 3 04 /02 /février /2009 10:09
Le TCDDK m'offre un challenge à bien des niveaux. Non seulement je découvre la programmation sur DSP et je me forme sur le traitement du signal, mais en plus de cela je dois composer avec les restrictions mémoire très importantes de cette plateforme.

En effet, le DSP 56364 possède 3 RAM différentes :
  • mémoire P : 1,25k x 24 bits pour stocker le programme.
  • mémoire X : 1K x 24 bits pour stocker des données.
  • mémoire Y : 0,75K x 24 bits pour stocker des données.
Il y a aussi des subtilités permettant de faire des vases communiquants entre les mémoires P, X et Y, afin d'allouer plus ou moins de mémoire au programme en prenant sur l'espace des données, mais je ne vais pas vous embêter outre mesure avec ça. Vous l'aurez constaté, le DSP possède vraiment très peu de mémoire.

En particulier, les 1,25k de la mémoire P ne pèsent pas bien lourd, mais c'est cohérent avec le fait que ce programme doit être éxecuté en temps réel sur tous les échantillons sonores reçus, soit 40000 fois par seconde (x2 si on traite le son en stéréo) car le convertisseur analogique / digital fonctionne avec une fréquence de 40KHz. Bon, il y a vraiment intérêt à faire des programmes courts, optimisés, et on comprend pourquoi le développement doit être fait en assembleur ou en C. Un programme en C++ aurait été beaucoup trop gros. Ca me rappelle mes tout premiers programmes sur ZX81 et son glorieux kilo octet de mémoire. Comme quoi les 4 Mo de la DS, c'est vraiment du luxe :)


Heureusement, le TCDDK possède une extension mémoire, une SRAM de 512 Ko permettant d'étendre la mémoire P, X ou Y.

Je bloque actuellement sur l'utilisation de cette SRAM en raison du manque d'info dans la doc de Line 6. Il n'y a qu'un exemple en assembleur DSP 56364, que je ne connais pas et que je vais donc devoir apprendre ne serait-ce que pour décrypter cet exemple. Mes connaissances en assembleur 68000 et 80x86 me permettent de le comprendre dans sa globalité, mais je n'en saisis pas toutes les subtilités.

Et pourtant l'utilisation de cette SRAM est indispensable, soit pour stocker des tableaux importants, des tables précalculées, mais aussi pour bufferiser le signal reçu, afin de réaliser des effets tels que des échos, des délais, des flangers, qui ont besoin de mémoriser le son afin de le mélanger au son traité par la suite. Bon, inutile tout de même de songer à programmer un looper, car les 512 Ko ne permettent de mémoriser que 4,37 secondes de son en mono à 40KHz. On comprend pourquoi la pédale ToneCore Echo Park de Line 6, basée sur la même architecture, annonce un délai d'écho maximum de 2,2 secondes en stéréo.


Je ne dois pas être le seul à éprouver quelques difficultés à coder sur le TCDDK, car le nombre d'effets publiés jusque là est très faible. Je n'en ai compté que 5 alors que le TCDDK est sorti en octobre 2008 :
  • 2 Band Filter EQ, écrit en assembleur (exemple de Line 6)
  • Tremolo, écrit en assembleur (exemple de Line 6)
  • Tremolo 2, écrit en C (Brian Soderberg)
  • BadRubix, écrit en C (Luke Durback)
  • ST-Fuzz, écrit en C (Stravingo)
Ces programmes sont disponibles sur le forum officiel du TCDDK et sur le Wiki officieux. Pour avoir un peu fouillé dans les recoins du net, je n'en ai pas trouvé d'autres. Cher lecteur, si tu as la connaissance d'un autre effet, merci de me le signaler :)

Line 6 a vraiment tout intérêt à diffuser plus d'exemples en C et à étoffer sa doc si il souhaite que son TCDDK touche un plus large public.

Partager cet article

Repost 0
Published by Stravingo - dans Musique
commenter cet article

commentaires