search for: optomising

Can anyone tell me, or point me in the direction to find, information on speeding up WINE if possible (especially OpenGL)? I'm sure there must be some way that I can do it. While I'm willing to accept it if it is not possible (heck, WINE is incredibly good for alpha software doing what it is doing), programs under WINE tend to be too slow for practical use, so any help on fixing

...to have them, if we already > generate them at the target level properly? Adding > instructions "just because" doesn't seem wise. > > -Owen If you look at it the way you are it sounds fine. :D However, if we have 1 instruction we reduce the amount of time we will spend optomising. I argued on my previous post that rotations are implemented on most machine (x86 platform). Thus it seems right to include 1 instruction in llvm and translate it to 3 instruction older architectures that have not implemented the rotation instruction yet. I am sure that it is only matter of time...

On Feb 3, 2009, at 3:54 PM, Kasra wrote: > I guess the backends could know about the instructions. But I am not > convinced why it is beneficial not to have ROR and ROL instructions > within llvm. > How would it be beneficial to have them, if we already generate them at the target level properly? Adding instructions "just because" doesn't seem wise. -Owen

Thanks Nick for the compile. I think the case for rol/ror is closed. Since LLVM optomises the code into rotations anyway. -- Kasra

Hi, I fixed the distorted audio bug in the XMMS plugin. A small follows below: --- vorbis.c.orig Mon Oct 11 04:05:14 1999 +++ vorbis.c Mon Oct 11 13:47:42 1999 @@ -161,7 +161,7 @@ /* XXX figure out something to put for the bitrate and how to calculate the length of the stream */ vorbis_ip.output->open_audio(FMT_S16_LE, od.vi.rate, od.vi.channels); - vorbis_ip.set_info(filename,

I'm not aware of any additional bits needed. But putting us right at the edge leaves me uncomfortable. So an implementation that isn't limited by the 7 bits in SubclassOptionalData seems sensible. Thanks, -Warren From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Monday, October 2, 2017 12:06 AM To: Ristow, Warren Cc: Hal Finkel; llvm-dev at lists.llvm.org Subject: Re:

--- On Tue, 2/3/09, Bill Wendling <isanbard at gmail.com> wrote: > From: Bill Wendling <isanbard at gmail.com> > Subject: Re: [LLVMdev] rol/ror llvm instruction set > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Cc: kasra_n500 at yahoo.com > Date: Tuesday, February 3, 2009, 2:52 PM > On Tue, Feb 3, 2009 at 2:45 PM, Dale Johannesen

On 10/02/2017 11:10 AM, Bruce Hoult via llvm-dev wrote: > Is there anything that means, in particular, "go fast, even if it > means not all bits are significant"? > > I'm currently working on an llvm-based compiler for a GPU that is > optomised for OpenGL, where 16 bit FP may not be quite accurate enough > (or may be in some cases), but 32 bit FP is overkill. A

Yes, I downloaded the aumix utility and am using it now. Set line in to %50 then %25 and to record but still the same thing. I'm streaming from the line in on the sound card which is being fed from a portable radio nearby. I get the distortion whether I have the audio fed into 'line in' or not. Matt -----Original Message----- From: owner-icecast@xiph.org

Hello, I've searched far and wide on the net and the only thing I've come up with is that no one has ever had this problem. I'm running Icecast 1.3.12 and the latest liveice on a Slackware 8.1 box. The idea here is that I need to stream a live source in multiple bitrates. I am having a problem that is just about going to send me back to Shoutcast. I have set up two