non, mon point de vue est légèrement nuancé: oui on peut dans l'absolu mettre n'importe quel codec sur ton dsp, aujourd'hui ils sont assez puissant pour faire tout ce que l'on veut. Mais si ton fournisseur ne te vent pas les bonnes primitive, tu vas devoir le redévelopper. C'est possible. Mais personne ne le fera.
Ce qui compte, in finé, c'est ce qui abouti dans un produit. Les hypothèses, les possibilités, sont bien joli, mais ce qui compte c'est le monde réel. Et dans le monde réel, les fondeurs n'ont pas du tout une approche "libre". C'est leur coeur de métier, et "ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.
Et, pour reprendre mon argumentaire, au final, on s'en contre ficher. Il te faut quoi pour développer sur ton pc? gcc. dans l'absolu. Sur ton mobile? le simulateur android par exemple (google à eu la bonne approche sur ce coup là). Ou un petit gcc-arm par exemple. Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent), les connecteurs, un os debug dessus.... Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).
Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.
Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!
A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 2.
Ce qui compte, in finé, c'est ce qui abouti dans un produit. Les hypothèses, les possibilités, sont bien joli, mais ce qui compte c'est le monde réel. Et dans le monde réel, les fondeurs n'ont pas du tout une approche "libre". C'est leur coeur de métier, et "ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.
Et, pour reprendre mon argumentaire, au final, on s'en contre ficher. Il te faut quoi pour développer sur ton pc? gcc. dans l'absolu. Sur ton mobile? le simulateur android par exemple (google à eu la bonne approche sur ce coup là). Ou un petit gcc-arm par exemple. Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent), les connecteurs, un os debug dessus.... Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).
Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.
Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!
A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).