similar to: Divided by Zero Error Speex-dev Digest, Vol 34, Issue 12

Hi, I've encoded the GSM AMR narrow band stream "T01.pcm" using narrow band speex encoder at 24.6kbps. When I try to decode this file using the fixed point speex decoder, it is giving Divided by Zero error in the function multicomb(). Can anybody encountered these type of problems earlier?? if yes, what should be done as rectification?? Thanks & Regards, T. Jyothiprakash

Hi Marc, I've downloaded the Speex1.2Beta version. In the code still there are some float variables are used for the Narrow band decoding. In the file "nb_celp.c" .93 is getting multiplied with the GAMMA_SCALING [Line number From - 1341 - 1351] Can please tell me weather the 1.2Beta version has complete narrow band decoding in fixed point?? Thanking you, Regards, T

Hi, In fixed point speex code there is no where satuartions checks are used. The basic arithmetic operations like ADD,ADD32,SUB,MUL etc. are just directly implemented without the saturation checks. Can u please comment on this. For the speex decoder testing, is there any standard streams? if yes from where can i get those? Thaking you all, Yours, Jyothiprakash Reddy, T

Hi, Can you please share the standard document of Speex codec. I have the api doc and speex manual but it doesnt have the details about the mode of operation and bitrate details etc., So can u please give us those details. Thanks & Regards, Jyothiprakash Reddy, T --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers

We should only add phis that were newly inserted, not ones that were already found. There are two cases we will hvae inserted phis: Part of the recursive call, or right in this function. The easiest way to differentiate new phis from old ones is whether they have 0 operands. I expect the attached will fix it. If not, please file a bug with reproducible IR. On Sun, Sep 24, 2017 at 11:40 PM,

I understand that changing the starting element to “InsertedPHIs.being() + StartingPHISize” it will be finite but given that InsrtedPHIs is finite. I have a case where one element(same element is appened to InsertedPHIs) is added to InsertedPHIs every time fixupDefs is invoked. I traced the issue why this was happening. template <class RangeType> MemoryAccess

Hi, Can some one explain the intended behaviour of following loop in void MemorySSAUpdater::insertDef(MemoryDef *MD, bool RenameUses) function. while (!FixupList.empty()) { unsigned StartingPHISize = InsertedPHIs.size(); fixupDefs(FixupList); FixupList.clear(); // Put any new phis on the fixup list, and process them FixupList.append(InsertedPHIs.end() - StartingPHISize,

On Sat, Sep 23, 2017 at 9:55 AM, Godala, Bhargav-reddy < Bhargav-reddy.Godala at amd.com> wrote: > > With regards > Bhargav Reddy Godala > Software Engineer 2 > Bangalore, India > E-mail: Bhargav-reddy.Godala at amd.com Ext 30678 > > > > On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Sat, Sep 23, 2017 at

With regards Bhargav Reddy Godala Software Engineer 2 Bangalore, India E-mail: Bhargav-reddy.Godala at amd.com<mailto:Bhargav-reddy.Godala at amd.com> Ext 30678 On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> wrote: On Sat, Sep 23, 2017 at 8:38 AM, Godala, Bhargav-reddy via llvm-dev <llvm-dev at

3.7.19 Thanks and Regards, Ram From: Pranith Kumar Karampuri [mailto:pkarampu at redhat.com] Sent: Friday, July 07, 2017 11:54 AM To: Ankireddypalle Reddy Cc: Gluster Devel (gluster-devel at gluster.org); gluster-users at gluster.org Subject: Re: [Gluster-devel] gfid and volume-id extended attributes lost On Fri, Jul 7, 2017 at 9:20 PM, Ankireddypalle Reddy <areddy at

Ram, I sent https://review.gluster.org/17765 to fix the possibility in bulk removexattr. But I am not sure if this is indeed the reason for this issue. On Mon, Jul 10, 2017 at 6:30 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > Thanks for the swift turn around. Will try this out and let you know. > > > > Thanks and Regards, > > Ram > > *From:*

On Fri, Jul 7, 2017 at 9:20 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > Pranith, > > Thanks for looking in to the issue. The bricks were > mounted after the reboot. One more thing that I noticed was when the > attributes were manually set when glusterd was up then on starting the > volume the attributes were again lost. Had to stop glusterd

Thanks for the swift turn around. Will try this out and let you know. Thanks and Regards, Ram From: Pranith Kumar Karampuri [mailto:pkarampu at redhat.com] Sent: Monday, July 10, 2017 8:31 AM To: Sanoj Unnikrishnan Cc: Ankireddypalle Reddy; Gluster Devel (gluster-devel at gluster.org); gluster-users at gluster.org Subject: Re: [Gluster-devel] gfid and volume-id extended attributes lost Ram,

Ram, As per the code, self-heal was the only candidate which *can* do it. Could you check logs of self-heal daemon and the mount to check if there are any metadata heals on root? +Sanoj Sanoj, Is there any systemtap script we can use to detect which process is removing these xattrs? On Sat, Jul 8, 2017 at 2:58 AM, Ankireddypalle Reddy <areddy at commvault.com> wrote: >

@ pranith , yes . we can get the pid on all removexattr call and also print the backtrace of the glusterfsd process when trigerring removing xattr. I will write the script and reply back. On Sat, Jul 8, 2017 at 7:06 AM, Pranith Kumar Karampuri <pkarampu at redhat.com > wrote: > Ram, > As per the code, self-heal was the only candidate which *can* do > it. Could you check

We lost the attributes on all the bricks on servers glusterfs2 and glusterfs3 again. [root at glusterfs2 Log_Files]# gluster volume info Volume Name: StoragePool Type: Distributed-Disperse Volume ID: 149e976f-4e21-451c-bf0f-f5691208531f Status: Started Number of Bricks: 20 x (2 + 1) = 60 Transport-type: tcp Bricks: Brick1: glusterfs1sds:/ws/disk1/ws_brick Brick2: glusterfs2sds:/ws/disk1/ws_brick

Ram, If you see it again, you can use this. I am going to send out a patch for the code path which can lead to removal of gfid/volume-id tomorrow. On Mon, Jul 10, 2017 at 5:19 PM, Sanoj Unnikrishnan <sunnikri at redhat.com> wrote: > Please use the systemtap script(https://paste.fedoraproject.org/paste/ > EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr

Hi, I am new to speex library. I am doing project in VC++. My project details are, I have to capture voice from mic and encode it then decode and play. I am capturing the voice and storing in a buffer from there i am reading frame by frame ( 160 bytes) . These bytes i am converting to short int then calling speex_encode-int(). The output buffer i am passing to doder speex_decode_int() function.

Please use the systemtap script( https://paste.fedoraproject.org/paste/EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr calls. It prints the pid, tid and arguments of all removexattr calls. I have checked for these fops at the protocol/client and posix translators. To run the script .. 1) install systemtap and dependencies. 2) install glusterfs-debuginfo 3) change the path

On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > 3.7.19 > These are the only callers for removexattr and only _posix_remove_xattr has the potential to do removexattr as posix_removexattr already makes sure that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr happens only from healing code of afr/ec. And this can only happen