Dummy speechd-el output driver possibly for running speechd-el inside emacs on android

[Peter Vágner]

Hello,

I have been looking into this yesterday. It took me a while to realize I
don't know how to do this properly.
In fact the first mistake I did is that I haven't even completelly
understood that email message from 2010 I have linked to. When comparint
GLib thread to pthreads, GLib one is not cancellable and speech-dispatcher
cancels threads in a few places I have seen so far.
This really needs some planning and knowledge of the project I assume. At
least I don know if we can try reworking most of the pthreads into
cancellable tasks as explained here
https://developer.gnome.org/programming-guidelines/stable/threading.html.en#when-to-use-threading
also avoiding mutexes or this is not applicable here. Perhaps this is why
you have added GLib support for more obvious things and leaved pthreads as
they are for the time being as it's not trivial at all.

As a hack somehow making speechd-el interfacing with espeak would perhaps
be more easier short term solution for what I'm after however I am unable
to do it either so it will only remain as a theoretical speculation for now.

Greetings

Peter

2017-11-02 9:57 GMT+01:00 Peter V?gner <pvdeejay at gmail.com>:

> Hello,
>
> Huh, I'm afraid I am not proficient enough so I would be able to rework
> speech-dispatcher handling to work with gthreads instead of pthread.
> Newertheless I've taken a look at the GLib threading docs
> https://developer.gnome.org/glib/stable/glib-Threads.html . By some quick
> look at the speech-dispatcher code (I've only looked at espeak module so
> far as I do know espeak API so it's easier for me to understand what's
> espeak and what's speech-dispatcher side of things...) comparing it with
> the functions and types documented in these GLib docs I think g_thread* and
> g_mutex* calls and types are pretty much in sync with its pthread
> counterparts. So changing these should not be very difficult task given the
> fact speech-dispatcher already makes some extensive use of GLib functions.
> I was able to find this old discussion which supports my understanding of
> the matter at https://mail.gnome.org/archives/gtk-app-devel-list/
> 2010-October/msg00072.html
> As an addition I've started looking at pthread semaphores. Or more
> specifically I need to have these reimplemented in order to be able to
> build on Android. and discovered this stack overflow question along with
> the accepted answer: https://stackoverflow.com/
> questions/10711258/implement-a-semaphore#18550188 .
>
> Is this a way to go or am I missunderstanding the matter?
> Might I be able to try out porting some modules one after the other this
> way when working with speech-dispatcher or do I have to look at
> speech-dispatcher as a whole when doing this?
> As a proof if I might actually be able to do this my-self I'm thinking
> reworking espeak module to use GLib threads in place of pthread.
> What do you think should I try or might this be better suited for an
> experienced developer avoiding risks that I might inadvertently break
> something else I may not be aware of at all?
>
> Thanks and greetings
>
> Peter
>
>
> 2017-11-02 0:08 GMT+01:00 Luke Yelavich <themuso at themuso.com>:
>
>> On Thu, Nov 02, 2017 at 07:15:57AM AEDT, Peter V?gner wrote:
>> > Given all this I would like to try getting speechd-el working with such
>> a
>> > setup.
>> > So I do have emacs, I do have speechd-el, I do have espeak built against
>> > libpulse, however the glue between speechd-el and espeak is missing. I
>> > can't build speech-dispatcher on termux because android pthreads
>> support is
>> > too limited for speech-dispatcher to build there.
>>
>> My desire is to eventually have all of speech-dispatcher code use GLib's
>> own
>> threads API, which afaikis usable on Android. In fact using as much GLib
>> as
>> possible would allow uses of speech-dispatcher on other platforms,
>> Android,
>> Mac OS, etc.
>>
>> > Since speechd-el has an API that more output drivers can be running at
>> the
>> > same time or even independently of each other I think it might be more
>> > viable than fighting pthreads on android  trying to create a kind of
>> very
>> > simple output driver for speechd-el.
>>
>> There is documentation for the SSIP protocol which is used over either a
>> unix
>> socket or inet socket. The docs are in the speechd git tree. It would be a
>> matter of implementing code to parse and interract with that protocol and
>> wrap espeak or even Android's own TTS API.
>>
>> Longer term though, I do think getting speech-dispatcher building more
>> easily
>> on android may be a better solution, patches welcome of course.
>> --
>> Please check out my Patreon campaign and spread the word.
>> https://patreon.com/lukefoss
>>
>> _______________________________________________
>> Speechd mailing list
>> Speechd at lists.freebsoft.org
>> http://lists.freebsoft.org/mailman/listinfo/speechd
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20171103/a6bea87c/attachment.html>