Topic: Taper's Linux HOWTO

[homer420]

I've put together a small HOWTO for you tapers interested in using Linux for transferring recordings, splitting tracks, and burning CD's (and DVD's):

http://homer.homelinux.net/taper-linux-howto.html

For the last 3+ years I've been using Linux exclusively as the operating system for my digital audio workstation. And over this time I've been able to find comparable {free} applications for performing the common tasks of a taper. This HOWTO is intended to provide an overview of these applications, and provide links to where they can be downloaded. It also provides an overview and pointers to some scripts that myself and others have written to make many of these tasks easier for us tapers.

This is my first attempt at writing a HOWTO so if you have any feedback or suggestions for improvement please send them my way (dmaley at nc dot rr dot com). Enjoy!

--
"That's it!  You people have stood in my way long enough.  I'm going to clown college!"
-Homer J Simpson

[hzgone]

didn't read through the whole thing since i don't have a linux box running.  Which is sitting in my garage with no power supply but a good refrence when i get it running again.  +T

[chase]

Cool 

I have been running linux exclusively for the past year or so, currently running ubuntu.  I have been slowly working on a website of my own that will hopefully serve as a one stop place to find info on how to get/install/use everything a normal taper/trader will need, on any platform, windows, mac, linux.

[pigiron]

Hell yea! We need more Linux presence around these parts.

I'll try out some of those scripts... tanks.

Now that 24 bit's coming more into play, you may want to add some more poop on that. I've found that AFsp has been carefully coded and does a one step 24/96 to 16/44.1 dither/resample (and more). Looks like the main web page is down, but the code's at ftp://ftp.tsp.ece.mcgill.ca/pub/AFsp/

I've also got a version of wavbreaker that I've hacked for 24 bits on ALSA.

Now we just need to get a group together to work on a good metaflac app 

[homer420]

Now that 24 bit's coming more into play, you may want to add some more poop on that. I've found that AFsp has been carefully coded and does a one step 24/96 to 16/44.1 dither/resample (and more). Looks like the main web page is down, but the code's at ftp://ftp.tsp.ece.mcgill.ca/pub/AFsp/

I've also got a version of wavbreaker that I've hacked for 24 bits on ALSA.

Indeed I need to update w/ some 24-bit related info.  Been on my to-do list for months, but don't have any 24-bit capable hardware and thus just needed a push to get it done ...

It should be fairly easy to add 24-bit recording to my drecord script since arecord supports this just fine.  But it doesn't appear sox is able to dither from 24 -> 16 bit so I'll have to look into other ways to do this from command line which I can incorporate into the script.

Audacity should be able to handle 24-bit recording and dithering to 16-bit just fine for those looking for a GUI interface.

I've also got a version of wavbreaker that I've hacked for 24 bits on ALSA.

Can you post or send me a patch for this?  I've been working w/ the wavbreaker author on a number of things and I'm also maintaining RPM's.  If it doesn't introduce any problems w/ the 16-bit stuff I'll get it added to my packages.

Cheers,
Dave

--
"To alcohol!  The cause of, and solution to, all of life's problems."
-Homer Simpson

[homer420]

I managed to track down the AFsp page:

http://www-mmsp.ece.mcgill.ca/Documents/Software/Packages/AFsp/AFsp.html

Looks like some interesting stuff.  I'll have to start looking into it's capabilities ...

[nic]

while this is a nice resource, unfortunately, it doesnt tackle the main problem with Linux recording...configuring the interface driver.

even on the ALSA page, many cards that are "supported" arent, at least the digital I/O portion of the interface isnt supported.
take the M-Audio PCI cards for example...sure, the Envy24 chip is supported, if you only use the analog RCA I/O. it's been the case for at least the last 6 years and that is IF you manage to get ALSA to load the driver in the first place (I've tried with 2.6.x kernels and I still cant get ALSA to load correctly...)

those of you who use Linux to transfer digital recordings, what interface are you using?

[it-goes-to-eleven]

I believe the M-Audio problem is because they won't release specs for their gear.  The UA-5 seems to work fine.

One big problem I have with linux audio is the lack of good dither. It would save me a lot of hassle if I could just 24/96>16/44 from a command line without ever visiting windows. Audio and Visio are the *only* things I use windows for.

Simple stuff, like swapping channels, is very tedious in Audacity (I asked on the audacity mailing list and nobody had an easy method).  Improving audacity all comes down to more 'man years' of work required.

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.  Ecasound, as good as it is, does not seem to be bit accurate.  Kai does an amazing job of supporting ecasound but doesn't seem to 'get' the need for bit accuracy and that most hardware is 24 bits and not 32.

I'm sure that Linux audio will continue to improve. I was doing 24 bit laptop recording with linux for a while and it worked quite well (and I think ecasound was quietly converting the 24 bit data from my Minime to 32 bits and then back to 24 when writing it out...).  Ultimately, I decided I wanted to make recordings more than I wanted to hack Linux sound and fight battles over bit correctness, etc.  Sometimes you just want to drive the car, not build it 

[Brian Skalinder]

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.

During the editing process, you mean?  Many Windows audio tools do the same, or are configurable to operate in the 32-bit realm during processing.

Help me understand why using 32-bit math when editing a 24-bit file would create more noise?  I suppose on one hand, you're using more precise math during the editing.  But on the other, you must then dither back to 24-bit.  So are you suggesting the extra precision available from 32-bit processing is negated by having to dither back down to 24-bit?  Genuinely curious...

[mfisch]

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.

During the editing process, you mean?  Many Windows audio tools do the same, or are configurable to operate in the 32-bit realm during processing.

Help me understand why using 32-bit math when editing a 24-bit file would create more noise?  I suppose on one hand, you're using more precise math during the editing.  But on the other, you must then dither back to 24-bit.  So are you suggesting the extra precision available from 32-bit processing is negated by having to dither back down to 24-bit?  Genuinely curious...

Indeed that is most unintuitive. I would think a 32-bit workspace would make the processing _more_ bit accurate. Of course, I'm not sure you will ever be bit accurate with digital audio, there are some pieces of math that simply don't fit into a 32-bit float either .... course -- if its good enough for hollywood its good enough for us right? I think the approaches various processors take in the digital realm will have a much greater effect on the sound than the bitdepth they are working at however.

ps, is he talking about just recording?

24 --> 32 --> 24?
As in:
101010101010101010101010 --> 10101010101010101010101000000000 --> 101010101010101010101010 .. looks bit accurate to me.

[ethan]

+T

[homer420]

while this is a nice resource, unfortunately, it doesnt tackle the main problem with Linux recording...configuring the interface driver.

even on the ALSA page, many cards that are "supported" arent, at least the digital I/O portion of the interface isnt supported.
take the M-Audio PCI cards for example...sure, the Envy24 chip is supported, if you only use the analog RCA I/O. it's been the case for at least the last 6 years and that is IF you manage to get ALSA to load the driver in the first place (I've tried with 2.6.x kernels and I still cant get ALSA to load correctly...)

those of you who use Linux to transfer digital recordings, what interface are you using?

I use a RME Digi96/8 PST card.  The default mixer app for Gnome (gnome-volume-control) doesn't properly support this card.  However there's a great app available called rmedigicontrol, included in alsa-tools, which is specifically designed for use w/ RME cards.  It's extremely difficult for a generic mixer app to correctly support all the different soundcards out there, and the folks who do the majority of the work on these mixers focus on making them work well w/ the most common soundcards around (ie. low-end).  Fortunately there are a number of alternative apps out there which are specifically designed for the higher-end cards, and in general these will allow you to make use of the full feature set of your soundcard.

In the case of your example, M-Audio (Envy24 chip), the ALSA driver (ice1712) does indeed support the digital interface.  And alsa-tools also contains a mixer app specific to the envy24 chipset called envy24control.  I'd suggest giving this a try to see if it does the trick for you.

As for getting the alsa drivers to load/work have you tried any of the recent distro releases based on a 2.6 kernel?  I would highly suggest giving Fedora Core 4 a try (sorry I'm biased towards Red Hat - any recent 2.6 based distro should be fine).  It's taken a little time for the linux vendors to get all their installer and config tools working properly w/ the ALSA stuff, but the Fedora folks seem to have all the major kinks worked out now and thus the drivers themselves should "just work" after a fresh install.

Note: The alsa-tools package is not in the base Fedora Core distro however it is included in Fedora Extras.  So you'll need to install it using yum after doing the OS install.

[Lil Kim Jong-Il]

Nice to see you here homer.  I saw your page when you posted to oade a long time back and used some of that when I still worked in 16-bit.

Does wavebreaker handle 24-bit files yet?

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.

During the editing process, you mean?  Many Windows audio tools do the same, or are configurable to operate in the 32-bit realm during processing.

Help me understand why using 32-bit math when editing a 24-bit file would create more noise?  I suppose on one hand, you're using more precise math during the editing.  But on the other, you must then dither back to 24-bit.  So are you suggesting the extra precision available from 32-bit processing is negated by having to dither back down to 24-bit?  Genuinely curious...

Translating between int and float creates noise because rounding errors are introduced during the storage format conversion.  Try reading a 2G file into audacity and then writing it out to another file name.   You will rarely get an exact duplicate.

I have yet to figure out how to get audacity to stay in 24-bit int mode even though there is a setting that seems to be intended for that purpose.

[homer420]

I believe the M-Audio problem is because they won't release specs for their gear.  The UA-5 seems to work fine.

One big problem I have with linux audio is the lack of good dither. It would save me a lot of hassle if I could just 24/96>16/44 from a command line without ever visiting windows. Audio and Visio are the *only* things I use windows for.

Simple stuff, like swapping channels, is very tedious in Audacity (I asked on the audacity mailing list and nobody had an easy method).  Improving audacity all comes down to more 'man years' of work required.

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.  Ecasound, as good as it is, does not seem to be bit accurate.  Kai does an amazing job of supporting ecasound but doesn't seem to 'get' the need for bit accuracy and that most hardware is 24 bits and not 32.

I'm sure that Linux audio will continue to improve. I was doing 24 bit laptop recording with linux for a while and it worked quite well (and I think ecasound was quietly converting the 24 bit data from my Minime to 32 bits and then back to 24 when writing it out...).  Ultimately, I decided I wanted to make recordings more than I wanted to hack Linux sound and fight battles over bit correctness, etc.  Sometimes you just want to drive the car, not build it 

From command line you should be able to just use arecord (or my drecord script once I add the support) to get a true 24-bit signal written to disk w/out any sort of conversions.  However I believe Brian Skalinder is correct that most audio editors (Windoze, Mac, etc) will convert to 32-bit for doing the actual signal processing.

Audacity definitely has some shortcomings.  It's come a long way since I first started playing with it, but certainly still has a ways to go if it's to compare with the proprietary apps available for Windoze or Mac.  Might be a bit of overkill for the typical tapers needs but you may want to also check out Ardour (ardour.org).

[homer420]

Nice to see you here homer.  I saw your page when you posted to oade a long time back and used some of that when I still worked in 16-bit.

Does wavebreaker handle 24-bit files yet?

Not officially however pigiron noted earlier in the thread that he's hacked 24-bit ALSA support into wavbreaker.  And thus I've requested he send me a patch so I can add it to my packages an begin playing around w/ it.  If all seems good I'll work w/ the author to get it integrated into future versions.

pigiron - feel free to just send me the source for your hacked version and I'll generate the patch ...