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

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.



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.


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.

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