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

On Tue, 24 Feb 2009, Alec Leamas wrote:

Derek Smithies wrote:
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.


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.,
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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]