[mary-dev] Could AudioPlayer be a interface?

Paulo Levi i30817 at gmail.com
Fri Oct 16 22:04:54 CEST 2009


You could send it base 64 encoded.
One of the nits about this is that to split the data you'd need to
translate the time to a number of bytes read (or emit  a end tag when
you emit silence (that has it's own bugs as i reported in the last
ticket i opened - punctuations are sometimes considered silence or not
emitted at all - i am hacking around it, but i don't think its 100% -
i just mark when there is a <boundary> with duration and skip spaces
and punctuations instead of just spaces while finding the next word).

On Fri, Oct 16, 2009 at 6:57 AM, Marc Schroeder <schroed at dfki.de> wrote:
> I think it is a very good idea to clean up the audio player "corner". Yes it
> is unsatisfactory to have various different audio players. I don't
> particularly care if they are threads or Runnables, as long as they play the
> audio.
>
> Feel free to suggest an interface and to outline how the different
> implementations of audio players could be adapted to implement it:
>
> the freetts audio player;
> the MARY audio player (marytts.util.data.audio.AudioPlayer)
>
>
> The other idea, embedding audio into XML, could you make that clearer
> please? How would you embed binary data into an XML document?
>
> Regards,
> Marc
>
> Paulo Levi schrieb:
>>
>> I'm trying to do audio streaming, and besides the interface being
>> slightly unfriendly (all strings, misdocumented - wrong order and
>> number of arguments) i'm having the problem that i've made a my own
>> version of the audioplayer (to support pausing) and i can use it in
>> the streaming call.
>>
>> AudioPlayer should not extend thread, but implement runnable. If
>> you're want to allow people to join() it, return the thread
>>
>> Besides that i actually think that streamAudio should not create a
>> thread, or at least have a variant that doesn't, since i am already
>> dividing my speakable tasks into a thread, simply because i don't want
>> to block the edt (or any other event thread that this voice can be
>> called on).
>>
>> On another matter i've thought about a way that you can support
>> notifications without another client thread. You could embed the audio
>> into a xml file (bettwen the pause information). So that a streaming
>> audioplayer would read the next audio - send notification -next audio
>> -send notification.
>> _______________________________________________
>> Mary-dev mailing list
>> Mary-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/mary-dev
>
> --
> Dr. Marc Schröder, Senior Researcher at DFKI GmbH
> Coordinator EU FP7 Project SEMAINE http://www.semaine-project.eu
> Portal Editor http://emotion-research.net
> Team Leader DFKI Speech Group http://mary.dfki.de
>
> Homepage: http://www.dfki.de/~schroed
> Email: schroed at dfki.de
> Phone: +49-681-302-5303
> Postal address: DFKI GmbH, Campus D3_2, Stuhlsatzenhausweg 3, D-66123
> Saarbrücken, Germany
> --
> Official DFKI coordinates:
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
> Geschaeftsfuehrung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
> Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
>


More information about the Mary-dev mailing list