similar to: Autoconf

FYI.. ---------- Forwarded message ---------- Date: Thu, 25 Jul 2002 15:41:56 +0200 (CEST) From: Pattara Kiatisevi <ott@linux.thai.net> Reply-To: oggonachip@yahoogroups.com To: oggonachip@yahoogroups.com Subject: [oggonachip] Ogg-on-a-Chip project first phase finished Hi all, Finally our master thesis is finished! Ogg Vorbis player ran with RTEMS operating system on LEON on the FPGA

Hi, in order to understand the Ogg Vorbis decoding algorithm, do you recommend any document/book/www? I have read those on the web page but look for something more detailed.. Thank you very much, Pattara The best things in life are free. - B.G. DeSilva (1927) ---------------------------------------------------------------------- Ott Pattara Kiatisevi T L W G M.Sc. INFOTECH Student,

Hi, as we are trying to implement MDCT in hardware, we are caring now about the "n" (size of input and output vectors to and from MDCT). As I have looked in the code, this "n" is chosen from the Ogg/Vorbis stream data in info.c:_vorbis_unpack_info() which means this "n" can vary aribitrarily (as the power of 2) depending only on the value got from song data? or is

Hi, I wonder if there is specific requirement or restriction for the decoder in order to be consider "Vorbis" compliant (or let's say, to be a "correct" vorbis decoder). I am experimenting with integerized libvorbis and the decoder delivers the audio data as following, (and compare with the floating point version below). $ tail audioout-int.txt 0290670 025e 085c 02cf 0895

Hi all, This is to say hello to all of you as we are starting the project Ogg on a Chip for our master thesis. More information can be found at http://oggonachip.sourceforge.net/. Cut from the homepage: "The Ogg Vorbis Player (http://www.xiph.org/ogg/vorbis/index.html) shall be implemented in form of a system-on-a-chip by using hardware/software co-design techniques. A prototyping board

Hi vorbis-dev, I'm investigating the mdct* function in libvorbis and writing a small client program to test it. I found that I have to set ARRAYSIZE when mdct_init(lookup, ARRAYSIZE) to minimum value of 62 otherwise it will segfault with mdct_backward. Is there any lower limit or it is more likely that my code has bug? Thank you very much, Pattara -- Please avoid sending me Word or

Hi Vorbis, Now I get libvorbis-rc3 + integerized mdct_backward + integerized window running. The sound output is ok. Now we have to go further on possible optimization of the code in order to have the music played realtime on our chip (LEON-Sparc). There are 2 possible ways: 1.Make everything integer, remove all floating point usage. Then we can remove FPU and can run the chip at higher

Hi, Today I tried to run my player code with the CVS libvorbis (instead of RC3 as usual) and I found the infinite loop here (lines prefixed with >> are in the loop): tatic ogg_int64_t _get_prev_page(OggVorbis_File *vf,ogg_page *og){ ogg_int64_t begin=vf->offset; ogg_int64_t end=begin; ogg_int64_t ret; ogg_int64_t offset=-1; >> while(offset==-1){ >>

Better late than never :) jack. --- Ogg Traffic for Tuesday, November 13, 2001 Jack Moffitt <[1]jack@xiph.org> _________________________________________________________________ Table of Contents 1. [2]Support The Ogg Project 2. [3]Status Updates 2.1. [4]Stan Seibert 2.2. [5]Chris Wolf 3. [6]New Developments 3.1. [7]Ogg On A Chip

Hey, I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have a prototype in golang that just spins up an instance of llvm-symbolizer

On Fri, May 4, 2018 at 6:29 PM Walter Lee <waltl at google.com> wrote: > Hi Kostya. Thanks for the quick feedback. I will work on addressing your > comments. > > In regard to initialization checks, I can eliminate most of them by > initializing the shadow memory very early, This will be a very good way to handle this. > but I still need to do something > in two

Hi Jake. Thanks for the info. Where can I keep up to date on the symbolizer status? Our symbolizer is provided by the Myriad vendor and integrated into its host test environment. It doesn't do much: just look for PC string patterns and symbolize them using addr2line. Thanks, Walter On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Hey, > I

Hi Kostya. Thanks for the quick feedback. I will work on addressing your comments. In regard to initialization checks, I can eliminate most of them by initializing the shadow memory very early, but I still need to do something in two places, __asan_handle_no_return and GetFakeStackFast. Would it be ok to have guards for those two places only? Walter On Fri, May 4, 2018 at 6:10 PM Kostya

Hi Walter, I've done a first quick scan. Overall looks reasonable, but I'd like to try reducing the number of newly introduced platform-specific ifs. Vitaly, please also take a look (once my initial comments are addressed). One outstanding issue is your problem with initialization vs checking, which requires you to insert so many ifs. Is there any chance you can avoid this? If you

On RAM... You chose the 32-byte shadow granularity to reduce the RAM overhead, but I am afraid this will actually increase it due to extra alignment requirements, especially if an average allocation on your typical application is small. The pointers are 32-bit, right? Given how RAM-constrained your environment is, maybe you should consider something more like HWASAN instead of ASAN.

https://bugzilla.netfilter.org/show_bug.cgi?id=1661 --- Comment #5 from Gabriel H. <gabriel.haas at aon.at> --- Hi Pablo, sorry for the huge delay... The fact that I didn't comment on your post for such a long time does not mean that I'm not hoping for this feature anymore :D :D Thanks for pointing me to the -I/--includepath option and usage of relative paths. You're right.

I have ported ASan in LLVM to Myriad RTEMS, and I would like to upstream the port. Below is the design doc. Feedback welcome. https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM The port is expected to work with modified versions of RTEMS and newlib. I have a git repo with changes to those projects, that I can make available if there is interest. Here is the patch

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:08.realpath Security Advisory The FreeBSD Project Topic: Single byte buffer overflow in realpath(3) Category: core Module: libc Announced:

Hello there. I tried make update using the following stable-supfile: *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_4 *default delete use-rel-suffix and my two nearest Russian CVS mirrors showed no changes in realpath. Heck, I downloaded the patch and said in /usr/src: # patch < realpath.patch so it was rejected. Then I looked into realpath.c's revision and

Hi, Would anyone be interested in developing a LatticeMico32 backend in LLVM? LatticeMico32 [1] is an open source microprocessor core designed by Lattice Semiconductor and typically used in FPGAs. It is comparable to the Microblaze processor that you already support. It is already supported by GNU Binutils and GCC (4.5+). It is used by the Milkymist [2] and RTEMS [3] projects. The Milkymist