@Neox : car il ne faut pas oublier que, dans ton cas aussi, plus tu as de micros, plus tu auras de flux à analyser pour savoir ce qui se passe et dans quelle piece.
ce n'est pas qu'un RPI qui travaille… Jarvis tourne sur chaque RPI (1 RPI/pièce).
Pour le moment webx, c'est un RPI qui pilote tout (mysql, nginx, services xpl-perl) Les services perl font des requêtes à la base de données locale. Les autres RPI pour le moment ne me servent qu'au multiroom audio.
Mais demain, je compte monter un cluster de 4 RPI ou chaque noeud fera tourner mon projet webx. Les services xPL-tourneront sur tous les RPI, excepté mysqld et ngninx.
Dans cette configuration là, je modifierai mes scripts pour m'adresser à l'adresse ip virtuelle du cluster (le noeud actif). Les requêtes faites à la base de données provenant des autres RPI (select/insert/update/delete) seront faite via le réseau au noeud actif (c'est à dire sur l'adresse ip virtuelle), celui qui hébergera mysql et nginx.
L'intérêt évident à cette configuration est d'avoir un moteur décisionnel décentralisé et que si le noeud actif tombe, un autre puisse redémarrer la base de données… là où se pose mon problème c'est sur les réplications dans les bases de données des autres RPI… Mais c'est un autre débat
[^] # Re: Merci bcp pour votre intérêt pour le sujet
Posté par popof . En réponse au message Array microphone + reconnaissance vocal. Évalué à 0. Dernière modification le 12 juin 2013 à 18:17.
@Neox : car il ne faut pas oublier que, dans ton cas aussi, plus tu as de micros, plus tu auras de flux à analyser pour savoir ce qui se passe et dans quelle piece.
ce n'est pas qu'un RPI qui travaille… Jarvis tourne sur chaque RPI (1 RPI/pièce).
Pour le moment webx, c'est un RPI qui pilote tout (mysql, nginx, services xpl-perl) Les services perl font des requêtes à la base de données locale. Les autres RPI pour le moment ne me servent qu'au multiroom audio.
Mais demain, je compte monter un cluster de 4 RPI ou chaque noeud fera tourner mon projet webx. Les services xPL-tourneront sur tous les RPI, excepté mysqld et ngninx.
Dans cette configuration là, je modifierai mes scripts pour m'adresser à l'adresse ip virtuelle du cluster (le noeud actif). Les requêtes faites à la base de données provenant des autres RPI (select/insert/update/delete) seront faite via le réseau au noeud actif (c'est à dire sur l'adresse ip virtuelle), celui qui hébergera mysql et nginx.
L'intérêt évident à cette configuration est d'avoir un moteur décisionnel décentralisé et que si le noeud actif tombe, un autre puisse redémarrer la base de données… là où se pose mon problème c'est sur les réplications dans les bases de données des autres RPI… Mais c'est un autre débat
J'espère que vous me suivez :-)