search for: vishes

Viswanath Puttagunta wrote: > + SUMM = vdupq_n_f32(0); It kills me that there's no intrinsic for VMOV.F32 d0, #0 (or at least I couldn't find one), so this takes two instructions instead of one. > + /* Consume 4 elements in x vector and 8 elements in y > + * vector. However, the 8'th element in y never really gets > + * touched in this loop. So, if len == 4,

Hello Jean-Marc, Yep, that was it.. with your patch, test_unit_mdct passes for all nfft. So, what you do you suggest the next step here is? Regards, Vish On 8 May 2015 at 12:30, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi, > > Can you apply this change to the MDCT test and run it again. See if more > (all) sizes pass. Given the results, I strongly suspect an

Hello Jean-Marc, Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr = 93.537021 nfft=256 inverse=0,snr = 88.353151 nfft=256

Hi Jean-Marc, Thanks for pointing us the way. Yes it is a overflowing problem. I moved all scaling code in the front of any other operations, and test_unit_mdct passes for all sizes. I will update Ne10 right after Vish double checks it on hardware. He will repost patches with more verification later this week. Regards, Phil Wang Well, I see three questions that need to be answered at this point

Hi All, I used the following script from the dtrace manual to measure how long a particular process runs on the cpu. Modified it to look at the exact timestamps: [i] sched:::on-cpu { self->ts = timestamp; printf("on=%d\n", self->ts) } sched:::off-cpu /self->ts/ { printf("off=%d\n", timestamp) self->ts = 0; } [/i] The output looks like this: [i]on=24591 off=24603

Hi, I have a question regarding RoR and DRb. First of all, I tested with simple client/server examples and everything worked as expected. I have the following lines in my environment.rb: DRb.start_service $rem_obj = DRbObject.new(nil, "druby://#{rname}:9001") Since rem_obj is a global variable, I can call it from any controller and the invoked procedure is run on the server. However,

Hello Jean-Marc, **Resending.. not sure why subject got removed earlier** Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr =

Hello all After installing Mongrel, Mongrel Cluster and all it''s dependencies via gems under FreeBSD. Next I have configured all config/mongrel_cluster.yml for each Rails app, then: % mkdir /usr/local/etc/mongrel_cluster and likend each railsapp.yml to it''s refering app/config/mongrel_cluster.yml My question is, after preparing all base configs now I need to add some rc.d

I'm trying to get these cleaned up and landed, but I'm running into some trouble with this patch. Using commit a08b29d88e3c (July 21) of Ne10, I'm seeing test failures for 60-point FFTs: nfft=60 inverse=0,snr = -3.312408 ** poor snr: -3.312408 ** nfft=60 inverse=1,snr = -16.079597 ** poor snr: -16.079597 ** All other sizes tested appear to work fine (84 to 140 dB of SNR). This

Hi there everybody, We''re having mongrel processes slowly die on us, with a segmentation fault. I''ve seen a few other people mention similar issues. Any info or suggestions would be nice: Error: /var/www/apps/heritage/current/config/../vendor/plugins/file_column/ lib/magick_file_column.rb:7: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i386-linux] Server:

Hello Jonathan, Just FYI, I started doing review of your patch and will get back to you in few days. After review, I would like to rebase your patch (as necessary) myself and do some testing.. and re-submit. Regards, Vish On 4 March 2015 at 09:00, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 3 March 2015 at 22:17, Jonathan Lennox <jonathan at

Hey guys, I used "script/generate controller admin/event" How do I link to the views and the controller when it''s inside a directory. I tried <%= link_to "some link", :controller=>"event",:action=>"index" %> <%= link_to "some link", :controller=>"admin/event",:action=>"index" %> <%=

On Friday, the IC3 (FBI/NW3C/BJA) put out a security advisory on their website that contained a fairly vaguely worded warning about Asterisk systems being compromised and then being used as "vishing" (voice phishing) platforms. They were non-specific on the threat other than to advocate upgrading to "newer versions" of Asterisk. This announcement was done on Friday

Hi All, We are getting these below error on our IMAP server. is this because of open file limits.?? We have set it to 4096. [root at vish conf.d]# ulimit -n 4096 Aug 27 16:08:26 imap(kavish.karkera at example.com-24685): Error: file_dotlock_open() failed with file /data/quarantine/index//data/quarantine/mailstore/24685/.INBOX.kavish.karkera/dovecot.index.cache: Too many open files Aug 27

All, Is there a way to set things up so that requests for static files in either WEBrick or Mongrel will just cause a regular HTTP request and not cause the dynamic routing-based invocation to occur? I had an issue where a request for a missing .js file was causing another request to be registered, thus blowing away my flash data. I tried to do this in my routing file, but I don''t

Hello Tony, opusenc from opus-tools works for me.. Just tried it successfully on my x86_64 Ubuntu Trusty 14.04 box. I was just able to do $ sudo apt-get install opus-tools $ opusenc music_48kbps.wav music_48kbps.opus I remember also being able to compile opus-tools (git://git.xiph.org/opus-tools.git) some time ago. Regards, Vish On 23 February 2015 at 12:30, Tony <yellowjacketlite at

On Mar 3, 2015, at 11:08 PM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 3 March 2015 at 21:59, Jonathan Lennox <jonathan at vidyo.com<mailto:jonathan at vidyo.com>> wrote: Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I

Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I mentioned in the IRC room a problem I discovered in creating my patch, and then later improved the fix Tim had made for the problem. Where do you get conflicts merging it to tip? In terms of merging, you posted your patch before I posted mine, so probably I should be

Hi, Can you apply this change to the MDCT test and run it again. See if more (all) sizes pass. Given the results, I strongly suspect an overflow. Jean-Marc On 08/05/15 01:21 PM, Viswanath Puttagunta wrote: > Hello Jean-Marc, > > Below are the results that show test_unit_dft passes, but > test_unit_mdct fails (only for nfft=480, 960, 1920) > Note: Tested on

Hi Timothy, Sorry for late reply. I have upstreamed the patch to fix the regression here: https://github.com/projectNe10/Ne10/commit/ee5d856cd9cb8c4a15ace567df4239f4e788d043 I have tested it with Vish's branch: http://git.linaro.org/people/viswanath.puttagunta/opus.git/shortlog/refs/heads/rfcv3_fft_fixed) Both unit test dft and unit test mdct passed on ARM v7/v8, floating point/fixed