On Wed, 21.01.09 20:51, Jason D. Clinton (m...@jasonclinton.com) wrote: > On Wed, Jan 21, 2009 at 1:41 PM, Damien Sandras <dsand...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list