Displaying 10 results from an estimated 10 matches for "old_ps".
Did you mean:
old_fs
2005 Oct 26
4
small patch for preprocess
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: preproc_patch_dth_10_26_05.patch
Type: application/octet-stream
Size: 8774 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20051026/c27a3ed6/preproc_patch_dth_10_26_05.obj
2016 Sep 07
2
Test failures building RELEASE_3.9.0/final
I ran "ninja check-asan" and no errors. But "ninja check-msan" had 117
errors.
I took the first FAILED test, which was for eventfd.cc, and executed the
command
line creating an eventfd executable in a temporary directory and then
executed that file using gdb. Finally, used bt to dump the stack.
I've emailed llvm-admin at lists.llvm.org to setup an account since
2016 Sep 07
2
-fsanitize=memory failing on 3.9.0
I've compiled REALEASE_390/final but all "ninja check-msan" tests are
failing (http://lists.llvm.org/pipermail/llvm-dev/2016-September/104609.html)
I'm waiting for an account to be created to file a bug, but in the
mean time I thought I'd take a look at it myself.
My system is an Arch Linux system that is up to date as of this morning:
$ uname -a
Linux wink-desktop
2005 Oct 31
0
small patch for preprocess
> Add the ability to set adaptation time and min noise duration,
What do you use that for in practice?
> and also provides ability to reset the state of the pre-
> processor via reset function.
that's a good idea.
> Moves initialization of old_ps
> into < 10 block so it doesn't get called as much.
Why?
> The rest
> are just my annoying reformats that happened when I
> was trying to synch my version of preprocess with the
> latest from subversion.
That would actually make it a pain to merge.
> In my version I...
2009 Sep 24
0
High CPU usage
...037 x filters.c :306 sum
17852 x lpc.c :193 d
103519 x ltp.c :67 part
77910 x ltp.c :68 part
69331 x ltp.c :69 part
13687042 x ltp.c :66 part
4209 x ltp.c :263 tmp
55351 x preprocess.c :804 st->old_ps[i]
508 x preprocess.c :807 st->prior[i]
217495 x preprocess.c :892 theta
117888 x filters.c :330 mem[j+1]
==============================================
I hope this is usefull.
Thanks
Mark
-----Original Message-----
From: speex-dev-bounces at xiph.org [mailto:speex-dev...
2016 Sep 07
4
Test failures building RELEASE_3.9.0/final
I've "successfully" built 3.9.0 release but when I run "ninja check-all" I
got 208 Unexpected failures:
Expected Passes : 33997
Expected Failures : 198
Unsupported Tests : 685
Unexpected Failures: 208
Below is the log I captured running "time ninja check-all | tee
ninja-check-all.txt"
https://drive.google.com/open?id=0B-KTY7zi7eZHU2hGYTRtd01QZjA
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've tried to implement new
NOKPROBE_SYMBOL() macro for making kprobe blacklist at
build time. Since the NOKPROBE_SYMBOL() macros can be placed
right after the function is defined, it is easy to maintain.
This series
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've tried to implement new
NOKPROBE_SYMBOL() macro for making kprobe blacklist at
build time. Since the NOKPROBE_SYMBOL() macros can be placed
right after the function is defined, it is easy to maintain.
This series
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Hi,
Here is the version 3 of NOKPORBE_SYMBOL series.
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've introduced NOKPROBE_SYMBOL() macro
for making kprobe blacklist at build time. Since the
NOKPROBE_SYMBOL() macros can be placed right after the
function is defined
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Hi,
Here is the version 3 of NOKPORBE_SYMBOL series.
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've introduced NOKPROBE_SYMBOL() macro
for making kprobe blacklist at build time. Since the
NOKPROBE_SYMBOL() macros can be placed right after the
function is defined