Re: New module decisions for 2.26

[Lennart Poettering <mztabzr 0pointer de>]

On Wed, 21.01.09 20:51, Jason D. Clinton (me jasonclinton com) wrote:

> On Wed, Jan 21, 2009 at 1:41 PM, Damien Sandras <dsandras seconix com> wrote:
> > Perhaps pulseaudio developers could try ekiga before we write a
> > pulseaudio plugin for it ?
> 
> Lennart's last blog post on the matter[1] indicated that we should be
> using alsa--not writing pulseaudio plugins for our apps. So, it should
> Just Work... This is how I have been working on a private git branch
> for Gnome Games. I didn't see that ticket 23 until now. Quite scary.
> 
> [1] http://0pointer.de/blog/projects/guide-to-sound-apis-followup.html

#23 is obsolete. I tracks a bug in ALSA, not in PA and I thus forgot
to close it when it was fixed in ALSA upstream. It's closed now.

After a rough peek at libpt (the ekiga sound abstraction library) I
see a couple of misuses of the ALSA API. Most problematic is that it
misunderstands the concept of periods: it seems to map the codec's
frame size 1:1 to the period size. That is not a good idea and misses
the point of periods. PA is forced by these small periods settings
into a low-latency behaviour that quite often doesn't work out, due to
a kernel/drivers that make the scheduling latency quite
unreliable. Normal hardware isn't really suffering by the problem
because it usually has much stricter limits on the period/buffer sizes
it supports. 

Now, this stuff should be fixed on two sides: firstly, PA should not
try to fulfill latency requests as blindly anymore and enforce
stricter limits on the latency settings. Right now, we assume that
applications know what they do and we try to fulfill whatever the
clients request -- the client is king. Secondly, libpt should not
misuse periods like this.

There are a couple of other issues where libpt/Ekiga should not do
what it is doing (the enumeration code is really evil, as one
example). That said, the code is actually not bending the ALSA API
that bandly as a lot of other applications are doing it.

If I find the time to I will have a look into making Ekiga work better
on PA in the next weeks.

Oh, and please don't misunderstand my suggestion not to port
applications to the native PA API. If your application already uses an
abstraction API then it makes perfect sense to add a native PA
backend for it too, to avoid the "stacking abstractions"
mess. However, applications that don't want to play the abstraction
game should link exclusively to ALSA for now unless they have a very
specific reason not to. The "safe" ALSA subset is the best abstraction
we have right now.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4