Speech Dispatcher roadmap discussion.

[Luke Yelavich]

On Thu, Oct 09, 2014 at 05:38:24PM AEDT, Halim Sahin wrote:
> Am 09.10.2014 00:36, schrieb Luke Yelavich:
> >CCing to the speechd list, and thanks for your feedback.
> >
> >On Wed, Oct 08, 2014 at 08:02:35PM AEDT, Halim Sahin wrote:
> >>Hi,
> >>Am 08.10.2014 09:32, schrieb Luke Yelavich:
> >>>* Implement event-based main loops in the server and modules
> >>
> >>Pros and cons?
> >
> >Ok, I can think of a few pros, but cannot think of any cons. Someone feel 
> >free to chime in if you can think of any.
> >* Pro - It is non-blocking, which allows Speech Dispatcher to do other tasks 
> >even whilst it is waiting for client activity.
> >* Pro - Allows the possibility for timer based events, i.e if there are no 
> >clients connected, and the server waits for a defined and configurable 
> >period of time, it can perform an action, i.e shut itself down.
> >* Pro - Allows event prioritization, i.e if you want the servicing of 
> >currently connected clients to come first, that can be assigned a higher 
> >priority.
> >* Pro - Allows for the possibility of inotify based file monitoring if 
> >desired, which means the file descriptors are not constantly being polled, 
> >which means less system resource usage. It should be noted that inotify is 
> >linux specific, but other platforms do offer something similar. Since GLib 
> >would likely be doing the work, it will depend on support being implemented 
> >in GLib for the platform in question.
> >
> >>>* Assess whether the SSIP protocol needs to be extended to better support 
> >>>available synthesizer features
> >>ok.
> >>
> >>>* Assess DBus use for IPC between client and server
> >>
> >>I see _no_ advantages to use d-bus at all.
> >>I don't think that a console screenreader like sbl or brltty should use
> >>d-bus to talk to speechd. This would only add more complexity to clients!
> >
> >I personally agree with this, but it was on the original roadmap, so I 
> >decided to add it anyway. If enough evidence can be presented as to why we 
> >should use DBus, then I am willing to reconsider.
> >
> >>>* SystemD/LoginD integration
> >>Ok In fact most distros are using unfortunately systemd.
> >>Please keep backward compatibility. Maybe other systems like **bsd* should
> >>be able to use speechd without having systemd running.
> >
> >SystemD is Linux Specific, so any support for ConsoleKit/SystemD etc would 
> >be enabled at build time, and it will have to be modular, given the need to 
> >support different *nix flavours.
> >
> >>>* Rework of the settings mechanism to use DConf/GSettings
> >>If you realy plan to change the settings stuff to gsettings, make sure that:
> >>1. speechd can be configured without running complete Desktop like gnome.
> >
> >That is certainly possible. Gsettings does have command-line tools to allow 
> >for this.
> >
> >>2. Settings should be accessible without installing a Desktop because many
> >>embedded systems don't have gnome installed. In that case speechd needs to
> >>be configured from plain textconsole.
> >
> >What I had in mind was to refactor spd-conf to be a multi-ui configuration 
> >tool, in that it can provide a text UI on the console, and if desired, a GUI 
> >for graphical desktops. So given that approach, I am sure we can satisfy 
> >point 2 that you raise.
> >
> >>>* Separate compilation and distribution of modules
> >>
> >>FULLACK.
> >>>* Consider refactoring client API code such that we only have one client 
> >>>API codebase to maintain, i.e python bindings wrapping the C library etc
> >>
> >>My thought: maintain only c api and use something like ctypes to use it in
> >>python.
> >
> >Given I am not strong in python, this is one option I always forget about. 
> >Indeed, using ctypes is an option, but perhaps we wrap it in a little python 
> >code to make it easier for developers such that they do not need to know how 
> >to use C types.
> >
> >>>* Moving audio drivers from the modules to the server
> >>Hmm this will make things unstable for a long time. I am not sure if this is
> >>really a problem and it's only a problem in pulseaudio.
> >
> >As I said, its not entirely pulseaudio specific. Even with libao or ALSA, 
> >you may want to have one Speech Dispatcher client coming out of one sound 
> >card, and, and another coming out of a second sound card, and both clients 
> >may wish to use the same speech synthesizer. Moving audio output management 
> >to the server would allow for this. This is something that would likely 
> >require a separate feature branch to be developed, and kept in sync with 
> >master, until it is stable enough to be merged.
> >
> >>Since pulseaudio integration there is no easy way to get audio running in
> >>plain textconsole.
> >>This produces many problems for new users.
> >>Please give it a higher priority and let's try to find a working solution
> >>for it.
> >
> >This issue, while affecting pulseaudio, also affects plain ALSA use as well. 
> >With distros now using session and seat management with Consolekit/LoginD, 
> >the problem has to do with permissions of various device nodes needed for 
> >hardware access, and yes even speakup falls into this category. As it stands 
> >now, it is possible to run Speech Dispatcher et al in your text console user 
> >session, and all should work. The problem arrises when you want an 
> >accessible text login. The reason why GUI login systems work is because the 
> >GUI login manager runs as its own user, and is treated like a logged in 
> >session, allowing for audio devices etc to work. What is needed is for a 
> >special session type to be added to ConsoleKit/LoginD. THis special session 
> >would be run as a separate user, but tat user would get access to audio, 
> >console etc whenever the active vt does not have a logged in user. In other 
> >words, you switch to a text console with a login, and this special session 
> >type is marked as th
> e active
> session. As a result, all processes running under atht special session, i.e 
> Speech Dispatcher and speechd-up, gets access to the audio device hardware 
> and speakup device node, and allows the user to read the console at login.
> 
> I am not sure if I got it right.
> Console screenreaders like sbl or brltty run with root privileges.
> If the screenreader triggers speechd to autospawn the audio system is not
> available for the graphical desktop because pulseaudio opens hw:0.0 which
> fails in that case.
> 
> In speechd.conf audiooutputmethod is set to pulse which is also only usefull
> for graphical Desktops.

The revised system I stated would require that brltty/speechd-up/sbl run as the 
user. These services really don't have any need what so ever to run as root, 
particularly since it is possible to make sure they have access to the device 
nodes they need by giving control of permissions management to 
LoginD/ConsoleKit. You will still be able to run everything as root/system wide 
should you choose to do so, but for the average user, it is better to make sure 
that services only have access to what they need, and nothing more.

Brailcom even go into some detail as to the work that is required to get BrlTTY 
etc to work with this setup. 
http://devel.freebsoft.org/speechd-analysis-speakup-brltty

Luke