Re: [Ekiga-list] A comparison ALSA-PULSE (long, addendum)

[Derek Smithies <derek indranet co nz>]

On Tue, 24 Feb 2009, Alec Leamas wrote:

> Derek Smithies wrote:
> > Hi,
> > > > Perhaps it's PTLib underneath it? I really don't know, I'm just throwing
> > > > the idea out there!
> >
> >  It is PTLib which contains the code to read from alsa.
> >
> > Surely, the ideal is not to go via ALSA, but have ptlib directly talk to 
> > pulse. Thus, we need to write a ptlib plugin for pulse audio.
> >
> > We know how ptlib plugins work. There are example plugins for alsa, esd, 
> > oss, sunaudio. The big question is writing a plugin for pulse.
> >
> > What is involved in writing code that talks directly to pulse ?
> > Anyone know example code, or of the pulse api docs?
> >
> > Please don't refer me to docs which say "just use alsa code". We are using 
> > alsa code, and that is why we are having this issue.
> >
> > Derek.


> I think you are right. For the reasons you mention, but also because the 
> current alsa plugin is seriously flawed  I made a short review very late 
> yesterday. Among other things it's synchronized in a way that forces playback 
> and record to wait for each others' I/O operations(!)
Yes - I am aware of this mutex. Have you tried it with this synchronizing 
mutex removed? That mutex has been there since the the plugin was written.

> With this said, I don't (yet) see any problems in understanding and using the 
> external interface. These problems are within the alsa plugin.

> So: with limited resources we have a choice to either "fix" (i. e., major 
> rewrite of) current alsa plugin, or make a pulse plugin.
What is there to rewrite? There are only a few things that are possibly 
wrong - the synchronising mutex and what else? It is, as you say, copied 
from the alsa example docs....

> The latter is most likely easier.
Not really...

> But then we leave platforms without pulse in the dark ages. So 
> question is: do we need a working alsa plugin if we have a pulse one? Anyone? 
> (let's take silence as a "no"  :-) )
A working alsa plugin is a requirement. There may only be 5 % of users 
using alsa, but they will scream loud and long if it does not work for 
them.

Some x11 window environments don't have pulse audio in them. So you need 
pulse and alsa plugins.

> What disturbs me a little is the way the plugin interface "seems" to be,  at 
> least from the alsa example. Question is if there is a way to arrange 
> event-driven  I/O  - current code is strictly polled.
The current code is arranged so that
*the application writes/reads a block of data to/from the sound device.
*this process is timed by the sound device so that the write/read takes as 
long as the framesize of the codec.
Thus, for GSM (20ms frame) the write/read takes 20ms.
It is the sound device that times the sending of UDP packets to the 
remote endpoint. Software timers are very unreliable (in comparison to 
hardware timers, where the board/driver determines the read time as being 
"exactly" 20ms)

Suppose we have 3 GSM frames in each UDP packet. This means that every 
60ms (silence detection disabled) a UDP packet is sent to the remote node.
To do the timing, there is a
 read of 320 bytes, which takes 20ms, encode of audio frame
 read of 320 bytes, which takes 20ms, encode of audio frame
 read of 320 bytes, which takes 20ms, encode of audio frame
 and the three encoded audio frames are placed in a UDP packet which is 
sent to the remote host.

> OTOH, we can live with that, for sure. But there "might* be other hooks 
> in the plugin interface not used today... we might need to 
> backwards-engineer some docs... possibly expanding the plugin interface 
> in a backwards-compatible way....
Sounds pretty hard way to do things.. I think the PTlib developers 
won't be happy with expansion of the plugin interface..

> There is good pulse doc's on their website e. g., 
> http://0pointer.de/lennart/projects/pulseaudio/doxygen/
Thanks for this.
It is a more useful set of documentation than when I last looked for 
pulse-doc like things.


--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek indranet co nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/