Здравствуйте!
>>>>> "Lex" == Lex <[email protected]> writes:
>>> Espeak можно использовать в качестве динамической библиотеки,
>>> тогда синтез и проигрывание речи отлично ложится в процесс
>>> сервера.
Я думал об этом и реализовать это в контексте нового Multispeech
несложно. В конце концов, обеспечение гибких возможностей подключения
различных синтезаторов было для меня одной из приоритетных задач. Но
стоит ли игра свеч в данном случае?
>>> Остается только вызов ru_tts (если учесть, что проигрывание
>>> будет происходить в процессе сервера)
А еще Mbrola и, возможно, еще какие-нибудь дополнительные
синтезаторы. Я думал, например, о Festival, а сейчас думаю еще и о
подключении голосов через wine, о чем в этой рассылке уже заходила
речь.
>> Ну мы же всё таки делаем универсальный сервер. :)
Lex> Ага, а прогнуться под один из синтезаторов для достижения
Lex> увеличения быстродействия (читай уменьшения траты ресурсов)
Lex> никак? :-)
Технически - никаких проблем. Но стоит ли так "прогибаться" именно под
Espeak? Ведь синтезатор этот и так имеет превосходный отклик, а вот
качество речи, увы, пока оставляет желать лучшего и не позволяет мне
рассматривать его в качестве основного. Но возможно я даже
когда-нибудь это и сделаю. Просто для полноты картины. По крайней
мере, я рассматривал такой вариант.
>> Если рассуждать открыто, то плюс внутреннего плеера в сервере
>> заключается скорее не в скорости отклика, т. к. разница
>> возможно будет, но не принципиально большая,
Да, мой опыт это вцелом подтверждает, но зависит от используемого
проигрывателя.
>> а в возможности вызвать функции вроде snd_pcm_drain() в
>> libalsa, для моментальной остановки речи,
Наверное все-таки snd_pcm_drop()? А snd_pcm_drain() как раз доигрывает
буфер, если я ничего не путаю.
На самом деле плохой отклик при использовании внешнего проигрывателя
объясняется главным образом наличием в нем своей внутренней
буферизации, на которую не всегда в должной мере удается повлиять при
помощи параметров запуска. И в некоторой опосредованности управления:
мы лишь запускаем и "прибиваем" процесс, а он уж сам решает что ему
при этом делать и сразу ли реагировать на сигнал останова или все-таки
сначала буфер доиграть.
Lex> А это разве не увеличение отклика?
Еще какое!
Lex> В моем понимании отклик - это не только собственно речь, но и
Lex> все остальные команды, посылаемые пользователем (путем
Lex> нажатия клавиш в клиенте) серверу.
Разумеется. Для нормальной работы речевой отклик должен быть
практически синхронным с нажатиями клавиш. Но почему вообще возникает
такой вопрос? Неужели в Voiceman отклик не достаточно оперативен? Я
абсолютно уверен, что Михаил крепко работал над этой проблемой. О том
свидетельствует хотя бы наличие утилиты trim.
Я сам не пробовал работать с Voiceman, но с Multispeech имею вполне
удовлетворительный отклик, то есть достаточный, чтобы не думать о его
улучшении. А ведь у меня, по моим наблюдениям, пожалуй, самая слабая
платформа из всех участников дискуссии: всего-на-всего обыкновенный
(одноядерный) Pentium IV от Intel, Работающий на частоте 3000 МГц, и
512 Мб оперативной памяти.
С уважением,
Игорь.
--
Blinux-rus mailing list
[email protected]
http://www.a11ywiki.org/cgi-bin/mailman/listinfo/blinux-rus
