Gopher said:
Many people around here fiddle around with tubes, capacitors, inductors, resistors asf since years.
There are even more people around still trying to mod
outdated CD-players, (pre- )amps, speakers.
Why don't you post a general post, telling the whole diy-audio
community to rather listen to music instead of fiddling around
with above.
There are also quite some people around here accepting the PC
as a black box MS-Windows based system and accepting it the way how it works. These people usually enjoy listening to MP3s over PC-speakers. Fair enough.
But there is also a very small community, trying to make an audiophile source out of the PC. This topic hasn't been
discussed very much for now. I strongly believe it is worth
discussing it.
As you might have seen, there are a lot of people around here, confirming that Linux is the OS, one should go for when it comes to Audio and Multimedia applications.
When it comes to postprocessing audio-data the platform bears a huge potential.
There are quite some people around, who use e.g. Brutefir etc.
to do the filtering/crossover/convolution already in the digital domain. These type off applications do need maximum
performance to avoid sound deterioration. That's what I am after.
Don't forget most of the audio and mulimedia Linux distros are highly tweaked realtime setups.
(Unfortunaletly these don't run on all PCs or makeing tweaking almost impossible.)
Coming up with these (your) kind of BOLD statements is a 10s job. Coming up with real constructive input to develop the story is a different story.
Enjoy your music and avoid reading these kind of threads, what just keeps you away from listening to music and keeps me away form getting my PC/Linux up2speed.
Constructive feedback or contribution is apprectiated and always welcome.
Cheers
Agree. I worked 8 to 9 years with M$ products, now 1 year Linux. All those m$ years wasted to keep the pc running: install firewall, updates, service packs, virusscans, virusupdates, spyware checkups, register cleaning, defragmenting HD's, blue screens, missing ntldr's, new installs etc. On Linux the pc works for me instead of the other way round.
Linux has some faults too, but compared to win only minor things.
Re: about the push 
Hi Rony.
Interesting. Slowly but slowly I see the potential the way you
fiddling around with the data-stream.
1. Do you have an idea if the 32bits are processed as floats ?
2. How can I possibly apply replay gain to the data stream, Is there a Sox feature, gain integrator?
Background: How2 establish a high quality volume control in the digital domain.
Cheers
ronybc said:
Hi Rony.
Interesting. Slowly but slowly I see the potential the way you
fiddling around with the data-stream.
1. Do you have an idea if the 32bits are processed as floats ?
2. How can I possibly apply replay gain to the data stream, Is there a Sox feature, gain integrator?
Background: How2 establish a high quality volume control in the digital domain.
Cheers
Rony,
Just noticed that you seem to be resampling to 48khz in the pc to try and avoid the affects of the soundcard resampling. I think in actual fact that soundcards that do resample do this to all material, even if the stream is 48khz in the first place. Therefore this may not have much of an effect except to add a further insatnce of resampling where there need only be one.
Soundcheck, I have now done a hd install of puppy and will patch for real time premption. Some level of preemption is available in the kernel as standard, but not full on - as you quite correctly pointed out previously. I have been advised to apply the Con Kovalis patch as well to further the effect. Definitely we are still to really determine, even in theory, if these patches will improve audio quality, but it does seem like a good idea to give audio applications priority over other systems and assign as much cpu time as possible. It should also notably improve the performance of my low spec system which at times gets sluggish at the moment.
Is it maybe possible to route audio using jack from xmms through ardour and control volume through it? The ardour engine is 32bit floating point and if it can be determined that volume control is done within the engine this may give you the performance you are lookimg for?
Just noticed that you seem to be resampling to 48khz in the pc to try and avoid the affects of the soundcard resampling. I think in actual fact that soundcards that do resample do this to all material, even if the stream is 48khz in the first place. Therefore this may not have much of an effect except to add a further insatnce of resampling where there need only be one.
Soundcheck, I have now done a hd install of puppy and will patch for real time premption. Some level of preemption is available in the kernel as standard, but not full on - as you quite correctly pointed out previously. I have been advised to apply the Con Kovalis patch as well to further the effect. Definitely we are still to really determine, even in theory, if these patches will improve audio quality, but it does seem like a good idea to give audio applications priority over other systems and assign as much cpu time as possible. It should also notably improve the performance of my low spec system which at times gets sluggish at the moment.
Is it maybe possible to route audio using jack from xmms through ardour and control volume through it? The ardour engine is 32bit floating point and if it can be determined that volume control is done within the engine this may give you the performance you are lookimg for?
Hi Ross.
The RT story goes even further. I read somewhere that a combination of
Kovalis and Molnar would be even better.
As an "insane push to the limits" you should have a look at realtime distros,
such as RTLinux.
The overall key issue behind above is to avoid process lock-ups, which can easily happen in a realtime environment, since all tasks are still handled sequential.
As long as you just run your audio application and don't touch your system while playing back everything should be OK.
For the ones without RT-patched Kernels, you could try the "nice" (command,
which can lift-up your task priority.
Start your application from command line:
$sudo nice -n -10 xmms
The range goes from -20 to +20, where -20 is the highest priority (but should be avoided ). -10 should work quite well!
The problem: You won't speed up ALSA and the soundcard driver.
When it comes to volume control, using ALSA/JACK/ARDOUR/XMMS might work.
Though I doubt that the sound improves by chaining up more and more applications. The other problem. Many of the applications running DSPs using
/dev/dsp as device. AFAIK this is only supported by OSS ( the old sound system under Unix). In the end you might run an OSS emulation under ALSA. This is
getting too complex.
There is still a lot to play around with!
Cheers
The RT story goes even further. I read somewhere that a combination of
Kovalis and Molnar would be even better.
As an "insane push to the limits" you should have a look at realtime distros,
such as RTLinux.
The overall key issue behind above is to avoid process lock-ups, which can easily happen in a realtime environment, since all tasks are still handled sequential.
As long as you just run your audio application and don't touch your system while playing back everything should be OK.
For the ones without RT-patched Kernels, you could try the "nice" (command,
which can lift-up your task priority.
Start your application from command line:
$sudo nice -n -10 xmms
The range goes from -20 to +20, where -20 is the highest priority (but should be avoided ). -10 should work quite well!
The problem: You won't speed up ALSA and the soundcard driver.
When it comes to volume control, using ALSA/JACK/ARDOUR/XMMS might work.
Though I doubt that the sound improves by chaining up more and more applications. The other problem. Many of the applications running DSPs using
/dev/dsp as device. AFAIK this is only supported by OSS ( the old sound system under Unix). In the end you might run an OSS emulation under ALSA. This is
getting too complex.
There is still a lot to play around with!
Cheers
Hi folks.
Today I digged out the "Ecasound" sound-processing tool.
It is quite easy to implement. I spent half a day to analyse it.
The tool just comes with a commandline interface.
The missing GUI doesn't really mean anything when it comes to the actual performance of this little tool. ( I think bulky GUIs are just wasting processing time anyhow. What I realized, the more you get into the Linux-world, the more you appreciate real fast command line operations. )
The application is highly optimized for realtime operation and manages all data processing at 32bit/float. I read that even Ardour is not able
to deliver the numerous features provided by Ecasound.
After some listening sessions today, I just can state here that this tool beats easily my favorite alsa/xmms setup. Again a step forward, Wow!
My new reference as "single track player".
(I need to write a script, to be able to playback multiple files from /tmp --
Any hacker around who can give some hints?)
For the ones interested in trying ecasound:
ecasound can be found in the Ubuntu repositories. It is easy to install with synaptics. Just search for it. Ecasound seems also to be well maintained.
Below the command line options, which gave me best results for now:
$ ecasound -r -c -b 1 -f:16,2,48000 -i:test.wav -ea:50 -o:alsa,hw:0,0
That's how I process my 48kHz base-material. Without using the -f option it processes automatically 16/44,1 material.
-r stands for realtime
-c stands for interactive mode. By typing start or stop you can manage the playback at the interactive mode new prompt.
-b buffer size in samples. I can run it with 1 sample buffersize. You might try larger buffers first (e.g. 256)
-ea:50 configures the volume-level at 50 %
-o you need to fill in the alsa device id. It might be hw:1,0 instead of 0,0
Once installed with synaptics you should do following to prepare ecasound for realtime-operation
cd /usr/bin
sudo chown root.audio ecasound
sudo chmod 4750 ecasound
Make sure that you got the "audio" user group configured as the "realtime" group in /etc/security/limits.conf (the last 3 lines should look like below)
@audio - rtprio 99
@audio - memlock 250000
@audio - nice -10
So far so good. Let me know what you experienced!
Cheers
Today I digged out the "Ecasound" sound-processing tool.
It is quite easy to implement. I spent half a day to analyse it.
The tool just comes with a commandline interface.
The missing GUI doesn't really mean anything when it comes to the actual performance of this little tool. ( I think bulky GUIs are just wasting processing time anyhow. What I realized, the more you get into the Linux-world, the more you appreciate real fast command line operations.
)The application is highly optimized for realtime operation and manages all data processing at 32bit/float. I read that even Ardour is not able
to deliver the numerous features provided by Ecasound.
After some listening sessions today, I just can state here that this tool beats easily my favorite alsa/xmms setup. Again a step forward, Wow!
My new reference as "single track player".
(I need to write a script, to be able to playback multiple files from /tmp --
Any hacker around who can give some hints?)
For the ones interested in trying ecasound:
ecasound can be found in the Ubuntu repositories. It is easy to install with synaptics. Just search for it. Ecasound seems also to be well maintained.
Below the command line options, which gave me best results for now:
$ ecasound -r -c -b 1 -f:16,2,48000 -i:test.wav -ea:50 -o:alsa,hw:0,0
That's how I process my 48kHz base-material. Without using the -f option it processes automatically 16/44,1 material.
-r stands for realtime
-c stands for interactive mode. By typing start or stop you can manage the playback at the interactive mode new prompt.
-b buffer size in samples. I can run it with 1 sample buffersize. You might try larger buffers first (e.g. 256)
-ea:50 configures the volume-level at 50 %
-o you need to fill in the alsa device id. It might be hw:1,0 instead of 0,0
Once installed with synaptics you should do following to prepare ecasound for realtime-operation
cd /usr/bin
sudo chown root.audio ecasound
sudo chmod 4750 ecasound
Make sure that you got the "audio" user group configured as the "realtime" group in /etc/security/limits.conf (the last 3 lines should look like below)
@audio - rtprio 99
@audio - memlock 250000
@audio - nice -10
So far so good. Let me know what you experienced!
Cheers
Hi soundcheck,
did you tried this one: Vector Linux ?
They now say it's the fastest distro.
I gave it a try some time ago, and it's very fast, especially on not so fast pc's. In a week or so I'll try xubuntu too (just to compare them), and start playing with brutefir, jack, and drc, ..
I am now using dynebolic but I don't have access to their web-site. Don't know why... I like the distro, but I'm yet on learning linux to properly evaluate it...
Good luck !
did you tried this one: Vector Linux ?
They now say it's the fastest distro.
I gave it a try some time ago, and it's very fast, especially on not so fast pc's. In a week or so I'll try xubuntu too (just to compare them), and start playing with brutefir, jack, and drc, ..
I am now using dynebolic but I don't have access to their web-site. Don't know why... I like the distro, but I'm yet on learning linux to properly evaluate it...
Good luck !
SunRa said:
NO. And I won't use it.
BTW: Is there a definition or Benchmark about "Fast Distros", would be interesting to see how and what they measure?
BTW: Xubuntu also uses XFCE, the same as Vector Linux.
Realtime patched, Xubunto will give you quite a good performance.
Beside that, you'll find all support you need for Ubuntu. I doubt that this will be the case with Vector-linux. You experienced it by yourself (me too) with Dyne:Bolic. As soon as you get in trouble with these small distros, you can forget about them.
The Ubuntu repositories are well maintained, what makes live a lot easier to find and install up2date applications.
Cheers
Offline SRC with Shibatch
Hi all.
First of all I just wanted to let you know that I am still very happy with ecasound. Whow! Anybody tried it yet?
However, I went further down the road, scanning for more Linux
related goodies.
To repeat the issue for the ones not following the thread, I do offline SRC with the "Voxengo R8brain Pro" to 48kHz, what is giving me much less Jitter compared to 44,1kHz base material or
48kHz realtime upsampling.
(Unfortunately nobody really confirmed my positive findings on different systems yet. )
However.
One of the links posted by Rony refered to a page,
which was saying and proving that Shibatch SSRC was
mainly leading all categories.
Decision taken: Go for the best!
I had a look at http://shibatch.sourceforge.net/ and
realized that there is sourcecode for the SSRC of Shibatch available - yeah - this piece of software is opensource code.
I downloaded it, unpacked it, and ran the make, which resulted
in a little binary called ssrc. I changed permissions of the file and:
Ready to rumble!
I converted my files like this
$ssrc --rate 48000 --bits 16 44source.wav 48target.wav
(takes less than 60s for a 5min track. I wonder how you can do that in realtime as a plugin to an application without catching high latencies, which in turn most probably degrades your sound again due to poor buffer handling?)
and heated up my system.
BTW: Inspired by Ronys SOX script, I wrote a little script to run ecasound a bit more user-friendly. (I might post it later, if anybody is interested!)
I started it and Here we go! I never expected it, but the result was obvious and clearly audible very soon.
After 30 minutes of further listening to a couple of reference files I'd say SSRC does a great, great job -- at no cost!
My first impression is telling me distortions are again lowered!
Anything wrong with it? I'll give it some more hours.
Conclusion:
The resampling algorithms do differ. And this is audible - even if SRC is done offline.
Folks - this doesn't cost you anything and it's done in 30 minutes- Give it a try!
Highly recommended!
Cheers
Hi all.
First of all I just wanted to let you know that I am still very happy with ecasound. Whow!
Anybody tried it yet?However, I went further down the road, scanning for more Linux
related goodies.
To repeat the issue for the ones not following the thread, I do offline SRC with the "Voxengo R8brain Pro" to 48kHz, what is giving me much less Jitter compared to 44,1kHz base material or
48kHz realtime upsampling.
(Unfortunately nobody really confirmed my positive findings on different systems yet.
) However.
One of the links posted by Rony refered to a page,
which was saying and proving that Shibatch SSRC was
mainly leading all categories.
Decision taken: Go for the best!
I had a look at http://shibatch.sourceforge.net/ and
realized that there is sourcecode for the SSRC of Shibatch available - yeah - this piece of software is opensource code.
I downloaded it, unpacked it, and ran the make, which resulted
in a little binary called ssrc. I changed permissions of the file and:
Ready to rumble!
I converted my files like this
$ssrc --rate 48000 --bits 16 44source.wav 48target.wav
(takes less than 60s for a 5min track. I wonder how you can do that in realtime as a plugin to an application without catching high latencies, which in turn most probably degrades your sound again due to poor buffer handling?)
and heated up my system.
BTW: Inspired by Ronys SOX script, I wrote a little script to run ecasound a bit more user-friendly. (I might post it later, if anybody is interested!)
I started it and Here we go!
I never expected it, but the result was obvious and clearly audible very soon. After 30 minutes of further listening to a couple of reference files I'd say SSRC does a great, great job -- at no cost!
My first impression is telling me distortions are again lowered!
Anything wrong with it? I'll give it some more hours.
Conclusion:
The resampling algorithms do differ. And this is audible - even if SRC is done offline.
Folks - this doesn't cost you anything and it's done in 30 minutes- Give it a try!
Highly recommended!
Cheers
I made a dual boot of an old Compaq E500 laptop (900Mhz Coppermine, 20G hd) which is a nice silent running one for music server. The laptop was a give-away from my old boss, in USB bus the plastic & pins where broken, but managed to repair it. Unfortunately the laptop has only one USB.
Installed Win 2k on 2G fat32 and Kubuntu on 15G ext3 (win for kids-games) Have also some 2 G fat32 left which both OS's can use, and 500mb swap. Partitioning managed very smooth with Gparted.
Played around with the very gadget-like Kubuntu, i am impressed! But the laptop needs more ram with the very graphical Kubuntu, now only 128mb. AmaroK played some tracks allready from hd.
How can i get music digital out on USB? Or is this working automatic?
I am searching things out to build USB to I2S converter with PCM2706.
Installed Win 2k on 2G fat32 and Kubuntu on 15G ext3 (win for kids-games) Have also some 2 G fat32 left which both OS's can use, and 500mb swap. Partitioning managed very smooth with Gparted.
Played around with the very gadget-like Kubuntu, i am impressed! But the laptop needs more ram with the very graphical Kubuntu, now only 128mb. AmaroK played some tracks allready from hd.
How can i get music digital out on USB? Or is this working automatic?
I am searching things out to build USB to I2S converter with PCM2706.
bluemartini said:
Hi there.
Yeah - Actually I am enyoing the sound for quite some time now. I do have the feeling that I can't get it better on the software side. - Though You never know!
However, I am still trying to squeeze more out of it. I also tried to improve ergonomics on my command-line player script.
I think I mentioned it before, I am running my volume control (32bit DSP) with eacsound, which I use as a player.
I introduced a kind of "Best-Volume-Flag" to my wrapper- script, which I apply to each of the directories (CDs) .
After listening to quite some CDs, I realized that there is only a small volume range for each of the CDs, where the sound sounds most realistic and right.
I am saving now this, to me, best sounding particular best-volume level by introducing and saving a "flag" for each of the CDs.
This flag pops up as default/best volume flag, next time I start to play the "CD"
(or better directory).
I also started structuring my file-names. I was really annoyed, being tight to
mp3-playlists and empty track,artist, .... databases when running the standard players.
What I did, I structured all my file-names that way, that I can
run a small awk script, as part of my player-script, to extract and display tracknumber, title, artist asf from the file name. That works really fine.
I also played around with running ecasound from single-user runlevel without
X being started up. I like that mode very much. You just run a character based screen. I am reducing resource utilisation to a minium!
Off topic - more related to PC music in general:
I also introduced a network HDD (WD-Netcenter 500GB). For (audio) backup-purposes and as shared network drive for documents. It works quite well for these purposes. For playing back tracks, which I transfer to the RAMDISK on the local machine, a 100Mbit LAN is just too slow.
Here I am looking forward to a reasonable priced gigabit LAN solution in the future.
I also just ordered an optical USB extension from Opticis. I hope that the galvanic
isolation from the PC will improve the sound on my external DAC. There is a slight
chance that I catch more jitter due to the optical conversion. I'll see.
Roadmap:
I got a kind of diskless & fanless Linux audio network client in mind, which is just booting and streaming from a home network.
These shouldn't be too expensive as far as I've seen. However, here I am back to the gigabitlan-problem. I'd also need a galvanic isolation from the home-network.
An optical lan might be a potenial solution. I digged out a 90ft 100Mbit optical LAN solution at around 200$, coming with tools to cut the fibre into the right length.
I also looked already into brutefir, to build a subwoofer crossover. It is not too difficult. First I'll do some tests on my system to see if the additional latency will negatively impact my sound. If that's not the case, I'd just need a 2nd DAC to go ahead.
RTLinux a "real" realtime system would be another idea. But here I would have to get myself into driver development. !?! Perhaps at a later stage.
All this is not done in a day. These will be some nice projects for this year.
I realized - The more I get into it, the more I have to improve my programming and UNIX skills, that'll take some time. It's a lot of (DIY) fun though.
Cheers SC
tubee said:
You need to activate the ALSA USB sound driver.
Edit /etc/modules: enter: snd-usb-audio
at the bottom and save it.
reboot.
Connect your DAC before you boot. And don't disconnect it while your system
is still up'n running.
You'll find a device in your player config dialog, which is called hw:1,0 which is usually the 2nd soundcard (USB-DAC) of the system. Select it.
It should work right away. If not try hw:0,0
tubee said:
There are actually many of them around.
DDDAC the USB2I2S module with Tent clock I'd recommend.
or have look at Empirical Audio for off the shelve produts.
There are also some asian products around.
Make sure to take a precision clock for the 270x.
I am runing the DDDAC by myself.
Cheers SC
Part 1: performance & tuning of linux
It's odd for me to not lurk, but I work more with servers than audio and can actually make productive comments here.
One of the biggest things about linux (unix in general) is the ability to heavily customize a system beyond many of the other operating systems. This is great for real time DIY stuff mentioned here. One key thing to point out before I start lecturing too much... You can customize linux until your fingers bleed. Some are more worth it than others. Unix as a whole is monsterous. Having source code access for linux just makes it so much more. Focus on the big things that matter and try not to get too caught up in the nitty-gritty. There have been many wars needlessly fought over the mundane.
This has been touched on, but I'll add a little more: Window Managers. These run on top of the X11 windowing system. Most people know of Gnome and KDE. These are the fattest and intended for end user desktop applications. What many don't realize is that you can have these installed, use their libraries, and be using another window manager that is much lighter still running gnome/kde programs. Alternatives include blackbox, twm, icewm, fluxbox, fvwm, afterstep, tinywm, window maker, and many others. Each has certain advantages and disadvantages depending on what you're doing and why.
This will blow the brains of the Micro$oft users, but you don't even need windowing running on the box to run windowed applications as X11 is fully network capable and can be redirected easily through ssh. I do this often for the coloc servers. VNC Server can also be set up in its own virtual environment that's totally separate from the hardware console (good if you don't have working console display drivers but do have a working network).
Another windoze mind blower: Different logins can have totally different desktops configured and running (and if you use the vnc server, they can be multiple simultaneous...and even terminal servers). I've even had real desktop as gnome and vncserver for the same user as wmaker running at the same time. Users of true multi-user systems shouldn't find this shocking. I often use window maker for small X11 (inside vncserver). To start it automatically, cd into the user's home directory and type "echo "exec wmaker" > .xinitrc". There are other ways of chaning, but that's quick and easy for window maker. Read the docs of the other window managers for their start commands.
Run Levels. These are often misunderstood by the non-unix aware. Run levels are nothing more than configuration slots that either launch or kill server programs of your own choosing. Levels 0 through 6 are commonly defined. 0 is shutdown, 6 is reboot (most of the unix flavors at least). Run level 1 (mentioned in earlier post) is defined special as "single user" and intended for deep system maintenance shutting all the peripheral stuff off so it won't be mess up by something (like a heavy upgrade...yes, I've done this and gone back to run level 3 without even having to reboot before). Run level 3 is normal text console mode; run level 5 is normal graphical login mode (most unix flavors). 2 and 4 seem up for grabs. I normally make 2 a stripped down version of 3 for time critical applications.
Run level programs are launched from the /etc/rc#.d/ (debian) or /etc/init.d/rc#.d/ (redhat/fedorka) directories (where # is the run level number in the directory name). For the beginner, load up X11/Gnome or KDE and look for the graphical run level editor to shut off the excess programs and reclaim a lot of ram. For the more experienced, check out the man pages for update-rc.d (debian) or chkconfig (red hat/fedorka) for the geek way.
In my run level 2, I normally shut down all the cron type programs and atd. These schedulers run when least expected and can really peg the processor doing mostly worthless tasks. When playing audio/video back under linux, I can usually tell when these are running as the system starts choking for a few minutes.
Other fluff programs for an audio class server: samba (unless you are sharing OUT from that box), apache (unless you have a web interface), ftp, inetd, database servers, NFS server, mail servers, print servers, and isdn services. I'm not sure why all these automatically activate when installed, but they often do.
BE CAREFUL when just shutting things off as a few of the more misc programs are needed by the OS to run and may cause trouble if suddenly missing. If you're unsure, look up the man page for the program and try turning things off ONE at a time then verifying your programs still run as expected.
Oh yeah, default run level is defined in /etc/inittab usually at the top with the line that starts with "id:". When the system boots, that line tells what run level to start in. If you want to change run levels while the system is up and going, type "init 2" for run level 2 (replace 2 with the desired run level).
Doing all this so far (and only running text console mode), you can get your total system RAM usage down to less than 20megs. (use the command "free -m" to see usage)
Here's another tip that will blow many minds: Get more RAM and just turn off swap ENTIRELY. Swap is pathetically slow and always will be. Swap is not needed for normal system operation. Swap is over flow catch. Swap was never intended to be a RAM replacement like some other OS's think....cough...gasp...micro$oft...hurl...splat
Command: "swapoff -a". To get it back on (as defined swap partitions in /etc/fstab) type "swapon -a".
Oh yeah, you can do this while the system is running (no reboots required). If you turn off swap, just make sure you have enough RAM to catch whatever was on disk.
With the operating system not swapping out to disk, the system behaves SO MUCH BETTER and much more responsive. This is a key element to a real time player.
I've even done this in windoze (yes it is possible)...and I'm amazed at my friends telling me that my dual 450 running XP is more snappy than their multi-ghz machines.
Before I forget (again), if you really want snappy, put your OS on a fast SCSI drive. It makes a difference in linux and a huge difference in windoze. I typically still use braindead IDE disks for large storage, though.
Kernel Recompiling. This can often be a hotly debated subject. In reality there are only a handfull of things you need to do to get the most out of your system. I usually compile core system drivers in as static/monolithic. I've had better results and stability that way. For here, keep audio drivers as modules. There are way too many drivers for audio cards and some seem to need parameters passed when they load (like my laptops). Turn off drivers you don't need or use. Leaving those as modules is ok if you want a generic type kernel, but they do take up some disk and slight memory table space.
I've also noted that some drivers will break the compile (when they shouldn't). Read carefully and disable those drivers. There will usually be a key word or something close by the error message for a clue.
Make sure the kernel is compiled specifically for the processor you are using. As mentioned in earlier posts, there are some real time options you can experiment with.
If you are new to all this, read the tldp.org howto's for this CAREFULLY. Giving specific instructions for kernel recompile is way too long and getting a bit off topic. Just realize that you WILL SPEND SOME TIME doing it over and over and over and over again testing variations. Don't be frustrated. I've compiled hundreds upon hundreds myself. The cleanest code is usually from kernel.org. Distributions tend to pre-patch their own source code and this can lead to abnormalities. While it is fine to use the distribution's code, most prefer the "pristine" source. Don't forget to tell your boot loader you have a new kernel after you compile and install it.
Recompile certain core packages. The libraries and programs you use heavily will slightly benefit from being recompiled to your current processor. Under debian I've just download the source and recompiled straight (super geek way). There is a recompile option for dpkg files, but I haven't done it yet. Under redhat/fedorka, look at the man page for "rpmbuild". After the package successfully recompiles, "reinstall" it over the existing.
Often the original (unpackaged) source code is more current, may be faster, and may have new features that are desirable. If you are new to compiling, stick to the package method above as that is usually more tested. Compiling a program from source isn't necessarily hard, but it can be overwhealming if you aren't aware of all the options. Start simple first.
....go to part 2
It's odd for me to not lurk, but I work more with servers than audio and can actually make productive comments here.
One of the biggest things about linux (unix in general) is the ability to heavily customize a system beyond many of the other operating systems. This is great for real time DIY stuff mentioned here. One key thing to point out before I start lecturing too much... You can customize linux until your fingers bleed. Some are more worth it than others. Unix as a whole is monsterous. Having source code access for linux just makes it so much more. Focus on the big things that matter and try not to get too caught up in the nitty-gritty. There have been many wars needlessly fought over the mundane.
This has been touched on, but I'll add a little more: Window Managers. These run on top of the X11 windowing system. Most people know of Gnome and KDE. These are the fattest and intended for end user desktop applications. What many don't realize is that you can have these installed, use their libraries, and be using another window manager that is much lighter still running gnome/kde programs. Alternatives include blackbox, twm, icewm, fluxbox, fvwm, afterstep, tinywm, window maker, and many others. Each has certain advantages and disadvantages depending on what you're doing and why.
This will blow the brains of the Micro$oft users, but you don't even need windowing running on the box to run windowed applications as X11 is fully network capable and can be redirected easily through ssh. I do this often for the coloc servers. VNC Server can also be set up in its own virtual environment that's totally separate from the hardware console (good if you don't have working console display drivers but do have a working network).
Another windoze mind blower: Different logins can have totally different desktops configured and running (and if you use the vnc server, they can be multiple simultaneous...and even terminal servers). I've even had real desktop as gnome and vncserver for the same user as wmaker running at the same time.
Users of true multi-user systems shouldn't find this shocking. I often use window maker for small X11 (inside vncserver). To start it automatically, cd into the user's home directory and type "echo "exec wmaker" > .xinitrc". There are other ways of chaning, but that's quick and easy for window maker. Read the docs of the other window managers for their start commands.Run Levels. These are often misunderstood by the non-unix aware. Run levels are nothing more than configuration slots that either launch or kill server programs of your own choosing. Levels 0 through 6 are commonly defined. 0 is shutdown, 6 is reboot (most of the unix flavors at least). Run level 1 (mentioned in earlier post) is defined special as "single user" and intended for deep system maintenance shutting all the peripheral stuff off so it won't be mess up by something (like a heavy upgrade...yes, I've done this and gone back to run level 3 without even having to reboot before). Run level 3 is normal text console mode; run level 5 is normal graphical login mode (most unix flavors). 2 and 4 seem up for grabs. I normally make 2 a stripped down version of 3 for time critical applications.
Run level programs are launched from the /etc/rc#.d/ (debian) or /etc/init.d/rc#.d/ (redhat/fedorka) directories (where # is the run level number in the directory name). For the beginner, load up X11/Gnome or KDE and look for the graphical run level editor to shut off the excess programs and reclaim a lot of ram. For the more experienced, check out the man pages for update-rc.d (debian) or chkconfig (red hat/fedorka) for the geek way.
In my run level 2, I normally shut down all the cron type programs and atd. These schedulers run when least expected and can really peg the processor doing mostly worthless tasks. When playing audio/video back under linux, I can usually tell when these are running as the system starts choking for a few minutes.
Other fluff programs for an audio class server: samba (unless you are sharing OUT from that box), apache (unless you have a web interface), ftp, inetd, database servers, NFS server, mail servers, print servers, and isdn services. I'm not sure why all these automatically activate when installed, but they often do.
BE CAREFUL when just shutting things off as a few of the more misc programs are needed by the OS to run and may cause trouble if suddenly missing. If you're unsure, look up the man page for the program and try turning things off ONE at a time then verifying your programs still run as expected.
Oh yeah, default run level is defined in /etc/inittab usually at the top with the line that starts with "id:". When the system boots, that line tells what run level to start in. If you want to change run levels while the system is up and going, type "init 2" for run level 2 (replace 2 with the desired run level).
Doing all this so far (and only running text console mode), you can get your total system RAM usage down to less than 20megs.
(use the command "free -m" to see usage)Here's another tip that will blow many minds: Get more RAM and just turn off swap ENTIRELY. Swap is pathetically slow and always will be. Swap is not needed for normal system operation. Swap is over flow catch. Swap was never intended to be a RAM replacement like some other OS's think....cough...gasp...micro$oft...hurl...splat
Command: "swapoff -a". To get it back on (as defined swap partitions in /etc/fstab) type "swapon -a".
Oh yeah, you can do this while the system is running (no reboots required). If you turn off swap, just make sure you have enough RAM to catch whatever was on disk.
With the operating system not swapping out to disk, the system behaves SO MUCH BETTER and much more responsive. This is a key element to a real time player.
I've even done this in windoze (yes it is possible)...and I'm amazed at my friends telling me that my dual 450 running XP is more snappy than their multi-ghz machines.
Before I forget (again), if you really want snappy, put your OS on a fast SCSI drive. It makes a difference in linux and a huge difference in windoze. I typically still use braindead IDE disks for large storage, though.
Kernel Recompiling. This can often be a hotly debated subject. In reality there are only a handfull of things you need to do to get the most out of your system. I usually compile core system drivers in as static/monolithic. I've had better results and stability that way. For here, keep audio drivers as modules. There are way too many drivers for audio cards and some seem to need parameters passed when they load (like my laptops). Turn off drivers you don't need or use. Leaving those as modules is ok if you want a generic type kernel, but they do take up some disk and slight memory table space.
I've also noted that some drivers will break the compile (when they shouldn't). Read carefully and disable those drivers. There will usually be a key word or something close by the error message for a clue.
Make sure the kernel is compiled specifically for the processor you are using. As mentioned in earlier posts, there are some real time options you can experiment with.
If you are new to all this, read the tldp.org howto's for this CAREFULLY. Giving specific instructions for kernel recompile is way too long and getting a bit off topic. Just realize that you WILL SPEND SOME TIME doing it over and over and over and over again testing variations. Don't be frustrated. I've compiled hundreds upon hundreds myself. The cleanest code is usually from kernel.org. Distributions tend to pre-patch their own source code and this can lead to abnormalities. While it is fine to use the distribution's code, most prefer the "pristine" source. Don't forget to tell your boot loader you have a new kernel after you compile and install it.
Recompile certain core packages. The libraries and programs you use heavily will slightly benefit from being recompiled to your current processor. Under debian I've just download the source and recompiled straight (super geek way). There is a recompile option for dpkg files, but I haven't done it yet. Under redhat/fedorka, look at the man page for "rpmbuild". After the package successfully recompiles, "reinstall" it over the existing.
Often the original (unpackaged) source code is more current, may be faster, and may have new features that are desirable. If you are new to compiling, stick to the package method above as that is usually more tested. Compiling a program from source isn't necessarily hard, but it can be overwhealming if you aren't aware of all the options. Start simple first.
....go to part 2
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.