Re: [NEW] eq-xmms

[Edd Barrett]

Edd Barrett wrote:

Jacob Meuser wrote:

On Mon, Jul 04, 2005 at 02:41:35AM -0500, Edd Barrett wrote:

On 7/4/2005, "Jacob Meuser" <[EMAIL PROTECTED]> wrote:

On Mon, Jul 04, 2005 at 11:32:47AM +0100, Edd Barrett wrote:

Hello,


file format, not just mp3.

I've had great results with this piece of software EQ'ing my vorbis


The configure script is linux-centric. It reads /proc/cpuinfo to see
what arch your machine is and if it has SSE and MMX and all the other

patched the configure script to not make that assumption. Its a dirty
hack I know.

I did try playing around with cpudetect.c and I tried things like
getting arch from param.h, but they ended up being even dirtier ,as it
has already made the x86 assumption.

What do you guys think?

Here is a port for eq-xmms. A plugin that will allow equalization of any files, but as for the build, I'm not sure and would like your opinions. buzzwords. If this fails (obviously in obsd it does) then it assumes x86 . I tried building on my sparc and it failed. For now all I have done is

I think you are abusing WANTLIB and forgetting about LIB_DEPENDS.

also, I think a better name would be xmms-equ.  note that the other
xmms plug-ins are named xmms-<whatever>.

--
<[EMAIL PROTECTED]>

--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net

Hi,

Thanks for yor comments, I will look into that.

Did you have any comments on the build itself? Did you take a look at
cpudetect.c and configure? As I say, I'm unsure the best way to patch
this to build.

generally speaking, only MMX should be built into i386 binaries.

don't forget, that the ports system is used to make packages, and
packages are the preferred method of installing software.

also remember that packages may be built on a "fast" machine, but
used on a "slow" machine.

so, unless you can test building the packages on a machine where SSE/
SSE2 is supported, and the packages work on, say, a 486, it's best to
disable extended cpu capabilities.

the other option is to make an "optimized" flavor, such as with
multimedia/mjpegtools.

IMO, disable optimizations until the rest of the port is OK.  then
more people can test if the extended code works.  according to the
$HOMEPAGE, it looks like they've had some problems with this stuff
anyway.

Hi again,

Im not sure about your WANTLIB concern.



WANTLIB=                X11 Xext Xi gdk glib gmodule gtk iconv intl m

here are my WANTLIB lines (from the port I have previously submitted)

WANTLIB=                gmodule Xi X11 iconv intl m glib Xext gtk \
                        xmms pthread gthread gdk







And yes.. they have had trouble, but overall it does work well.

Thanks for your time

Edd

--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net

Here is the wantlib line from xmms-flac, which has been checked in and therefore approved. Similar would you not agree? I have decided to remove xmms in favour of LIB_DEPEND as it will compile directly against that. make newlib-depends check is happy with this. What is your concern (unless you just meant libxmms)? I have changed the naming convention on my local copy as requested and removed the hard coded version number. Reguarding CPU optimizations, the patch makes no CPU assumptions. The safest option. However I dodn't think people would approve of patching a configure script.

Hello,

Here is my revised xmms equalizer port (renamed xmms-equ).



I am sure if I had newer hardware than an Ultra 5 I would not see this.

Please test, and if seen to be good, commit.

Edd

Tested on sparc64 with a fresh snapshot. By default the sound is skippy, but works if you turn 'extra filtering' off in the preferences.

xmms-equ.tgz
Description: Binary data