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

[Rui Batista]

Hi,
Seg, 2010-10-11 ?s 13:07 +0200, Hynek Hanke escreveu:
> 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.
> 
Neither volume setting... I only know how to change speech-dispatcher
volume in pulseaudio using the pulseaudio control application. Last time
I checked, the pulseaudio simple API had no way to set volume.

Moreover, with the corrent pulseaudio driver (and  supose, libao), we
can not handle latency changes and so on in pulseaudio. When routing
speech-dispatcher sound to a pulseaudio server on the netowrk this is
noticiable (I tried that.).
Sometime ago I tried reimplementing the pulseaudio driver using the
asynchronous API but never had something usable. Is it worthwile to
retry something like this? I.G. re-re-rewriting the pulseaudio driver
using the async API? This time from scratch, not using xmms code or
something.
It idoesn't seem an easy task but it's doable with some time.

> 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.
> 
I think the current driver drains the stream when stopping... but anyway
it is CPU consumming sending 256 bytes at each time. We should send
whatever we can and stop if needed. There is a way to do this without
copying any data to pulseaudio internal buffers, so it is not dependent
on the size of the buffer.

I'm talking from what I recall of pulseaudio API, if I'm wrong in
something please correct me.

> 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 can  notice some differences in speed from my corei7 to my netbook.
You say: ok, one has 4 cores the other has one. But under eavy workloads
in the netbook I notice that speech+pulseaudio are consumming a good
ammount of CPU.

> 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.
> 
I?m not a big fan of libao, at least regarding to pulseaudio. It's
another extra layer and, if we need better control when dealing with
pulseaudio, it is not that flexible. For alsa output it seems better
than the current situation.
IMO libao is not not the "one-feetsall" soluction for speech-dispatcher
but having a driver for it like we have now works better for some
people.

Regards,

Rui Batista
> Best regards,
> Hynek Hanke
> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd

-- 
Rui Batista
E-mail/googletalk: ruiandrebatista (at) gmail (dot) com
MSN/WLM: ruiandrebatista (at) hotmail (dot) com (don't send mail to this
one)
Skype: ruiandrebatista
twitter: http://twitter.com/ragb
weblog: http://unreliabledevice.net