Здравствуйте, Анатолий.
07.01.2010 12:48, i_chay пишет: > Если для newfon вы предварительно обрабатываете текст в py-скрипте, то > почему вы ожидаете, что ru-tts будет делать это за вас? > Потому-что ru_tts - это не newfon. :-) > >> NVDA сам обрабатывает пунктуацию). В >> > Orca тоже сам обрабатывает пунктуацию (если пунктуацию еще и синтезатор будет > обрабатывать -- в смысле: читать или не читать, -- то придется каждый раз > синхронизировать настройки скринридера и синтезатора). > Если для SpeechDispatcher Orca не выполняет обработку пунктуации, то имеет > смысл "разместить тикет" в соответствующем месте. > > Да, не выполняет. speech-dispatcher обработку пунктуации перекладывает на синтезаторы. Он передает им параметр уровня пунктуации (none, some, most, all). Так-что это скорее фича orca, чем баг. Хотя мне приятнее слышать локализированую пунктуацию orca, как было раньше с gnome-speech services. >> latency у звукового >> сервера ниже, чем у alsa dmix. >> > Так у вас основную задержку создает не аудиосервер. > Почему? У меня, получается, конвеер задержку вызывает, а у других подписчиков -- нет? Или у меня требования завышенные? Для справки, у меня intel core 2 duo t7250, 2.0 gc. Еще ubuntu 9.10 стоит на нетбуке acer aspire one, у которого intel atom 1.6. Не сказать бы, что разница в отклике на этих машинах заметна. >> Возможно, хорошего отклика можно добится написав нативный вывод на >> pulseaudio без создания кучки процессов на каждое нажатие клавишь. >> > Опять же дело не столько в "нативном выводе", сколько в "каждом нажатии > клавиш", которое инициирует создание конвейера ru_tts | проигрыватель. Если > такой конвейер создавать один раз и обмениваться с ним через канал или сокет, > то издержки на каждое нажатие будут заметно ниже. > Это, наверное, то, что делает multispeech 2. Но в любом случае ru_tts надо перезапускать при изменении параметров речи. >> Но >> это значит создание еще одного велосипеда "yet-another-speech-server", >> чего делать не хочется. >> > Можно оформить в виде C-модуля для SpeechDispatcher (насколько помню, > SpeechDispatcher запускает модули как подпроцессы, а затем прибивает их, но > это не есть серьезное препятствие). > Он запускает модуль 1 раз, и дальше обменивается с ним информацией через stdin/stdout. Убивает при завершении работы. Написание модуля для speech-dispatcher - наиболее простая задача с точки зрения написания кода, но как все это быстрое чудо потом заставить работать с emacspeak? >> Попрежнему остается открытым >> вопрос с кривой обработкой команд протокола dectalk, из-за которого >> multispeech 2 не работает с orca, а, как я понял, протокол не >> документирован... >> > Есть повод предпочесть SpeechDispatcher. > Да. Но см. выше насчет emacspeak. >> Но боюсь, что с моими >> познаниями в linux и опытом программирования под него... >> > В контексте обсуждаемой темы большую часть нужд покроет стандартная run-time > C library. > Я имел ввиду всякие утилиты, коими должен владеть разработчик под linux: automake и иже с ними. -- Blinux-rus mailing list [email protected] http://www.a11ywiki.org/cgi-bin/mailman/listinfo/blinux-rus
