Приветствую всех.
> на вход к ru_tts надо
> активно процессить, без этого вобще не возможно работать. Ни пунктуация,
> ни английские буквы, ни даже мягкие/твердые знаки им просто не
> обрабатываются. Я выдрал функции из драйвера newfon для NVDA, и оформил
> их в питоновский скрипт.
Если для newfon вы предварительно обрабатываете текст в py-скрипте, то почему
вы ожидаете, что ru-tts будет делать это за вас?
> NVDA сам обрабатывает пунктуацию). В
Orca тоже сам обрабатывает пунктуацию (если пунктуацию еще и синтезатор будет
обрабатывать -- в смысле: читать или не читать, -- то придется каждый раз
синхронизировать настройки скринридера и синтезатора).
Если для SpeechDispatcher Orca не выполняет обработку пунктуации, то имеет
смысл "разместить тикет" в соответствующем месте.
> latency у звукового
> сервера ниже, чем у alsa dmix.
Так у вас основную задержку создает не аудиосервер.
> Возможно, хорошего отклика можно добится написав нативный вывод на
> pulseaudio без создания кучки процессов на каждое нажатие клавишь.
Опять же дело не столько в "нативном выводе", сколько в "каждом нажатии
клавиш", которое инициирует создание конвейера ru_tts | проигрыватель. Если
такой конвейер создавать один раз и обмениваться с ним через канал или сокет,
то издержки на каждое нажатие будут заметно ниже.
> Но
> это значит создание еще одного велосипеда "yet-another-speech-server",
> чего делать не хочется.
Можно оформить в виде C-модуля для SpeechDispatcher (насколько помню,
SpeechDispatcher запускает модули как подпроцессы, а затем прибивает их, но это
не есть серьезное препятствие).
> Или это и есть пресловутый linux way?
Есть Unix way, а Linux это не Unix :)
Если речь о конвейерах и "классическом" Unix прошлого века, то "угу". .. :)
> Попрежнему остается открытым
> вопрос с кривой обработкой команд протокола dectalk, из-за которого
> multispeech 2 не работает с orca, а, как я понял, протокол не
> документирован...
Есть повод предпочесть SpeechDispatcher.
> Но боюсь, что с моими
> познаниями в linux и опытом программирования под него...
В контексте обсуждаемой темы большую часть нужд покроет стандартная run-time C
library.
Успехов. Анатолий.
--
Blinux-rus mailing list
[email protected]
http://www.a11ywiki.org/cgi-bin/mailman/listinfo/blinux-rus
