similar to: SpeexDSP AEC into ffmpeg api

Hello, alsa-plugins currently includes speex/speex_types.h, but that doesn't work with speexdsp versions >= 1.2rc2, since speex_types.h has been replaced with speexdsp_types.h. I made a patch for alsa-plugins, so that it includes speexdsp_types.h instead. I also bumped the speexdsp version check from "1.2" to "1.2rc2" in configure.ac, since speexdsp_types.h didn't

Processing Conflict: speexdsp-1.2-0.9.rc3.el6.x86_64 conflicts speex <= 1.2-0.21.rc1 I am loath to replace things on my primary workstation as I have far too much to do as it is without dealing with self-inflicted injuries. However, I do use Jitsi as a softphone and the latest version has a dependency on a package in EPEL which replaces something from the base distro. Can someone inform me

I've filed a bug for aarch64 https://github.com/xiph/speexdsp/issues/7 and provided the port in a fork with a pull request. We need someone to review/merge in the pull request? It provides the source code, but my testing was under Android builds, so there would be some configure changes needed to build it stand alone. On Tue, Apr 19, 2016 at 4:32 PM, Frank Barchard <fbarchard at

From: Tanu Kaskinen <tanu.kaskinen at linux.intel.com> Not everyone who includes speexdsp_config_types.h will have a test which defines those, and if we've chosen to use the stdint types at configure time then we know exactly which header(s) are available, so just choose the best one then and generate the header to use it. This patch, including the above text, is copied from a commit

Hi, On Sat, Mar 28, 2015 at 2:34 PM, Evan JIANG <firstfan at gmail.com> wrote: > Hi all, > > (Sorry that may be duplicated that I was not a mail-list member before, > so last mail sent failed) > > I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I > build with i386, X86_64, armv7 and armv7s all passed. > But when I build for ARM64 (for

Hi all, I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC preprocess.lo CC jitter.lo CC mdf.lo CC fftwrap.lo CC

On Thu, Jul 09, 2015 at 12:23:17PM +0300, Tanu Kaskinen wrote: > Hello, > > alsa-plugins currently includes speex/speex_types.h, but that doesn't > work with speexdsp versions >= 1.2rc2, since speex_types.h has been > replaced with speexdsp_types.h. Strictly speaking it hasn't been "replaced", it's just supplied by speex rather than speexdsp, as was the

Complains about missing Int16 functionality. So for 64bit on Arm you have to compile without –enable-neon and that has a huge effect on the AEC functionality. The Pi3 with neon is just struggling with the AEC routines as its audibly better on a Pi4 but its not the garble that a Pi0 produces. Without the neon on the Pi3 the 1.2 – 1.85 perf boost of neon with FFT is lost and it really effects AEC

Hello everyone, while I've been a user of both Vorbis and Speex since about 2005, this is the first time I write to the dev mailing list. I created ports for both SpeexDSP and Speex for Ravenports and have a question regarding the status of SpeexDSP. Ravenports is a new universal package building system for *nix systems that supports Linux, FreeBSD, DragonflyBSD and Solaris (with

anyone know how to get the aarch64 fork pulled into the mainline speexdsp? The code is provided in the bug report https://github.com/xiph/ speexdsp/issues/7 On Fri, Jul 29, 2016 at 5:21 PM, Frank Barchard <fbarchard at google.com> wrote: > I've filed a bug for aarch64 > https://github.com/xiph/speexdsp/issues/7 > > and provided the port in a fork with a pull request. We

Thanks ... > Those links seem to work here. 2 links "http://rarewares.hydrogenaudio.org" redirect to "https://hydrogenaud.io" ... no "rarewares" subdomain "http://git.xiph.org/speex.git" maybe better "http://git.xiph.org/?p=speex.git;a=summary" "http://git.xiph.org/speexdsp.git" maybe better

FTR, my main concern with this kind of approach is the case where your platform has two compilers, only one of which has stdint.h Jean-Marc On 07/05/2015 11:10 AM, Tanu Kaskinen wrote: > From: Tanu Kaskinen <tanu.kaskinen at linux.intel.com> > > Not everyone who includes speexdsp_config_types.h will have a test > which defines those, and if we've chosen to use the stdint

Hello list, Hope you are all doing well! I am facing a problem when compiling Asterisk 16.8.0 in a CentOS 6 box and I wonder if someone can put some light on it. Log history short, install_prereq fails to install the packages (not sure how important they actually are....): speexdsp-devel, gmime-devel, uriparser-devel, iksemel-devel, uw-imap-devel, hoard Then, I am running the following commands

Hi all, (Sorry that may be duplicated that I was not a mail-list member before, so last mail sent failed) I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC

Hi I'm new to speex list but joined because I'm needing to port the Neon to ARM64. On that function, saturate_32bit_to_16bit(), I noticed the ifdef's are wrong. The first version is for normal arm 32 bit arm and should be used for arm32 and thumb2 but not thumb1. The second version is 32 bit neon and should be #ifdef __ARM_NEON__ I've done a third version which is 64 bit neon.

Hi all, I'm updating OpenEmbedded-core's speexdsp from 1.2rc1 (when it still was a part of the speex source tree) to 1.2rc3. I found out that building the new version for aarch64 fails in resample_neon.h (the target machine is OE-core's default qemuarm64 target). This is the error message: .../speexdsp-1.2rc3/libspeexdsp/resample_neon.h:148:5: error: impossible constraint in

I have * box on machine with external ip address and internal one I'm tring to register to it from to machines - one from innternet ( everything is ok - in sip.conf nat=yes)\ and the other one is in the internal network (in sip.conf - nat=no ) and it say 403 Forbidden? Any Ideas ? here are the logs and configs From the external SIP Client whic registers.

Hello Tristan, Thank you. But I am using libspeex library. Does the speexdsp library be included in it? Or it needs to be installed separate. Appreciate the help. Thanks, Ankhit On Thu, Aug 20, 2015 at 11:43 AM, Tristan Matthews <tmatth at videolan.org> wrote: > Hi Ankhit, > > On Thu, Aug 20, 2015 at 12:06 PM, Ankhit Vivekananda < > ankhit.vivekananda at biscotti.com>

Hi apols as not really speex dev but really struggling to find this info that sure you will know in an instant. I am trying to compile alsa-plugins so I get the speexdsp as well as the rate conversion and just don’t know how. pi at raspberrypi:~/alsa-plugins-1.2.2 $ arecord -D mic ALSA lib dlmisc.c:287:(snd1_dlobj_cache_get) Cannot open shared library

I recently stumbled upon <speex/speex_resampler.h> and made a chain of discoveries: - "http://speex.org/downloads" some links are broken ("rarewares" and git) - there is some (minor) development (whitespace and more) of the "dead" Speex codec ... will there be a release? (I don't really need such myself) - there is some (more useful?) development of the