Menu
▾
▴
iaxclient-devel
|
From: Matthew C. <mc...@no...> - 2008-04-23 20:39:42
|
On Wed, 2008-04-23 at 13:57 -0600, Matthew Crane wrote: > Hello all: > > I'm investigating how well the speex echo canceller works in the 2.1 > branch of iaxclient. Whenever I turn on the speex AEC in our client, > the audio that is sent by the client. Sorry... that last sentence should read, "...the audio that is sent by the client is almost completely unintelligible." > Has anyone tested the performance of the speex echo canceller with 8 > kHz-sampled audio? > > -Matt > -- > Matthew Crane > Senior Software Engineer > Novell, Inc. > mc...@no... > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Peter G. <jpg...@gm...> - 2008-04-23 22:06:27
|
Hi Matt, On Wed, Apr 23, 2008 at 4:39 PM, Matthew Crane <mc...@no...> wrote: > On Wed, 2008-04-23 at 13:57 -0600, Matthew Crane wrote: > > Hello all: > > > > I'm investigating how well the speex echo canceller works in the 2.1 > > branch of iaxclient. Whenever I turn on the speex AEC in our client, > > the audio that is sent by the client. > > Sorry... that last sentence should read, "...the audio that is sent by > the client is almost completely unintelligible." > > > Has anyone tested the performance of the speex echo canceller with 8 > > kHz-sampled audio? I've got a patch that's been sat upon for quite a while now that begins integrating the new (or at least greatly improved) speex aec module (introduced in speex-1.2beta2) into iaxclient. I've been holding off committing these changes because the results have really only been verified to be good on Mac. However, I think this code goes in the right direction. Even when the AEC fails to cancel echo, it doesn't make things sound worse. This patch was originally developed by Mihai and I've been using for quite a while now. I believe that there are some general audio quality improvements derived from this patch also. Specifically, there are some compatibility fixes for speex-1.2beta3's agc interface. In the next couple days I will merge this updated AEC patch into trunk. Pete |
|
From: Mihai B. <mi...@ha...> - 2008-04-24 03:46:22
Attachments:
smime.p7s
|
On Apr 23, 2008, at 6:06 PM, Peter Grayson wrote: > Hi Matt, > > On Wed, Apr 23, 2008 at 4:39 PM, Matthew Crane <mc...@no...> > wrote: >> On Wed, 2008-04-23 at 13:57 -0600, Matthew Crane wrote: >>> Hello all: >>> >>> I'm investigating how well the speex echo canceller works in the 2.1 >>> branch of iaxclient. Whenever I turn on the speex AEC in our >>> client, >>> the audio that is sent by the client. >> >> Sorry... that last sentence should read, "...the audio that is sent >> by >> the client is almost completely unintelligible." >> >>> Has anyone tested the performance of the speex echo canceller with 8 >>> kHz-sampled audio? > > I've got a patch that's been sat upon for quite a while now that > begins integrating the new (or at least greatly improved) speex aec > module (introduced in speex-1.2beta2) into iaxclient. I've been > holding off committing these changes because the results have really > only been verified to be good on Mac. However, I think this code goes > in the right direction. Even when the AEC fails to cancel echo, it > doesn't make things sound worse. You can actually find this code in branches/team/mihai/echocan. As Pete said, performance is pretty good on Mac. On windows it seems that it does not work, but at least it doesn't make things worse. The reason seems to be related to crappines in Windows' audio APIs. Performance on Linux has not been tested (at least not by me) Anyways, bottom line is the code currently in trunk does not have functioning AEC Cheers Mihai |
|
From: Matthew C. <mc...@no...> - 2008-04-24 13:11:19
|
On Wed, 2008-04-23 at 23:46 -0400, Mihai Balea wrote: > On Apr 23, 2008, at 6:06 PM, Peter Grayson wrote: > > > Hi Matt, > > > > On Wed, Apr 23, 2008 at 4:39 PM, Matthew Crane <mc...@no...> > > wrote: > >> On Wed, 2008-04-23 at 13:57 -0600, Matthew Crane wrote: > >>> Hello all: > >>> > >>> I'm investigating how well the speex echo canceller works in the 2.1 > >>> branch of iaxclient. Whenever I turn on the speex AEC in our > >>> client, > >>> the audio that is sent by the client. > >> > >> Sorry... that last sentence should read, "...the audio that is sent > >> by > >> the client is almost completely unintelligible." > >> > >>> Has anyone tested the performance of the speex echo canceller with 8 > >>> kHz-sampled audio? > > > > I've got a patch that's been sat upon for quite a while now that > > begins integrating the new (or at least greatly improved) speex aec > > module (introduced in speex-1.2beta2) into iaxclient. I've been > > holding off committing these changes because the results have really > > only been verified to be good on Mac. However, I think this code goes > > in the right direction. Even when the AEC fails to cancel echo, it > > doesn't make things sound worse. > > You can actually find this code in branches/team/mihai/echocan. > As Pete said, performance is pretty good on Mac. On windows it seems > that it does not work, but at least it doesn't make things worse. > The reason seems to be related to crappines in Windows' audio APIs. > Performance on Linux has not been tested (at least not by me) > Anyways, bottom line is the code currently in trunk does not have > functioning AEC > Thanks Pete and Mihai. I'll have a look at the branch. For some reason, I assumed that the requirement for speex-1.2beta3 in the 2.1beta of iaxclient was because of AEC. :-) If I can verify that the latest speex AEC works well inside of iaxclient on linux, I might try getting one of the low-latency Windows portaudio implementations working. In regards to the wmme API, you're right -- it's unusable for AEC. -Matt |
|
From: Mihai B. <mi...@ha...> - 2008-04-24 13:23:37
Attachments:
smime.p7s
|
> If I can verify that the latest speex AEC works well inside of > iaxclient > on linux, I might try getting one of the low-latency Windows portaudio > implementations working. In regards to the wmme API, you're right -- > it's unusable for AEC. Good luck with that. Just to spare you some pain, I've tried Direct Sound, and it does improve AEC performance., but it introduces some other issues, such as audio under/overflows. In addition to that, Portmixer doesn't work with DirectSound, so you won't have volume controls. Let us know how it goes... Mihai |
|
From: Matthew C. <mc...@no...> - 2008-04-24 14:28:38
|
On Thu, 2008-04-24 at 09:23 -0400, Mihai Balea wrote:
> > If I can verify that the latest speex AEC works well inside of
> > iaxclient
> > on linux, I might try getting one of the low-latency Windows portaudio
> > implementations working. In regards to the wmme API, you're right --
> > it's unusable for AEC.
>
> Good luck with that. Just to spare you some pain, I've tried Direct
> Sound, and it does improve AEC performance., but it introduces some
> other issues, such as audio under/overflows. In addition to that,
> Portmixer doesn't work with DirectSound, so you won't have volume
> controls.
This is my first time compiling code checked out from the svn
repository. When trying to run the autogen.sh script in your echocan
branch, autoconf is generating an error when it comes across
"PKG_REQUIRES":
configure.ac:213: error: possibly undefined macro: PKG_REQUIRES
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
Any clue what I need to do to fix this issue? I've got pkgconfig
installed on my system as well as the necessary version of autoconf.
-Matt
> Let us know how it goes...
>
> Mihai
|
|
From: Peter G. <jpg...@gm...> - 2008-04-24 14:36:22
|
On Thu, Apr 24, 2008 at 10:28 AM, Matthew Crane <mc...@no...> wrote: > > On Thu, 2008-04-24 at 09:23 -0400, Mihai Balea wrote: > > > If I can verify that the latest speex AEC works well inside of > > > iaxclient > > > on linux, I might try getting one of the low-latency Windows portaudio > > > implementations working. In regards to the wmme API, you're right -- > > > it's unusable for AEC. > > > > Good luck with that. Just to spare you some pain, I've tried Direct > > Sound, and it does improve AEC performance., but it introduces some > > other issues, such as audio under/overflows. In addition to that, > > Portmixer doesn't work with DirectSound, so you won't have volume > > controls. > > This is my first time compiling code checked out from the svn > repository. When trying to run the autogen.sh script in your echocan > branch, autoconf is generating an error when it comes across > "PKG_REQUIRES": > > configure.ac:213: error: possibly undefined macro: PKG_REQUIRES > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > > Any clue what I need to do to fix this issue? I've got pkgconfig > installed on my system as well as the necessary version of autoconf. Perhaps it is complaining because the PKG_REQUIRES variable is being referenced before it is ever declared. Try writing PKG_REQUIRES="" somewhere before line 213 (e.g. 207). Pete |
|
From: Matthew C. <mc...@no...> - 2008-04-24 16:25:19
|
On Thu, 2008-04-24 at 10:35 -0400, Peter Grayson wrote:
> > This is my first time compiling code checked out from the svn
> > repository. When trying to run the autogen.sh script in your echocan
> > branch, autoconf is generating an error when it comes across
> > "PKG_REQUIRES":
> >
> > configure.ac:213: error: possibly undefined macro: PKG_REQUIRES
> > If this token and others are legitimate, please use
> > m4_pattern_allow.
> > See the Autoconf documentation.
> >
> > Any clue what I need to do to fix this issue? I've got pkgconfig
> > installed on my system as well as the necessary version of autoconf.
>
> Perhaps it is complaining because the PKG_REQUIRES variable is being
> referenced before it is ever declared. Try writing PKG_REQUIRES=""
> somewhere before line 213 (e.g. 207).
>
> Pete
I found the problem. The version of pkgconfig in SuSE Linux Enterprise
Desktop 10 SP1 has the following entry in /usr/share/aclocal/pkg.m4:
m4_pattern_forbid([^_?PKG_[A-Z_]+$])
Basically, trying to define any variables of the form
"PKG_BLAH_BLAH_BLAH" in a configure.ac macro file is a no-no. I've
changed all instances of PKG_REQUIRES in my source tree to
PACKAGE_REQUIRES. If you want to include this change in the trunk so
this issue doesn't hit any other Linux users that happen to have this
pkgconfig setup, here's the diff:
matt:~/src/iaxclient/branches/team/mihai/echocan> svn diff
Index: iaxclient.pc.in
===================================================================
--- iaxclient.pc.in (revision 1421)
+++ iaxclient.pc.in (working copy)
@@ -9,5 +9,5 @@
Libs: -L${libdir} -liaxclient @PTHREAD_LIBS@
Libs.private: @GSM_LIBS@
Cflags: -I${includedir}
-Requires.private: portaudio-2.0 speex @PKG_REQUIRES@
+Requires.private: portaudio-2.0 speex @PACKAGE_REQUIRES@
Index: configure.ac
===================================================================
--- configure.ac (revision 1421)
+++ configure.ac (working copy)
@@ -205,12 +205,14 @@
fi
AM_CONDITIONAL(VIDEO, test x$with_video = xyes)
+PACKAGE_REQUIRES=""
+
has_ogg=no
if test ! x$with_ogg = xno; then
PKG_CHECK_MODULES(OGG, [ogg >= 1.1.3],has_ogg=yes)
if test x$has_ogg = xyes; then
AC_DEFINE(USE_OGG, 1, [OGG])
- PKG_REQUIRES="$PKG_REQUIRES ogg"
+ PACKAGE_REQUIRES="$PACKAGE_REQUIRES ogg"
elif test ! x$with_ogg = xauto ; then
AC_MSG_ERROR([
libogg is required to build this package!
@@ -238,7 +240,7 @@
PKG_CHECK_MODULES(THEORA, [theora >= 1.0alpha7],has_theora=yes)
if test x$has_theora = xyes; then
AC_DEFINE(USE_THEORA, 1, [THEORA])
- PKG_REQUIRES="$PKG_REQUIRES theora"
+ PACKAGE_REQUIRES="$PACKAGE_REQUIRES theora"
elif test ! x$with_theora = xauto ; then
AC_MSG_ERROR([
libtheora is required to build this package!
@@ -254,7 +256,7 @@
PKG_CHECK_MODULES(VIDCAP, [vidcap >= 0.1],has_vidcap=yes)
if test x$has_vidcap = xyes; then
AC_DEFINE(USE_VIDCAP, 1, [VIDCAP])
- PKG_REQUIRES="$PKG_REQUIRES vidcap"
+ PACKAGE_REQUIRES="$PACKAGE_REQUIRES vidcap"
elif test ! x$with_vidcap = xauto ; then
AC_MSG_ERROR([
libvidcap is required to build this package!
@@ -270,7 +272,7 @@
PKG_CHECK_MODULES(FFMPEG, [libavcodec >= 51.40.3],has_ffmpeg=yes)
if test x$has_ffmpeg = xyes; then
AC_DEFINE(USE_FFMPEG, 1, [FFMPEG])
- PKG_REQUIRES="$PKG_REQUIRES ffmpeg"
+ PACKAGE_REQUIRES="$PACKAGE_REQUIRES ffmpeg"
elif test ! x$with_ffmpeg = xauto ; then
AC_MSG_ERROR([
FFmpeg is required to build this package!
@@ -467,7 +469,7 @@
done
AC_SUBST(CLIENTS)
-AC_SUBST(PKG_REQUIRES)
+AC_SUBST(PACKAGE_REQUIRES)
AC_CONFIG_FILES([
Makefile
|
|
From: Peter G. <jpg...@gm...> - 2008-04-24 19:21:10
|
Hi Matt On Thu, Apr 24, 2008 at 12:24 PM, Matthew Crane <mc...@no...> wrote: > On Thu, 2008-04-24 at 10:35 -0400, Peter Grayson wrote: > > > > This is my first time compiling code checked out from the svn > > > repository. When trying to run the autogen.sh script in your echocan > > > branch, autoconf is generating an error when it comes across > > > "PKG_REQUIRES": > > > > > > configure.ac:213: error: possibly undefined macro: PKG_REQUIRES > > > If this token and others are legitimate, please use > > > m4_pattern_allow. > > > See the Autoconf documentation. [snip] > I found the problem. The version of pkgconfig in SuSE Linux Enterprise > Desktop 10 SP1 has the following entry in /usr/share/aclocal/pkg.m4: > > m4_pattern_forbid([^_?PKG_[A-Z_]+$]) > > Basically, trying to define any variables of the form > "PKG_BLAH_BLAH_BLAH" in a configure.ac macro file is a no-no. I've > changed all instances of PKG_REQUIRES in my source tree to > PACKAGE_REQUIRES. If you want to include this change in the trunk so > this issue doesn't hit any other Linux users that happen to have this > pkgconfig setup, here's the diff: Good find. I've committed a fix to trunk. Also, I have committed the new echo cancellation code to iaxclient trunk. This effectively obsoletes Mihai's echocan branch. As Mihai mentioned, the results on Windows have not been spectacular thus far. Using a different API besides wmme might yield good results. Note that I have not yet given up on getting aec working with wmme. One of the primary deficiencies in iaxclient's aec implementation is that it fails to buffer the reference (output) audio stream before feeding it into the speex echo canceler; we just take the reference output audio straight from portaudio and push it into the speex echo canceler. This makes it so that the speex echo canceler's tail has to account for all of the latency through portaudio's output pipeline, over the air, into the microphone, and back through portaudio's input pipeline. The application notes for speex specifically talk about this problem. On systems with low latency, such as Mac, we can get away with this, but on Windows using wmme, the echo canceller's tail is not long enough. The other potential problem affecting aec with wmme is the switch to using a fixed samples per frame with portaudio instead of allowing portaudio to use its natural (and variable) buffer size. I suspect that this may affect how well wmme keeps the input and output audio streams synchronized. It is this input / output synchronization that is most critical to aec working. That's pretty much what I know about aec. Check out audio_encode.c and audio_portaudio.c to see the code in action. Pete |
|
From: Matthew C. <mc...@no...> - 2008-04-25 20:25:01
|
On Thu, 2008-04-24 at 15:20 -0400, Peter Grayson wrote: > Hi Matt > > On Thu, Apr 24, 2008 at 12:24 PM, Matthew Crane <mc...@no...> wrote: > > On Thu, 2008-04-24 at 10:35 -0400, Peter Grayson wrote: > > > > > > This is my first time compiling code checked out from the svn > > > > repository. When trying to run the autogen.sh script in your echocan > > > > branch, autoconf is generating an error when it comes across > > > > "PKG_REQUIRES": > > > > > > > > configure.ac:213: error: possibly undefined macro: PKG_REQUIRES > > > > If this token and others are legitimate, please use > > > > m4_pattern_allow. > > > > See the Autoconf documentation. > > [snip] > > > I found the problem. The version of pkgconfig in SuSE Linux Enterprise > > Desktop 10 SP1 has the following entry in /usr/share/aclocal/pkg.m4: > > > > m4_pattern_forbid([^_?PKG_[A-Z_]+$]) > > > > Basically, trying to define any variables of the form > > "PKG_BLAH_BLAH_BLAH" in a configure.ac macro file is a no-no. I've > > changed all instances of PKG_REQUIRES in my source tree to > > PACKAGE_REQUIRES. If you want to include this change in the trunk so > > this issue doesn't hit any other Linux users that happen to have this > > pkgconfig setup, here's the diff: > > Good find. I've committed a fix to trunk. > > Also, I have committed the new echo cancellation code to iaxclient > trunk. This effectively obsoletes Mihai's echocan branch. As Mihai > mentioned, the results on Windows have not been spectacular thus far. > Using a different API besides wmme might yield good results. Note that > I have not yet given up on getting aec working with wmme. > Unfortunately, it looks like some sort of audio problem has crept in between 2.1beta3 and now (at least on SLED 10). Incoming audio sounds very choppy. I turned echo cancellation off -- problem still there. I compiled using --without-echo-can -- problem still there. I'm going to checkout a version of the trunk from a few days ago to see if the echo-cancellation merge introduced these problems or if it was something earlier. -Matt |
|
From: Matthew C. <mc...@no...> - 2008-04-25 21:16:36
|
On Fri, 2008-04-25 at 14:24 -0600, Matthew Crane wrote:
> Unfortunately, it looks like some sort of audio problem has crept in
> between 2.1beta3 and now (at least on SLED 10). Incoming audio sounds
> very choppy. I turned echo cancellation off -- problem still there. I
> compiled using --without-echo-can -- problem still there.
>
> I'm going to checkout a version of the trunk from a few days ago to see
> if the echo-cancellation merge introduced these problems or if it was
> something earlier.
>
> -Matt
>
More info:
A build of the trunk checked out with "-r {2008-04-20}" has got audio
working correctly. The current trunk as well as Mihai's echocan branch
have both got audio problems (lots of dropouts -- like several per
second) on SLED 10.
-Matt
|
|
From: Peter G. <jpg...@gm...> - 2008-04-28 14:28:34
|
What platform are you running on? Are you seeing the same symptoms on
multiple platforms?
And what is SLED 10?
On Fri, Apr 25, 2008 at 5:16 PM, Matthew Crane <mc...@no...> wrote:
> On Fri, 2008-04-25 at 14:24 -0600, Matthew Crane wrote:
>
> > Unfortunately, it looks like some sort of audio problem has crept in
> > between 2.1beta3 and now (at least on SLED 10). Incoming audio sounds
> > very choppy. I turned echo cancellation off -- problem still there. I
> > compiled using --without-echo-can -- problem still there.
> >
> > I'm going to checkout a version of the trunk from a few days ago to see
> > if the echo-cancellation merge introduced these problems or if it was
> > something earlier.
> >
> > -Matt
> >
>
> More info:
>
> A build of the trunk checked out with "-r {2008-04-20}" has got audio
> working correctly. The current trunk as well as Mihai's echocan branch
> have both got audio problems (lots of dropouts -- like several per
> second) on SLED 10.
>
> -Matt
|
|
From: Matthew C. <mc...@no...> - 2008-04-28 14:43:57
|
On Mon, 2008-04-28 at 10:27 -0400, Peter Grayson wrote: > What platform are you running on? Are you seeing the same symptoms on > multiple platforms? > I haven't tried any other platforms yet. I'll give Windows WMME a try later today, since it looks like the problem is not specific to echo cancellation code (i.e., I've seen the problem when I've built using --without-echo-can). > And what is SLED 10? SuSE Linux Enterprise Desktop 10 -Matt |
|
From: Matthew C. <mc...@no...> - 2008-04-28 20:23:17
|
On Fri, 2008-04-25 at 15:16 -0600, Matthew Crane wrote:
> On Fri, 2008-04-25 at 14:24 -0600, Matthew Crane wrote:
>
> > Unfortunately, it looks like some sort of audio problem has crept in
> > between 2.1beta3 and now (at least on SLED 10). Incoming audio sounds
> > very choppy. I turned echo cancellation off -- problem still there. I
> > compiled using --without-echo-can -- problem still there.
> >
> > I'm going to checkout a version of the trunk from a few days ago to see
> > if the echo-cancellation merge introduced these problems or if it was
> > something earlier.
> >
> > -Matt
> >
>
> More info:
>
> A build of the trunk checked out with "-r {2008-04-20}" has got audio
> working correctly. The current trunk as well as Mihai's echocan branch
> have both got audio problems (lots of dropouts -- like several per
> second) on SLED 10.
Okay, I've found the source of the problem. In audio_portaudio.c, the
framesPerBuffer parameter in calls to Pa_OpenStream() was changed from
paFramesPerBufferUnspecified to SAMPLES_PER_FRAME. When I changed it
back to the old value, audio sounds okay. For whatever reason, the new
value causes very choppy audio playback in SuSE Linux.
I suspect that we will need the fixed value of SAMPLES_PER_FRAME in
order for echo cancellation to work, though, huh? :-)
-Matt
|
|
From: Peter G. <jpg...@gm...> - 2008-04-29 03:40:47
|
On Mon, Apr 28, 2008 at 4:22 PM, Matthew Crane <mc...@no...> wrote:
> On Fri, 2008-04-25 at 15:16 -0600, Matthew Crane wrote:
> > On Fri, 2008-04-25 at 14:24 -0600, Matthew Crane wrote:
> >
> > > Unfortunately, it looks like some sort of audio problem has crept in
> > > between 2.1beta3 and now (at least on SLED 10). Incoming audio sounds
> > > very choppy. I turned echo cancellation off -- problem still there. I
> > > compiled using --without-echo-can -- problem still there.
> > >
> > > I'm going to checkout a version of the trunk from a few days ago to see
> > > if the echo-cancellation merge introduced these problems or if it was
> > > something earlier.
> > >
> > > -Matt
> > >
> >
> > More info:
> >
> > A build of the trunk checked out with "-r {2008-04-20}" has got audio
> > working correctly. The current trunk as well as Mihai's echocan branch
> > have both got audio problems (lots of dropouts -- like several per
> > second) on SLED 10.
>
> Okay, I've found the source of the problem. In audio_portaudio.c, the
> framesPerBuffer parameter in calls to Pa_OpenStream() was changed from
> paFramesPerBufferUnspecified to SAMPLES_PER_FRAME. When I changed it
> back to the old value, audio sounds okay. For whatever reason, the new
> value causes very choppy audio playback in SuSE Linux.
Ah ha. I believe it.
> I suspect that we will need the fixed value of SAMPLES_PER_FRAME in
> order for echo cancellation to work, though, huh? :-)
I think given the way the echo cancellation is currently implemented
that yes, this is true. However, I think a different echo cancellation
implementation that avoids doing sketchy things like fixing the
samples (frames) per buffer to inappropriate values is certainly
possible. I wish I had the bandwidth to address this right now, but I
do not. Maybe someone else out there would like to take a cut at this
one?
Pete
|
|
From: Matthew C. <mc...@no...> - 2008-04-29 20:27:37
|
On Mon, 2008-04-28 at 23:40 -0400, Peter Grayson wrote: > > Okay, I've found the source of the problem. In audio_portaudio.c, the > > framesPerBuffer parameter in calls to Pa_OpenStream() was changed from > > paFramesPerBufferUnspecified to SAMPLES_PER_FRAME. When I changed it > > back to the old value, audio sounds okay. For whatever reason, the new > > value causes very choppy audio playback in SuSE Linux. > > Ah ha. I believe it. > > > I suspect that we will need the fixed value of SAMPLES_PER_FRAME in > > order for echo cancellation to work, though, huh? :-) > > I think given the way the echo cancellation is currently implemented > that yes, this is true. However, I think a different echo cancellation > implementation that avoids doing sketchy things like fixing the > samples (frames) per buffer to inappropriate values is certainly > possible. I wish I had the bandwidth to address this right now, but I > do not. Maybe someone else out there would like to take a cut at this > one? > > Pete Good news: For some reason, playback sounds fine with the fixed samples per buffer when using the ALSA version of PortAudio. The problems with using the fixed samples per buffer appears to be limited to PortAudio OSS. This is all very strange. The reason I started using OSS instead of ALSA was because both iaxclient (using the old paFramesPerBufferUnspecified parameter) and the PortAudio test programs had choppy playback when using ALSA! :-) Next... testing echo cancellation! -Matt |
|
From: Mihai B. <mi...@ha...> - 2008-11-06 17:08:39
|
On Nov 6, 2008, at 12:00 PM, Matthew Crane wrote: > In starting my work, I wanted to see how the current DirectSound- > based portaudio would play with iaxclient. And to my surprise, it > sounds... just fine. I was curious to know under what conditions I > might start to see under/over-flows. Is there any more insight you > might be able shed on these problems you encountered? If I remember correctly, it depends on what devices you use for your audio input/output. For me it failed when trying to use the built in audio in and out and worked fine with USB headsets. It might also depend on what hardware you have (motherboard, audio chipset, etc) Hope this helps Mihai |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X