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

[Rui Batista]

Hi,
Seg, 2010-10-11 ?s 21:11 +0200, Halim Sahin escreveu:
> Hi,
> On Mon, Oct 11, 2010 at 04:15:18PM +0100, Rui Batista wrote:
> > Hi,
> > 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.
> 
> Hmm, this was not a big problem for me.
> The synths do volume adjustments and using pulseaudio to control
> individual volumes is one of the power features :-).
> 
Then if some synth doesn't support volume setting we get stuck. Don't
count on users to set volume in pulseaudio, it is confusing at least.

> > Moreover, with the corrent pulseaudio driver (and  supose, libao), we
> > can not handle latency changes and so on in pulseaudio. When routing
> 
> Yes, this is the only difference between libao and the pulseaudio driver
> in speech-dispatcher.

Not is isn't. With libao you can not set properties for the connection
(i.g. a11y special handling), you can not configure the prebuffering as
effectively as in the curren t pulse code (even with the simple API).

> The latency-setting could be added to libao (which is more easy) than
> rewriting from scratch.

Yes, if the libao devs agree to that. Remember that in some situations
the pulse server changes the latency, we need a wayy to detect that
(callbacks in the async API) and reset that.

> Don't forget that the new approach to pulse works and is well usable.

Agreed, it is.

> Maybe we should prepare a small patch for libao's pulse plugin to add
> the missing feature.
> 
Libao's pulse plugin uses the simple or async API? If the former I don't
think it is possible, it is the same as the current pulse driver.

> > speech-dispatcher sound to a pulseaudio server on the netowrk this is
> > noticiable (I tried that.).
> 
> Yes I have tested this as well.
> 
> 
> > 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.
> 
> Well the problem is not the driver that sends much data. The problem is
> pulseaudio resamples afaik all incoming audio samples which is cpu
> consuming.

Maybe. Anyway I don't like the thread waking up every 256 bytes. If
pulse can access the woll buffer without copies (with the async api) it
seems better to leave that to the pulse lib. But this is in a
hepothetical cenario where we use the async API.

> I see not a noticable cpu consumtion on my netbook using libao->alsa.

It seems some people has problem with latencies on that setup. I didn't
test so just can tell what I've been reading.

> Giving pulseaudio larger buffers would result in bigger latencies (see
> the old driver).

If you wait to play until you have some data in the buffer
(prebuffering) yes. If you tell pulseaudio to play a big buffer without
copying as soon as it can that problem doesn't appear. So no
prebuffering. But the size of the buffer is not dependent on
prebuffering settings, at least there should be a way to don't do that.
a
> 
> > I'm talking from what I recall of pulseaudio API, if I'm wrong in
> > something please correct me.
> 
> After libao started working I spent no time to pulseaudio.
> 
Ok.

> > 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 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.
> 
> Well the working and usable pulse driver wouldn't be possible if we
> don't cloned it from libao.

I don't consider it a real clone but that's just my opinion. with the
old driver, on way or another, the pulse stuff had to be rewriten.
Thanks to bill and Mark to making it possible anyhow.

> Sure there are some finetuning stuff missing, but it should be added to
> libao and used in speechd by additional parameters to the library.
> 
If it is the easier and more fleixible way I agree. I don't think it is
the easy way so... But that is just my opinion.

> > 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.
> 
> NACK. It's the most stable and usable one which is available for
> speech-dispatcher

For your setup I belive it is. For mine the pulse driver is works
better.
e
> It's,alsa oss support works really well and the pa stuff could be easily
> added. As i can remember it was only one different parameter to
> pulse-sijmple api which the pulseaudio driver in speechd uses
> differently.

I can remember at least two. Te prebuffering stuff and the a11y
property. But the code talks for itself and I'm really tired to see more
code today :).
> 

Regards,

Rui Batista


> CIAO.
> halim
> 
> 
> _______________________________________________
> 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