Fui com pocketsphinx_continuous e uma placa de som de US $ 4 .
Para gerenciar o fato de que ele precisa parar de ouvir ao usar o sintetizador de voz, usei o amixer para manipular a entrada de volume no microfone (essa foi a melhor prática recomendada pela CMU, pois o mecanismo de parada de partida resultará em um reconhecimento mais fraco)
echo "SETTING MIC IN TO 15 (94%)" >> ./audio.log
amixer -c 1 set Mic 15 unmute 2>&1 >/dev/null
Com um comando correspondente para silenciar a audição quando o sintetizador de voz é reproduzido
FILE: mute.sh
#!/bin/sh
sleep $1;
amixer -c 1 set Mic 0 unmute >/dev/null 2>&1 ;
echo "** MIC OFF **" >> /home/pi/PIXIE/audio.log
Para calcular os horários certos para silenciar, basta executar o soxi via lua e defina o unmute.sh (oposto ao mute.sh) para executar "x" segundos a partir da inicialização. Não há dúvida de muitas maneiras de lidar com isso. Estou feliz com os resultados desse método.
LUA SNIPPET:
-- Begin parallel timing
-- MUTE UNTIL THE SOUNDCARD FREES UP
-- "filename" is a fully qualified path to a wav file
-- outputted by voice synth in previous operation
-- GET THE LENGTH
local sample_length = io.popen('soxi -D '..filename);
local total_length = sample_length:read("*a");
clean_length = string.gsub(total_length, "\n", "") +1;
sample_length:close();
-- EXAMPLE LOGGING OUTPUT...
--os.execute( 'echo LENGTH WAS "'.. clean_length .. '" Seconds >> ./audio.log');
-- we are about to play something...
-- MUTE, then schedule UNMUTE.sh in x seconds, then play synth output
-- (have unrolled mute.sh here for clarity)
os.execute( 'amixer -c 1 set Mic '..mic_level..' unmute 2>&1 >/dev/null ');
os.execute( 'echo "** MIC OFF **" >> ./audio.log ');
-- EXAMPLE LOGGING OUTPUT...
-- os.execute( 'echo PLAYING: "'.. filename..'" circa ' .. clean_length .. ' Seconds >> ./audio.log ');
os.execute( './unmute.sh "'.. clean_length ..'" &');
-- THEN PLAY THE THING WHILE THE OTHER PROCESS IS SLEEPING
os.execute( './sounds-uncached.sh '..filename..' 21000')
Para realmente pegar a voz no pi, eu uso:
pocketsphinx_continuous -bestpath 0 -adcdev plughw:1 -samprate 20000 \
-nfft 512 -ds2 -topn2 -maxwpf 5 -kdtreefn 3000 -kdmaxdepth 7 -kdmaxbbi 15 \
-pl_window 10 -lm ./LANGUAGE/0892-min.lm -dict ./LANGUAGE/0892-min.dic 2>&1 \
| tee -i 2>/dev/null >( sed -u -n -e 's/^.\{9\}: //p' ) \
>( sed -u -n -e 's/^READY//p' \
-e 's/^Listening//p' -e 's/^FATAL_ERROR: \"continuous\.c\"\, //p') \
> /dev/null
Novamente, existem outras maneiras, mas eu gosto da minha saída dessa maneira.
Para o sintetizador, usei a solução pi incipiente da Cepstrals, mas não está disponível on-line, você deve contatá-los diretamente para combinar a compra e custa cerca de US $ 30. Os resultados são aceitáveis, no entanto, o discurso cria alguns cliques e estalos desagradáveis, a empresa respondeu dizendo que não possui mais um RaspPi e não está disposta a melhorar o produto. YMMV
O reconhecimento de voz fica em torno de 12% da CPU quando "ocioso" e dispara rapidamente ao fazer um pedaço de reconhecimento.
A criação de voz atinge cerca de 50-80% ao renderizar.
O play / sox pesa bastante, mas aplico efeitos em tempo real às vozes renderizadas enquanto as toco;)
O pi é bastante simplificado usando todos os guias que pude encontrar para interromper serviços desnecessários e é executado no modo CLI completo. 800 mhz com over-clock (menor).
scaling_governor definido como: performance
Quando em pleno funcionamento: funciona a cerca de 50ºC sob luz solar direta e 38ºC na sombra. Eu tenho dissipadores de calor instalados.
Último ponto: na verdade, eu uso todo esse equipamento na IA "impulsionada pela Internet" como um ótimo extra.
O pi lida com tudo isso perfeitamente, e reproduz qualquer áudio em rede em tempo real, e áudio totalmente em loop para qualquer outra caixa Unix. etc.
Para lidar com a sobrecarga da CPU de fala grande, implementei um sistema de cache baseado em md5sum para que as mesmas expressões não sejam renderizadas duas vezes. (cerca de 1000 arquivos a 220 mb no total cobrem 70% das declarações que geralmente recebo da IA) isso realmente ajuda a reduzir a carga total da CPU em geral.
Na prática, tudo isso é totalmente factível. no entanto, o reconhecimento de voz será apenas tão bom quanto a qualidade de seus microfones, seu modelo de idioma, quão especificamente as vozes dos sujeitos estão próximas do público-alvo original (eu uso um modelo en_US em crianças en_UK, não é perfeito) e outras minúcias de detalhes que com esforço você pode reduzir a um resultado decente.
E para o registro, eu já fiz tudo isso uma vez antes em um Kindle (e isso também funcionou com cmu esfinge e flite). Espero que isto ajude.