speechd-discuss
[Top][All Lists]
Advanced

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

Audio output in libao and Pulse (was: the libao driver)


From: Steve Holmes
Subject: Audio output in libao and Pulse (was: the libao driver)
Date: Mon, 11 Oct 2010 08:08:55 -0700

I don't know if this has to do with my post from yesterday where I
observed sluggish performance with the libao output method or not.  My
system uses alsa as the chosen method specified in libao.conf but when
I use libao in speechd, it takes over half a second to stop current
speech and general key echoing seems to lag by a similar amount of
time.  When I switch back to alsa, all is snappy again with no other
changes. to my system.

On Mon, Oct 11, 2010 at 01:07:32PM +0200, Hynek Hanke wrote:
> On 20.9.2010 11:24, Hynek Hanke wrote:
> >On 14.9.2010 14:34, Chris Brannon wrote:
> >>There's a serious deficiency in the libao library: it doesn't have
> >>any sort of stop function.
> >Well, this seems to be a bigger problem. I don't understand
> >though why did libao decide not to implement stop(), given
> >that most of its backends support it.
> 
> It's been pointed out that neither the current Pulse Audio
> backend uses any kind of stop() functions, so there is
> not really any difference.
> 
> In both cases, very small amount of data is being sent
> to the audio backend and stoping is handled simply
> as not sending any more data. The buffers have a fixed
> size of 256 bytes.
> 
> This seems to me as very suboptimal. The former Pulse
> Audio backend used to try to send as much data as available,
> but I was never very familiar with it, so I can't explain exactly
> how does stopping work in the asynchronous API.
> 
> Perhaps, if the audio backend is doing its own buffering
> to prevent dropouts, we are not thinking about network
> transport and CPU usage is not a big concern, this solution
> might be good enough and it makes code simpler and more
> stable. In the result, when we consider the end user experience,
> the current pulse backend seems better.
> 
> I'm however still a bit concerned about the implications the
> current solution could have and whether we can rely on it.
> 
> If somebody could explain, why that actually is not any
> problem, we should re-consider libao as the primary audio
> backend.
> 
> Best regards,
> Hynek Hanke
> 
> 
> _______________________________________________
> 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]