Help recording on Audacity [SOLVED]

[adamw]

Hey, don't be embarrassed, you're not alone :). My current main system is an HTPC (Home Theatre PC) which also serves as an impromptu desktop, a bit of a jack of all trades. When I first built it I connected it direct to my TV (didn't have the money for a monitor). Couple of weeks ago I got around to buying a monitor. The nvidia drivers have lots of nice support for multiple displays, so I read through all the documentation, came up with an xorg.conf that should work fine, shut the system down, plugged the new monitor in and rebooted. I got weirdness.

 

I footled. I read every bit of documentation I could find, every example file. About two minutes into this messing I had a situation where the monitor had perfect output but nothing was appearing on the TV, where the second half of the desktop should be. I tweaked, I twiddled, I prodded, I pulled, I redid everything from scratch. Nothing.

 

It was at this point that I looked behind the machine and noticed I'd knocked out the s-video connector when plugging in the monitor.

 

D'oh.

 

I plugged it back in and rebooted. Bang, everything came up. I'd had the right configuration for hours...

[banjo]

I feel better now.

 

Thanks for the kind words.

 

Just as an update, I have been fooling around with

Audacity and figuring out how to use it. I have now

recorded a few very brief tracks from the microphone

and converted them into the following formats:

 

ogg

wav

mp3

 

In order to do the mp3, I downloaded lame in a tarball

and built it locally. That worked out fairly well.

 

Unfortunately, when I pointed audacity at the

local libmp3lame.so audacity simply crashed.

Hmmmm.

 

So, I used a CLI to do the deed, to wit:

 

lame test.wav test.mp3

 

and that seemed to work.

 

Whatever works! Being an old Unix hack for years,

I ain't afraid of the CLI......... I just have to steer clear

of that hardware stuff.... :woops:

 

I am still using the Aucacity 1.1.1. I downloaded an

rpm of 1.2.2 and tried to install it and it dropped me

directly into Dependency Hell, so I backed off.

 

 

Banjo

(_)=='=~

[adamw]

RPM Pointers For Mandrake Happiness:

 

use RPMs from the three main Mandrake sources - main, contrib and plf - WHENEVER POSSIBLE. Your first attempt to install any program should be:

 

urpmi <programname>

 

once you've set up correct mirrors for main, contrib and plf using the guide at http://easyurpmi.zarb.org/

 

If these sources do not contain a piece of software you need, or you REALLY REALLY REALLY REALLY NEED a newer version than they contain, build it from source following the instructions provided. ALWAYS install stuff built from source in /usr/local; never in /usr. Do not build a newer version from source unless you actually *need* something in that newer version.

 

Never, ever, for any reason, download a random RPM package from some other distro, or some other version of Mandrake, and try to install it.

 

Simple rules that will make things much easier :). You might want to try uninstalling that source-built version of lame and installing the one from plf instead. Or if you want to keep yours, adding this line:

 

/usr/local/lib

 

to /etc/ld.so.conf and then running 'ldconfig' might help.

[banjo]

Thanks for the pointers.

 

I built lame from source because I could not find a

package anywhere. Obviously I am not looking in the

right places.

 

I have never had anything but bad luck with urpmi unless

I was running it through the Control Center and the package

is on the original CD's. I suppose that I am misusing that

as well. But then, where is the document describing what

this is all about? I have found lots of tutorials crammed with

details, command line args etc., but nothing with an overview

of how it is supposed to work or what it is supposed to do.

What are, in fact, the rules of engagement?

 

It seems to be fairly well impossible to upgrade apps in

Linux because of the Dependency Hell issue. I have read

nightmare stories about people trying to upgrade Mozilla

and trashing their systems. I have been trying to upgrade

my Audacity to 1.2.2 and finding myself in a labarynth of

twisty passages with green snakes. It is very difficult to

tell which required package name full of alphabet soup

is going to be incompatible with something and render my

system useless.

 

So, I live with the old stuff.

 

I hate to think of upgrading Mandy just to get a newer

version of Audacity running.

 

I do not know what ld.so.conf or ldconfig do, but I will go

search for man pages to see if that will help.

 

Thanks again for the overview information.

It helps a lot.

 

Banjo

(_)=='=~

[adamw]

You weren't exactly using it wrong, no - you probably just didn't know there are more comprehensive official urpmi sources available online. Trying to use urpmi on a single package you downloaded from somewhere is pointless. that's not what it's meant for. Go to http://easyurpmi.zarb.org/ , read and follow the instructions, and then urpmi will be a whole lot more useful for you.

 

The whole 'dependency hell' thing is exactly the reason I suggest installing from source for anything that does not have a Mandrake package. Stuff you build from source will never replace something in the main system and it completely misses the RPM database so it can't screw that up. If you ensure everything built from source goes to /usr/local it is completely separated from the base Mandrake system; if the worst comes to the worst you simply rm -rf /usr/local and you're right back to a standard Mandrake setup. That's impossible when you start installing random RPMs. Additionally, since /usr/local is designated as a place for non-system files, the Mandrake tools will always ignore it; doing an upgrade install will simply leave it completely alone, so IT can't mess up the upgrade and the upgrade can't break IT.

 

I follow my own rules exactly and I keep the source to everything I build from source in my /home/adamw/source tree. That way I know exactly what I have installed from source and if an update to the basesystem upgrades something that makes a source-built program not work I simply rebuild and reinstall it. Painless and safe.

 

So follow my rules for your situation. You have a slightly old Audacity from the Mandrake package, so you followed rule 1. Great. Now - do you *really need* the new version or do you just figure 'it's a new version so I should have it'? This is bad thinking on Linux. Read the changelog and determine if there's something you actually need.

 

If you really need the new version here is what you DO NOT DO: go to the audacity home page, download an RPM that looks like it might work (a Fedora one, or even one that says it's for Mandrake; those types of packages will generally *install* and *work* ok, but they pollute your rpm database and can screw up updates. They're best avoided.)

 

Here is what you DO do: download the source tarball. Untar it into your home directory. READ THE DOCUMENTATION and follow its instructions. If it says it needs a certain thing to build - let's say it needs Bobbity - then what you will need is the Mandrake bobbity -devel package. Fire up rpmdrake and search for bobbity, or just use urpmq. You will see a package named something like:

 

libbobbity0-devel

 

install it. Always read documentation, it's there for a reason. Once you have installed all the -devel packages that the documentation indicates you need, do the build process. In most cases this is:

 

./configure

make

(become root)

make install

 

Very likely, the first few times you do this, you'll get errors caused by some other development packages not being installed. A lot of software doesn't bother to list the build dependencies it needs, or if it does list them, some are missed or skipped out. Don't panic. Look through the errors; try and find the *first* error message, all later ones are consequences of the first and can often be misleading (they often look much worse than the actual problem is). From the error message you can usually work out what -devel package is missing, go ahead and install it, and restart the build process.

 

Once you've done this a few times you'll start building up an installed base of many common -devel packages and it won't happen anywhere like as often.

 

99% of Linux software is well-behaved and installs into /usr/local by default. If you're very unlucky you MAY find something that's been really, really badly written to install itself into /usr. I always keep an eye on the output of the 'make install' stage to check this. If you find such a piece of software, again, DON'T PANIC. Immediately run make uninstall and check the documentation for instructions on how to install into /usr/local instead. Usually, the --prefix= parameter for the configure script is what you need to use, e.g.:

 

./configure --prefix=/usr/local

 

Some very safety-minded individuals do this every time they build anything. I'm too lazy :).

 

/usr/local/bin is in the default path, so once something is installed there, you're mostly ready to run it right away. Anything built from source will not appear on the Mandrake menu; add it with menudrake or just make yourself a launcher or something.

 

The only other thing - ld.so.conf specifies which directories the system looks in to load libraries. /usr/local/lib isn't listed there by default; source-built packages put their libraries here, so if you build a library from source, you need this line for the system to find it. ldconfig rebuilds the system's list of available libraries from the ld.so.conf file.

 

This all looks horribly long and complicated. It honestly isn't. I worked it all out mostly for myself, through trial and error, within a month of starting to use Linux. It's a very simple to use and reliable process which will keep your installation functioning perfectly and will make sure you never have any problems using *correct* packages and Mandrake updates. Just resist the temptation to use random packages. Resist! :)

[banjo]

Wow! Thanks!

 

That is exactly the information I was looking for.

 

I have placed it in my "linuxinfo" directory for future

reference.

 

Loading up urpmi with a bunch of web sources was

not practical for me in the past because I was on dialup

and I could retire before it got done doing what it

wants to do. However, just recently I switched over to

DSL, so now it might make more sense.

 

So, I built LAME from source.

 

When I built LAME it behaved very well and put itself

into /usr/local/bin and /usr/local/lib as you suggest.

 

My problem with Audacity 1.1.1 is that it crashes

with a Segmentation Fault when I attempt to point

it at the libmp3lame.so. From the CLI, lame works fine.

It is most certainly not worth a huge amount of time

to upgrade Audacity to fix this problem. I would

probably burn my CD's from .wav files anyway and

only translate to mp3 if I want to put something out

on the web. CLI is fine for that.

 

I am not one to chase the latest and greatest update,

which is why I am still running my Mandy 9.1. My old

Linux is a rock, and I like stability. I switched over to

Linux from Win98 a year and a half ago when I saw

WinXP coming like a runaway train full of SPAM. I do

not regret the decision, since day in and day out I

see my colleages being leveled by automatic Gatesian

XP upgrades and general system trashing. Ick!

 

I think that I might take on a source upgrade to

Audacity just as a challenge. As long as it does not

trash my installed Mandrake it would be interesting to

try it. We shall see.

 

Thanks again for the help.

 

Banjo

(_)=='=~

[adamw]

Nope, installing from source can't possibly break anything fundamental to the system. As I explained, that's the advantage of building from source :). If you screw up, just make uninstall, or remove everything audacity put in /usr/local/bin and /usr/local/lib manually. It's not like WIndows, where when you install something it hides bits of itself all over the system; building from source you can see exactly what goes where and if you remove it all, it's *gone*.