Audacious LazyUSF Alpha

February 10th, 2010

As i have recently installed a Linux distro on my laptop that i can actually use (and tolerate), which is Ubuntu (fedora you have failed me again ;) , i have been spending some time working on the Audacious Version of LazyUSF.

Although it is yet anywhere near release-worthy (more-like pre-alpha), I’m releasing this in it current state for people who might be remotely interested. But, as i said before it is not complete, and there are guaranteed to be bugs with it, and some features (like fading) aren’t implemented yet, so for the brave souls that do wish to try it, i hold no responsibility for loss of data,computer,sanity,life etc.

Precompiled binaries (for Audacious 2.3, x86 Ubuntu 9.10…) : lazyusf32.so.bz2
Precompiled binaries (for Audacious 2.3, amd64 Ubuntu 9.10…) : lazyusf.so.bz2

Or the source code (remember ubuntu, can’t guarentee it will compile on anything else), you can get from svn at svn://joshw.info/lazyusf

woo.

Read the new comic con review here.

LazyUSF update

February 3rd, 2010

Ok, seems i wasn’t as thorough with testing is as i probably should of been. I left something in it which crashes certain sets in the recompiler, which is now fixed, as well as a mysterious problem which caused some to occasionally not work.
Also i removed certain (minor) optimizations which required the need for CPUs to have SSE2, so it should work if they do not now.

Get the new version here

LazyUSF

January 31st, 2010

Woo, no updates in 18 months ftw.

Now that foobar2000 1.0 is out people started telling me that foo_input_usf crashes when used in it, despite it working for me correctly every time i try.
Well, that gave me slightly more incentive to complete work on a player derived from a slightly different source (as opposed to a port of 64th Note). This one was created from something that I’ve been making for Audacious, called LazyUSF (which that should hopefully be finished soon).

There are quite a few differences in it, such as Timing problems that I’ve tried to rectify (although this can only be helped to a certain degree due to technical limitations that were originally implemented in the USF format, and fixing it would break lots of sets horribly), and cleaner Cpu code.

So, without futher ado, i give you LazyUSF

Ciao.

xmms usf player

May 9th, 2008

Here’s a thing i’ve had around for almost a year, but i never go ’round to releasing. I never did this, because at the time i was wanting to implement the new c++ core, but due to me putting it off this still may be a while.

There still may be some problems with it, but it seems to run just fine for me.
It’s got no config, or interface yet, the settings are Recompiler Cpu, RSP_SECTIONS, Fast Seek, logarithmic fading, 3 minute default length.

Build for x86: libusf.so.bz2

New foo_input_usf

April 11th, 2008

Ok, after several months due to the complexity and many issues arising during the development of this, this newest version of foo_input_usf is here.
Most of the issues in the previous version have been fixed, which include running multiple instances (when converting, so this is now possible), tag writing and better memory handling.

-Josh

foo_input_usf update

November 28th, 2007

I’ve made a small fix to foo_input_usf, where the USFLib of sets would not be loaded from inside archives other than rar, yes, i accidental hard-coded “rar” into the loading code and then forgot about, so that has been fixed and updated.

Also, after reading a post on a forum i read that someone tried to convert a lot of USFs to mp3, and it crashed. Well, foo_input_usf is based on Project64, which doesn’t really like to run more than once at a time.
Seeing this occur prompted me to be crazy and am now in process of rewriting the plug-in from the original code and putting all Project64 CPU code into it’s own classes to separate them to allow multiple threads of the plug-in to run at the same time.
So i’ll put that up when i have got something stable running.

-Josh

completing usf sets

November 21st, 2007

After a period of many months of inactiveness, i’ve decided to get off my rear and put in an effort to complete some USF sets.
In this case either myself, or someone else has provided names/times for each of the tracks, and in some cases a re-rip is necessary to make sure that the tracks play correctly.

After some surveying of what has been sent, and after being prodded a bit i am in process of completing these sets:

  • Duke Nukem: Zero Hour
  • Gauntlet Legends
  • Wipeout 64
  • Ridge Racer 64
  • Banjo Tooie
  • San Francisco Rush 2049
  • Rush 2
  • Bomberman 64 – The Second Attack

So i should have these done and up within a few days :)

blog & exceptions

November 17th, 2007

Well, this is another way to which i have attempted an half-assed attempt at trying to populate my site with something useful. Useful being the key word. I actually am writing something, unlike my mediawiki attempt, and cool, this saves drafts…good for when the power goes out, like it was doing this morning…nothing like the sounds of power transformers down the street blowing up to motivate me to save my work, but considering im on my laptop it doesn’t matter the slightest to me.

Now for the useful.

I’ve been attempting to find a suitable replacement for what windows calls structured exception handling (SEH), in linux.
SEH works similar to regular exceptions, but it can handle all non standard exceptions like segmentation faults and invalid instructions and the like, and allows the programmer to handle these in a (hopefully) non-crash way and gracefully let the user know or do something else.
In linux, this doesn’t exist as availably as it does in windows, because visual c has __try and __except blocks that can be made easily. The internals of this work by all windows programs have a pointer to an exception handler structure at the start of memory pointer by the fs register (fs:[0]) and this is called when something goes wrong. Linux however, has no such thing.

Linux does have signals, and advanced ways to handle them. A signal in Linux, is an exception in Windows.

Linux’s way of handling these is via a function called sigaction, sure there is also signal function, but that in this instance is useless.
sigaction allows the programmer to select exactly what signals need to be handled, and allows a function handler to be specified for them. Now the useful part here is not only does it catch the signals, but then allow the program state to be changed before returning to the exact same spot where the signal occurred…like in windows.

For example, lets say a segmentation fault occurs, because i wrote to an invalid memory pointer, i would then be able to catch this signal (SIGSEGV), know exactly where im trying to write to, and exactly where in my program it is doing so from, but i can simply alter the memory location by overwriting the faulting instruction or skipping over it entirely.

Now this is extremely useful because some programs require this effect, for example in Project64. For Project64 which deals with this behavior quite a bit to be ported to linux, or and part of its CPU, this code would need to be modified to allow the exceptions to be caught this way.
Well, its what ive been trying to figure out lately anyway.

Example Code