Re: [Ekiga-devel-list] pulseaudio support (was Re: What's missing for 3.2.1)

[Dave Allan <dallan redhat com>]

Peter Robinson wrote:
> On Tue, Apr 28, 2009 at 3:45 PM, Dave Allan <dallan redhat com> wrote:
> > Peter Robinson wrote:
> >
> > > To add the 3.4 (or possible 3.2.x release would be the pulse audio
> > > plugin. I've tried it as a patch to ptlib but it seems to lock up for
> > > me but I haven't had the time to compile up ptlib/opal/ekiga trunk and
> > > test with it. It would also be nice to have upnp (possibly with gupnp
> > > now that there's confirmation it works on Windows.
> > Are you actively working on pulseaudio support?  I've downloaded and built
> > the ptlib/opal/ekiga trunks.  There is a pulse plugin in ptlib, which works
> > with its own test code but is broken when ekiga tries to use it.  I've only
> > just begun to look into what's wrong, not to mention that I can only work on
> > it very intermittently.  Is your patch on top of what's in the tree already
> > (it sounds like it's separate)?  We should coordinate our efforts.
>
> No, the patch that I was testing was straight from the ptlib svn
> trunk, nothing further than that. I basically saw ekiga lock up when
> trying to use it.
>
> Peter

Peter,

If you're willing to try an experiment, I managed to get sound to play 
from ekiga through the pulse plugin.  My SIP server disagrees with 
something that ekiga is sending in the call setup, so I can't make 
calls, but here is a patch to apply on top of the ptlib pulse support 
that caused me to be able to play test sounds.

The patch makes two changes: 1) it sets the lastWriteCount so that ekiga 
doesn't think the audio write failed and 2) it changes the sample rate 
and number of channels that the pulse plugin expects.  I'm guessing that 
the sample rate and number of channels need to be negotiated between 
ptlib and opal/ekiga, but I haven't tried to do that.

If the lockup goes away but you have garbled audio on the call, try 
removing the changes to sample rate and number of channels, as it was 
set to 8k/1ch which I would think is correct for most codecs.  The patch 
changes them to 44.1k/2ch which is correct for test sounds, but I would 
expect to be wrong for an actual call.

Dave


Index: sound_pulse.cxx
===================================================================
--- sound_pulse.cxx	(revision 22476)
+++ sound_pulse.cxx	(working copy)
@@ -74,8 +74,8 @@
   os_handle = -1;
   s = NULL;
   ss.format =  PA_SAMPLE_S16LE;
-  ss.rate = 8000;
-  ss.channels = 1;
+  ss.rate = 44100;
+  ss.channels = 2;
 }
 
 
@@ -188,6 +188,8 @@
     return PFalse;   
   }
 
+  lastWriteCount = len;
+
   PTRACE(6, "Pulse\tWrite completed");
   return PTrue;
 }
@@ -228,8 +230,8 @@
 // Get the sample rate in samples per second.
 unsigned PSoundChannelPulse::GetSampleRate() const
 {
-  PTRACE(6, "Pulse\tGet sample rate return 8000");
-  return 8000;
+  PTRACE(6, "Pulse\tGet sample rate return 44100");
+  return 44100;
 }
 
 // Get the sample size in bits per sample.