[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WIP audio in server
From: |
Jeremy Whiting |
Subject: |
WIP audio in server |
Date: |
Mon, 10 Aug 2015 20:21:00 -0600 |
Ok, last patch of the day. Undone items:
1. Audio socket cleanup. Not sure what needs to be done here. Should
the socket files get deleted during shutdown, etc.
2. Stopping audio (probably can be done from parse_stop in parse.c
3. Play command use which is only used in generic.c
BR,
Jeremy
On Mon, Aug 10, 2015 at 7:05 PM, Jeremy Whiting <jpwhiting at kde.org> wrote:
> Ok, another update. This time audio parameters are coming from the
> user's config (I think, GlobalFDSet getting initialized is a mystery
> to me so far because of macros and dotconf callbacks. Seems to work
> here though.
>
> BR,
> Jeremy
>
>
> On Mon, Aug 10, 2015 at 5:43 PM, Jeremy Whiting <jpwhiting at kde.org> wrote:
>> Ok, here's a working patch. A few things I'll fix before this is ready
>> for master though.
>>
>> 1. Audio initialization needs to come from the config files again.
>> 2. Audio socket cleanup.
>> 3. Documentation changes for this big change in how spd works.
>> 4. How to request the server stop playing audio (or maybe it knows
>> because it's telling the modules the same thing...
>> 5. Audio file playback in generic.c needs to open the file and send
>> the audio on the socket.
>>
>> BR,
>> Jeremy
>>
>>
>> On Wed, Aug 5, 2015 at 5:42 PM, Jeremy Whiting <jpwhiting at kde.org> wrote:
>>> Ok, the audio in the server is in it's own thread now, and mostly all
>>> code is in server/audio.c to keep it separate from the other file
>>> descriptor handling for clients. I'm still getting pauses for some
>>> reason, but it is threaded now at least and works when run with -d
>>> also. I'll try to figure out where the pauses are coming from.
>>>
>>> BR,
>>> Jeremy
>>>
>>> On Fri, Jul 31, 2015 at 6:47 PM, Jeremy Whiting <jpwhiting at kde.org>
>>> wrote:
>>>> I've spent a bit of time wrestling with this code today and have found
>>>> the following.
>>>>
>>>> If I don't initialize pulse by calling _pulse_open but only initialize
>>>> once I have data to set the format it works mostly, though there are
>>>> pauses of silence in long phrases from espeak still.
>>>> If I do initialize pulse by calling _pulse_open in pulse_open and also
>>>> reinitializing in pulse_play as required for audio rate changes etc.
>>>> it doesn't play anything somehow (it's getting stuck in pa_simple_free
>>>> on a mutex somehow).
>>>>
>>>> Do I need to run a thread for every audio socket we attach in the
>>>> server? If so what should the thread's start_routine look like, just
>>>> while(1) and the callback audio_process_incoming is called when we get
>>>> traffic on the fd ? Once this is working (and I clean up how we
>>>> initialize the audio to not hard coded values, but get the config from
>>>> the config file) I can look at making the audio use the pulse async
>>>> api, but I want to get the proof of concept working as a first step.
>>>> My knowledge of pthreads seems to be blocking me at the moment though.
>>>>
>>>> thanks,
>>>> Jeremy
>>>>
>>>>
>>>>
>>>> On Thu, Jul 30, 2015 at 7:42 PM, Jeremy Whiting <jpwhiting at kde.org>
>>>> wrote:
>>>>> Oops, I didn't see this until just now. At any rate I got that issue
>>>>> solved, now only playback failing (I verified I get samples in the
>>>>> server and I think it's initializing the AudioId properly since it's
>>>>> not NULL here. It seems to think it's playing from all the return
>>>>> values, but I hear no audio yet. I also wasn't sure what to do about
>>>>> sending the audio parameters just yet, so hard coded some based on my
>>>>> config here for now.
>>>>>
>>>>> BR,
>>>>> Jeremy
>>>>>
>>>>> On Thu, Jul 30, 2015 at 6:40 PM, Luke Yelavich
>>>>> <luke.yelavich at canonical.com> wrote:
>>>>>> On Fri, Jul 31, 2015 at 10:40:04AM AEST, Luke Yelavich wrote:
>>>>>>> On Fri, Jul 31, 2015 at 07:27:27AM AEST, Jeremy Whiting wrote:
>>>>>>> > Hey all,
>>>>>>> >
>>>>>>> > I'm implementing moving audio from the modules to the server (and
>>>>>>> > modules will send audio data to the server on a unix socket). I've got
>>>>>>> > the socket creation, and seem to have the ability to connect to the
>>>>>>> > socket in the modules but it's hanging here when I try to run spd-say
>>>>>>> > hello. Also I'm getting this in my speech-dispatcher.log as if it's
>>>>>>> > trying to open a second audio connection from sd_espeak for some
>>>>>>> > reason when it hangs (and no log output after this):
>>>>>>> >
>>>>>>> > [Thu Jul 30 15:03:15 2015 : 829380] speechd: Adding audio
>>>>>>> > connection on socket 4
>>>>>>> > [Thu Jul 30 15:03:29 2015 : 105629] speechd: Adding module on fd 28
>>>>>>> > [Thu Jul 30 15:03:29 2015 : 105654] speechd: Adding audio
>>>>>>> > connection on socket 4
>>>>>>> >
>>>>>>> > I'm probably doing something obviously wrong, but can't seem to see
>>>>>>> > what at the moment though I've been beating my head against it for a
>>>>>>> > while and debugging. Can you see anything obvious in my changes?
>>>>>>>
>>>>>>> Well, I wonder if what you have in speechd_audio_connection_new is
>>>>>>> correct. You make reference to module sockets and the server socket
>>>>>>> where clients connect, and not the audio socket.
>>>>>>
>>>>>> Helps if I attach the diff.
>>>>>>
>>>>>> Luke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Moving-audio-from-modules-to-the-server.patch
Type: text/x-patch
Size: 58681 bytes
Desc: not available
URL:
<http://lists.freebsoft.org/pipermail/speechd/attachments/20150810/1174ea62/attachment-0001.bin>