[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

speechd-el "modularity"

From: mk360
Subject: speechd-el "modularity"
Date: Sun, 08 Aug 2010 12:11:28 -0400

        Well, but what about other syntetizers?

El 08/08/2010 8:50, Pierre Lorenzon escribi?:
> Hi,
> I wonder if speechd-el is enough modular. Indeed I am trying to
> implement a direct client to festival without using
> speech-dispatcher. Ideally it would be sufficient to replace
> the ssip driver by a "festival-driver" implementing the
> suitable methods. However it seems that certain task like
> speechd.text are dedicated back to the main speechd library. In
> particular it seems that the speechd.text method is essentially
> the speechd--send-text function which is not driver
> specific. In my mind it should be. I know that speechd-el was a
> speech-dispatcher client at the beginning and that the other
> output modules like brltty came later. Anyway I suspect that
> this architecture is mostly due to historical reasons.
> Now I should explain why I am doing such things. I know that
> speech-dispatcher is a very powerful tool. Anyway my opinion
> speech-dispatcher is not useful for those who only have
> festival as synthesis. Indeed festival has all abilities to do
> what speech-dispatcher is doing provided one write a few lines
> of scheme code. In particular with the recent alsa support in
> festival it seems possible to implement a reasonable speech flu
> scheduler.
> The gain is that instead of two connections in the chain (and 2
> servers, 2 clients) there is only one connection one server,
> one client and hence the system will be more reactive.
> So shall we plan to have more separation of the tasks in
> speechd-el ?
> Regards
> Pierre
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]