Part 2: linux performance & tuning
continued from part 1...
If your audio box is just by itself and not using much in the way of networking, DHCP configuration is fine. If your audio box also happens to serve audio streams, files, web interface over the network, you should change the IP address to a static one that won't conflict with the internal DHCP server's address pool. Micro$oft seems to get confused if a samba server with the same name suddenly changes IP addresses.
As mentioned in one of the earlier posts, use the "setpci" command to change the hardware setup to something more in favor of the audio card. This does make a big difference. I've had dual booted systems and the windoze side would play ok during network transfers but the linux side would start pop'ing. That is why.
ALSO VERY, VERY IMPORTANT: off one of the "setpci" web articles was another article about testing the PC hardware. DO THIS AND NEVER, EVER BYPASS THIS.
READ THE ABOVE PARAGRAPH AGAIN!
And maybe once more. I've had brand new server class sytems I've built behave totally stupid. I wasn't able to trace down the problem until I started hardware testing.
JUST BECAUSE SOMETHING IS NEW OR BY A BIG NAME MANUFACTURER DOESN'T MEAN IT WILL WORK AS ADVERTISED!!!
Read the above again.
When things are going wrong for no good reason, this will save you many, many, many hours of headaches.
As a rule of thumb, I run memtest (memtest86.com, memtest.org) and drive fitness tests (DFT, download boot floppies/CD from your manufacturer's web site) on brand new systems even before an OS gets installed. I do this even for systems that have been running great for months on end. Just because it passed once doesn't mean it will pass again (esp. disk drives).
I also run "Linux Test Project" (see sourceforge.net) from time to time as it will really stress the OS. If there is a problem I need to pay attention to, it usually shows up as a crash.
Years ago I built an audio PC for my dad. That system was constantly acting flaky (moron name brands...) and nothing I did would fix it. Later I ran memtest and found out I got errors. Read the memtest pages carefully to fully understand this next part... It turns out that the problem wasn't the RAM but the processor. I've also found many more bad/poorly (cough...best buy specials) designed motherboards. Memtest over night is pretty good about finding errors in the data path (as in from cpu to mb to RAM).
In my personal experience over the years, out of 10 defective computers, 7 will have bad motherboards, 2 will have bad ram sticks, 1 will have a bad processor.
In case you haven't gotten above, this happens FAR MORE THAN THE COMMON CONSUMER REALIZES.
If you want a stable and happy PC that will run forever under linux, you have to have stable hardware under it. (in reality, true for any operating system)
ok, let's shift gears back to the opearting system for a minute. Linux is true multitasking. I think some one mentioned task priorities earlier. In short, one running program can be given more preference over another. This is good for your players and such.
For linux: "nice -n -19 command" where command is the command line name and options of the program you want to run (like the audio player). -19 may seem low mathmatically, but remember computers use positive binary only and once you cross the mid bit threshold, many use that bit as a flag for negative numbers. So binarially (is that even a word?) speaking, negative numbers can be greater than positive numbers.
You can read up more on that by typing "man nice". And using the flat out maximum priority possible isn't always the best way of doing things. Usually something in the mid-high range is appropriate.
You can also use the "top" command to see running processes and priorities (along with other stuff). Type 'q' to quit out of it.
Multiple Users. This usually isn't touched on much. It's fine to set up and test your system as "root" (being administrator), but root has sudden death access to the system that can totally wipe anything and everything with a slip of the fingers. When you get your system set up, create an audio type user and use that instead of root. Certain audio devices may need their permissions changed so that audio user can access them. That's done with "chmod" and "chown". As a general word of warning, don't chmod something to world writable as that invites security problems. Read the man pages for more detailed information.
"find" and "xargs" are your friend for batch conversion. Sometimes I'll encode my video captures with separate audio by way of lame.
My generic command:
cd /path/to/wav/files
find *.wav -type f | xargs -l1 replace=FILENAME nice lame...something FILENAME
That finds all the .wav files in a given directory, passes them to lame one at a time where the "...something" statement is the appropriate encoding parameters for the video file and FILENAME is one file at a time (in this case). "man xargs" for more in depth details.
This could also be used with flac or other lossless encoders...or probably after running cdparanoia to rip your disc you just bought before it gets scratched. To keep things from getting way over scattered with cdparanoia, it's best to create an "artist" directory with the name of the band/group/whatever then another sub directory with the disc title. It may even be a good idea to use sox to normalize the wav file (NOT COMPRESS) to get more consistent playback before flac encoding. I'm constantly amazed at the morons who call themselves professionals but don't know how max out the volume on the disc before mastering...digital audio can be in the mud too...but that's a whole other rant.
If you're the overly paranoid type about data integrity, you could create par2 parity recovery files for verification and repair. In debian there's a package called "par2" and "parchive".
http://parchive.sourceforge.net/ also has programs and links.
In reality this is probably a good thing for the paranoid even though it can eat up more space. If a disc gets scratched or a hard disk partially crashes, this is an easy way to verify and fix the file(s).
Oh yeah, it was mentioned above to add the "snd-usb-audio" module to list it in modules and reboot. While it does need to be in the modules list, you don't need to reboot to add it. Just type "modprobe snd-usb-audio". Linux rarely needs rebooting (mainly just for core libs...if that...and new kernels).
While on USB, I've read that using cat5 for the usb cable can greatly extend the link since usb is a differential signal. You'd probably need to make your own cable as I don't recall seeing these as common in stores. Just make sure that one twisted pair becomes the data lines.
To see what is on usb type: "lsusb". Many unix list commands start with "ls" from the dawn of the file "ls" command. Use "lsusb -v" for more detail.
Hmm...here's a hot topic that comes to mind: Power Management. This can be your best friend or your worst enemy. Some of this can be disabled on the kernel boot line with "noapm noapic". There are a few others that slip my mind at the moment. The apmd server can be shut off from starting in the run levels. Higher P3 and P4 CPU frequency scaling (cpufreq keyword) can be tweaked or shut off using /proc or /sys depending on how it was compiled in the kernel. Oh yeah, if you really hate it, just remove it from the kernel and recompile.
Some want power management on (slower fans, less heat), some will hate it because it causes pops or slow downs when changing states. This will more depend on your hardware and what you're doing than anything else. There is no real correct way to set this up universally for everyone. Just know it exists and can be changed.
I think I've lectured/rambled enough for one post. Copy this down and read it again carefully if you're new to linux. Many linux critics go on bashing sprees just because they don't know any of this (or even try).
|
-=D=-
|
BTW, if you happen to have experience with USB audio devices and linux, please post it here. I'm thinking about building a PCM2906 device for easy/generic/universal audio on linux (especially laptops) and am curious about how other's have faired.
I'm also curious about a cs42448 based USB device, but that seems to be much further out. (as in how would linux see it? 8 channels independent, or all acting together? argh...I need to learn SMD soldering now)
continued from part 1...
If your audio box is just by itself and not using much in the way of networking, DHCP configuration is fine. If your audio box also happens to serve audio streams, files, web interface over the network, you should change the IP address to a static one that won't conflict with the internal DHCP server's address pool. Micro$oft seems to get confused if a samba server with the same name suddenly changes IP addresses.
As mentioned in one of the earlier posts, use the "setpci" command to change the hardware setup to something more in favor of the audio card. This does make a big difference. I've had dual booted systems and the windoze side would play ok during network transfers but the linux side would start pop'ing. That is why.
ALSO VERY, VERY IMPORTANT: off one of the "setpci" web articles was another article about testing the PC hardware. DO THIS AND NEVER, EVER BYPASS THIS.
READ THE ABOVE PARAGRAPH AGAIN!
And maybe once more. I've had brand new server class sytems I've built behave totally stupid. I wasn't able to trace down the problem until I started hardware testing.
JUST BECAUSE SOMETHING IS NEW OR BY A BIG NAME MANUFACTURER DOESN'T MEAN IT WILL WORK AS ADVERTISED!!!
Read the above again.
When things are going wrong for no good reason, this will save you many, many, many hours of headaches.
As a rule of thumb, I run memtest (memtest86.com, memtest.org) and drive fitness tests (DFT, download boot floppies/CD from your manufacturer's web site) on brand new systems even before an OS gets installed. I do this even for systems that have been running great for months on end. Just because it passed once doesn't mean it will pass again (esp. disk drives).
I also run "Linux Test Project" (see sourceforge.net) from time to time as it will really stress the OS. If there is a problem I need to pay attention to, it usually shows up as a crash.
Years ago I built an audio PC for my dad. That system was constantly acting flaky (moron name brands...) and nothing I did would fix it. Later I ran memtest and found out I got errors. Read the memtest pages carefully to fully understand this next part... It turns out that the problem wasn't the RAM but the processor. I've also found many more bad/poorly (cough...best buy specials) designed motherboards. Memtest over night is pretty good about finding errors in the data path (as in from cpu to mb to RAM).
In my personal experience over the years, out of 10 defective computers, 7 will have bad motherboards, 2 will have bad ram sticks, 1 will have a bad processor.
In case you haven't gotten above, this happens FAR MORE THAN THE COMMON CONSUMER REALIZES.
If you want a stable and happy PC that will run forever under linux, you have to have stable hardware under it. (in reality, true for any operating system)
ok, let's shift gears back to the opearting system for a minute. Linux is true multitasking. I think some one mentioned task priorities earlier. In short, one running program can be given more preference over another. This is good for your players and such.
For linux: "nice -n -19 command" where command is the command line name and options of the program you want to run (like the audio player). -19 may seem low mathmatically, but remember computers use positive binary only and once you cross the mid bit threshold, many use that bit as a flag for negative numbers. So binarially (is that even a word?) speaking, negative numbers can be greater than positive numbers.
You can read up more on that by typing "man nice". And using the flat out maximum priority possible isn't always the best way of doing things. Usually something in the mid-high range is appropriate.
You can also use the "top" command to see running processes and priorities (along with other stuff). Type 'q' to quit out of it.
Multiple Users. This usually isn't touched on much. It's fine to set up and test your system as "root" (being administrator), but root has sudden death access to the system that can totally wipe anything and everything with a slip of the fingers. When you get your system set up, create an audio type user and use that instead of root. Certain audio devices may need their permissions changed so that audio user can access them. That's done with "chmod" and "chown". As a general word of warning, don't chmod something to world writable as that invites security problems. Read the man pages for more detailed information.
"find" and "xargs" are your friend for batch conversion. Sometimes I'll encode my video captures with separate audio by way of lame.
My generic command:
cd /path/to/wav/files
find *.wav -type f | xargs -l1 replace=FILENAME nice lame...something FILENAME
That finds all the .wav files in a given directory, passes them to lame one at a time where the "...something" statement is the appropriate encoding parameters for the video file and FILENAME is one file at a time (in this case). "man xargs" for more in depth details.
This could also be used with flac or other lossless encoders...or probably after running cdparanoia to rip your disc you just bought before it gets scratched. To keep things from getting way over scattered with cdparanoia, it's best to create an "artist" directory with the name of the band/group/whatever then another sub directory with the disc title. It may even be a good idea to use sox to normalize the wav file (NOT COMPRESS) to get more consistent playback before flac encoding. I'm constantly amazed at the morons who call themselves professionals but don't know how max out the volume on the disc before mastering...digital audio can be in the mud too...but that's a whole other rant.
If you're the overly paranoid type about data integrity, you could create par2 parity recovery files for verification and repair. In debian there's a package called "par2" and "parchive".
http://parchive.sourceforge.net/ also has programs and links.
In reality this is probably a good thing for the paranoid even though it can eat up more space. If a disc gets scratched or a hard disk partially crashes, this is an easy way to verify and fix the file(s).
Oh yeah, it was mentioned above to add the "snd-usb-audio" module to list it in modules and reboot. While it does need to be in the modules list, you don't need to reboot to add it. Just type "modprobe snd-usb-audio". Linux rarely needs rebooting (mainly just for core libs...if that...and new kernels).
While on USB, I've read that using cat5 for the usb cable can greatly extend the link since usb is a differential signal. You'd probably need to make your own cable as I don't recall seeing these as common in stores. Just make sure that one twisted pair becomes the data lines.
To see what is on usb type: "lsusb". Many unix list commands start with "ls" from the dawn of the file "ls" command. Use "lsusb -v" for more detail.
Hmm...here's a hot topic that comes to mind: Power Management. This can be your best friend or your worst enemy. Some of this can be disabled on the kernel boot line with "noapm noapic". There are a few others that slip my mind at the moment. The apmd server can be shut off from starting in the run levels. Higher P3 and P4 CPU frequency scaling (cpufreq keyword) can be tweaked or shut off using /proc or /sys depending on how it was compiled in the kernel. Oh yeah, if you really hate it, just remove it from the kernel and recompile.
Some want power management on (slower fans, less heat), some will hate it because it causes pops or slow downs when changing states. This will more depend on your hardware and what you're doing than anything else. There is no real correct way to set this up universally for everyone. Just know it exists and can be changed.
I think I've lectured/rambled enough for one post. Copy this down and read it again carefully if you're new to linux. Many linux critics go on bashing sprees just because they don't know any of this (or even try).
|
-=D=-
|
BTW, if you happen to have experience with USB audio devices and linux, please post it here. I'm thinking about building a PCM2906 device for easy/generic/universal audio on linux (especially laptops) and am curious about how other's have faired.
I'm also curious about a cs42448 based USB device, but that seems to be much further out. (as in how would linux see it? 8 channels independent, or all acting together? argh...I need to learn SMD soldering now)
Re: Part 2: linux performance & tuning
Hi Dunndatt.
Interesting "Linux" read. For Linux freaks only!
What did hit me:
1.
I'll try the swapoff.
2.
Instead of using "nice", using Ingo Molnar rt patches I'd consider
the better choice.
3.
I am runnung a PCM2707 as USB 2 I2S converter. This piece
of silicon is very sensitve to incoming jitter. That's mainly the
underlying reason for this thread. With a perfect soundcard, being able to perfectly regenerate the stream - timewise - this discussion would not be held.
Best results I achieved by running 48kHz material over the
PCM 2706.
4.
I never managed to make the setpci run on my dual-core machine.
On single core machines though, people report sound improvements.
Cheers SC
Hi Dunndatt.
Interesting "Linux" read. For Linux freaks only!
What did hit me:
1.
I'll try the swapoff.
2.
Instead of using "nice", using Ingo Molnar rt patches I'd consider
the better choice.
3.
I am runnung a PCM2707 as USB 2 I2S converter. This piece
of silicon is very sensitve to incoming jitter. That's mainly the
underlying reason for this thread. With a perfect soundcard, being able to perfectly regenerate the stream - timewise - this discussion would not be held.
Best results I achieved by running 48kHz material over the
PCM 2706.
4.
I never managed to make the setpci run on my dual-core machine.
On single core machines though, people report sound improvements.
Cheers SC
This is not necessary. I saw the date of your post... it was Jan 2007. By that time, Ubuntu v6.10 was stable and well documented, and the Ubuntu Website clearly specified what you need to download and install. I have followed those instructions on multiple desktops and scrambled DVDs and other audio/video formats have worked correctly afterwards. Zero compilation or fiddling with the source was necessary.kevinkr said:
I have done this a year ago too, with Ubuntu v5.10, with zero compilation or source fiddling, but the Ubuntu Website did not document the instructions well.... I had to look elsewhere for the instructions. That was the only difference.
You may need to recompile the kernel from source to get basic WAV audio playback working, if that doesn't work out of the box. But once basic WAV playback is working, no further recompilation should be needed with a modern Ubuntu version.
Re: Re: Linux Audio the way to go!?
Have you tried with a very recent version in the last few months? I am not just a Linux user, I work in an environment where I see a variety of people with a variety of competence levels all learning to install Linux and then going out and installing it at client sites. They do not seem to be facing any trouble at all, even when they do it the first time.
If you can install Windows XP by yourself from a CD, it's almost certain that you will be able to install Ubuntu v6.10 from a CD (or a modern SLED, SuSE Linux Enterprise Desktop, or any of the other modern Linux desktop distros) without trouble.pinkmouse said:
Have you tried with a very recent version in the last few months? I am not just a Linux user, I work in an environment where I see a variety of people with a variety of competence levels all learning to install Linux and then going out and installing it at client sites. They do not seem to be facing any trouble at all, even when they do it the first time.
Note that I specifically mentioned 64 bit linux in my post, and also the version I am running is 6.06 not 6.10.. Post date and installation date are actually quite removed in time. I've no doubt that installing deCSS in a 32 bit distro of ubuntu is much easier - I've done that too..
One other thing that needs to be mentioned is that installing deCSS in the U.S. is illegal, not that that stops anyone..
Don't get me wrong, I think Ubuntu is great and install the 32 bit version on desktops for total computer newbies, and the consensus is that it is reliable and easy to use, not to mention well supported.
The 64 bit version is a little more problematic, I have not so far successfully installed 32 bit wine on this distro, and that prevents me from running windoz apps I need daily. (There is no 64 bit version yet) So my transition to full linux use will probably be delayed until the end of winxp support at least.. I do occasionally recompile debian packages of various apps and get them to run successfully, but I usually try to stick to what is in the Ubuntu repositories.
One other thing that needs to be mentioned is that installing deCSS in the U.S. is illegal, not that that stops anyone..
Don't get me wrong, I think Ubuntu is great and install the 32 bit version on desktops for total computer newbies, and the consensus is that it is reliable and easy to use, not to mention well supported.
The 64 bit version is a little more problematic, I have not so far successfully installed 32 bit wine on this distro, and that prevents me from running windoz apps I need daily. (There is no 64 bit version yet) So my transition to full linux use will probably be delayed until the end of winxp support at least.. I do occasionally recompile debian packages of various apps and get them to run successfully, but I usually try to stick to what is in the Ubuntu repositories.
I am sick and tired of windoz. Linux works flawless on a dual boot laptop with win, but the latter cannot install the lan/modem, tried a lot.
Will sweep the win partition off soon, and make a dual boot linux/linux. Have somewhere an old pc in the attic with XP for the kids-games, not often in use. Even my kids want to play on the, by them called "fast", 616Mhz/512mB ! Ubuntu desktop in living room.
The silent Compaq laptop will be a linux music server in time. Ordered 512mB of ram, but the Armada E500 is picky with ram, it didn't work out.
I think USB audio sucks so I had some fun implementing an Ethernet streaming machine.
http://audio.peufeu.com/
The problem now is that it works well, so I'm not motivated to tweak it any further.
Next version will feature multichannel and a JACK driver. One day.
Oh yeah, it runs on Linux.
Try amarok XD
http://audio.peufeu.com/
The problem now is that it works well, so I'm not motivated to tweak it any further.
Next version will feature multichannel and a JACK driver. One day.
Oh yeah, it runs on Linux.
Try amarok XD
peufeu said:
Peufeu.
I wouldn't say in general that USB audio sucks. It is all relative, right!?
I might achieve 90% quality with my setup , you might achieve 92% with yours. If you look at it from an absolute perspective ethernet sucks pretty much the same as USB.
I am well aware of the limitations of USB. However.
If you followed the thread, you would have seen that it heavily depends on your setup. You can tweak a lot, without building
quite complex technical solutions as you did.
I tried Amarok. It can't cope with my player-setup.
Regarding Jack: Jack doesn't allow these low buffer sizes I am running, within my setup. I tried it. Jack is no option for me.
Jack is still using ALSA as soundcard interface, at least for USB soundcards.
The more processes you got in the chain, the worse it gets.
Process-Scheduling and IRQ handling are becoming an issue
and introduce non-linearities to the stream. WIth my realtime
Linux and RAMplayback I manage to get arround these issues
quite well.
In general the problem with USB (beside running it isonchronous) is that it usually doesn't get the IRQ respectively scheduling priority than e.g. ethernet, graphics, HDD
asf.
On older systems you can tweak this with setpci. On dual cores I unfortunately never managed. (Though, I think it is no longer needed.)
Cheers SC
Hehe, I read the entire thread now (interesting).
> it is also technically illegal to play back MP3, WMA, M4A, etc using Linux since the patented playback algorithms are reverse-engineered
Actually MP3 is open source (but patented) and all windows media is decoded with windows binary codecs (DLLs) running in some kind of emulation environment. It wreaks havoc on 64 bit machines.
I chose Linux for my audio PC because :
- it's more stable
- good support for RME (back when I used SPDIF)
- media player -> jack -> brutefir -> jack -> alsa
- has software RAID5 (I store my ripped CDs in FLAC on a RAID5 volume. OS is on a RAID1 volume. So this makes 7 hard disks.)
I must insist on RAID. Harddrives are so cheap now that the cost is insignificant. When (not if, when) one drive dies, there is no problem, I get a system message and change the drive. This happens about once a year.
Ethernet storage boxes are a disaster waiting to happen. You get a 500 GB fileserver with no redundancy. When the drive in it dies, all your data is gone. I don't store anything important on something that isn't RAID.
Software RAID is great because the RAID adapter can't fail because there isn't one. When my mobo dies, I can just plug the drives in a new one and Linux Kernel will autodetect the RAID. If I have a dead motherboard I can even put the drives in USB enclosures, connect them to my laptop and get the data. Usually, with hardware RAID, or motherboard RAID, when the controller fries you have to buy the exact same one, but since it's obsolete you can't find it, and your data is lost.
I make backups too which I store at my old man's house. The CDs are not at my home. So if I get robbed, I won't have to spend a month re-ripping my CDs. And it protects the huge amount of money I spent buying about 1000 CDs...
Linux is nice for backups since you can script pretty much anything.
Also with Windows you never know where your audio goes ; the system can convert sample rates or digital volume without telling. I believe you need ASIO to defeat this. On Linux you just need to tell ALSA not to use the mixer, and your samples are untouched.
I use audacious but also like amarok.
I said USB sucks (a bit of provocation !) because :
- the current crop of USB chips all extract their clocks from the USB isochronous ticks. This is an unnecessary compromise on jitter. It is better to slave the computer to the DAC. This is easy to do with a soundcard like RME or my ethernet thingie. When asynchronous USB audio comes it will be better.
- it has a 5m limitation on the cable length
- it is not electrically isolated
> An optical lan might be a potenial solution
Ethernet is transformer-isolated by design. Check that the ethernet jacks on your mobo or network cards have a "MagJack" logo or similar. On very old gear the transformer is a separated component. Then use UTP (unshielded) cable not STP (shielded) since the shield connects the grounds at both ends which defeats the transformer.
Latency is only meaningful for video playback (lipsync). The only use for a realtime kernel is to prevent buffer underruns. I use the CK kernel which has all the needed patches. Being able to use near realtime priority without root privileges saves a lot of headaches. It works very well and no matter how loaded the machine is, audio doesn't skip.
schedtool is much better than nice.
dunndatt>
Yeah testing gear is important. Murphy's law.
- I only use Kingston RAM
- I especially hate motherboards (for instance, nforce3-4 is incompatible with maxtor SATA drives. Symptoms are corrupt data sometimes and then after a week the drive seems dead. I went through 3 drives RMA'd and then changed all of them for seagates. It works). It seems nvidia likes mickey mouse features like the "hard firewall" in nforce4 which replaces some network packets with random data and corrupts all your downloads.
If you use 64 bit Linux like I did, be warned : your Athlon will love you, it's a lot faster, but all the 32 bit binaries now need special care and start to be a pain. These binaries include windos codecs, some quicktime, flash player etc. So 64-bit is a pain for multimedia.
-----------
Right now I'm using audacious > pipe > sox for oversampling > pipe > driver for my gear (written in C++) > ethernet > FPGA board > DAC.
It works but of course it's suboptimal. I oversample with sox since I have no digital filter on my DAC and besides, floating-point calculations done by a computer are a lot better than some cost-optimized hard filter inside a chip.
That such a kludge doesn't skip even under heavy multitasking is a testament to the quality of the low lat kernel patches...
Next step is to write a driver for JACK. I like Jack because everything runs in userspace so I don't need to write kernel code. Debugging is easy since it's like a regular program, not kernel. I have a driver almost finished which will support multichannel for brutefir.
I ran a test of my gear with no resampling, audacious playing into the ethernet DAC, I2S output looped back to I2S input, and the DAC sending back the data to the PC. The bits from my WAV file were untouched, so I know it works...
Keep up !
> it is also technically illegal to play back MP3, WMA, M4A, etc using Linux since the patented playback algorithms are reverse-engineered
Actually MP3 is open source (but patented) and all windows media is decoded with windows binary codecs (DLLs) running in some kind of emulation environment. It wreaks havoc on 64 bit machines.
I chose Linux for my audio PC because :
- it's more stable
- good support for RME (back when I used SPDIF)
- media player -> jack -> brutefir -> jack -> alsa
- has software RAID5 (I store my ripped CDs in FLAC on a RAID5 volume. OS is on a RAID1 volume. So this makes 7 hard disks.)
I must insist on RAID. Harddrives are so cheap now that the cost is insignificant. When (not if, when) one drive dies, there is no problem, I get a system message and change the drive. This happens about once a year.
Ethernet storage boxes are a disaster waiting to happen. You get a 500 GB fileserver with no redundancy. When the drive in it dies, all your data is gone. I don't store anything important on something that isn't RAID.
Software RAID is great because the RAID adapter can't fail because there isn't one. When my mobo dies, I can just plug the drives in a new one and Linux Kernel will autodetect the RAID. If I have a dead motherboard I can even put the drives in USB enclosures, connect them to my laptop and get the data. Usually, with hardware RAID, or motherboard RAID, when the controller fries you have to buy the exact same one, but since it's obsolete you can't find it, and your data is lost.
I make backups too which I store at my old man's house. The CDs are not at my home. So if I get robbed, I won't have to spend a month re-ripping my CDs. And it protects the huge amount of money I spent buying about 1000 CDs...
Linux is nice for backups since you can script pretty much anything.
Also with Windows you never know where your audio goes ; the system can convert sample rates or digital volume without telling. I believe you need ASIO to defeat this. On Linux you just need to tell ALSA not to use the mixer, and your samples are untouched.
I use audacious but also like amarok.
I said USB sucks (a bit of provocation !) because :
- the current crop of USB chips all extract their clocks from the USB isochronous ticks. This is an unnecessary compromise on jitter. It is better to slave the computer to the DAC. This is easy to do with a soundcard like RME or my ethernet thingie. When asynchronous USB audio comes it will be better.
- it has a 5m limitation on the cable length
- it is not electrically isolated
> An optical lan might be a potenial solution
Ethernet is transformer-isolated by design. Check that the ethernet jacks on your mobo or network cards have a "MagJack" logo or similar. On very old gear the transformer is a separated component. Then use UTP (unshielded) cable not STP (shielded) since the shield connects the grounds at both ends which defeats the transformer.
Latency is only meaningful for video playback (lipsync). The only use for a realtime kernel is to prevent buffer underruns. I use the CK kernel which has all the needed patches. Being able to use near realtime priority without root privileges saves a lot of headaches. It works very well and no matter how loaded the machine is, audio doesn't skip.
schedtool is much better than nice.
dunndatt>
Yeah testing gear is important. Murphy's law.
- I only use Kingston RAM
- I especially hate motherboards (for instance, nforce3-4 is incompatible with maxtor SATA drives. Symptoms are corrupt data sometimes and then after a week the drive seems dead. I went through 3 drives RMA'd and then changed all of them for seagates. It works). It seems nvidia likes mickey mouse features like the "hard firewall" in nforce4 which replaces some network packets with random data and corrupts all your downloads.
If you use 64 bit Linux like I did, be warned : your Athlon will love you, it's a lot faster, but all the 32 bit binaries now need special care and start to be a pain. These binaries include windos codecs, some quicktime, flash player etc. So 64-bit is a pain for multimedia.
-----------
Right now I'm using audacious > pipe > sox for oversampling > pipe > driver for my gear (written in C++) > ethernet > FPGA board > DAC.
It works but of course it's suboptimal. I oversample with sox since I have no digital filter on my DAC and besides, floating-point calculations done by a computer are a lot better than some cost-optimized hard filter inside a chip.
That such a kludge doesn't skip even under heavy multitasking is a testament to the quality of the low lat kernel patches...
Next step is to write a driver for JACK. I like Jack because everything runs in userspace so I don't need to write kernel code. Debugging is easy since it's like a regular program, not kernel. I have a driver almost finished which will support multichannel for brutefir.
I ran a test of my gear with no resampling, audacious playing into the ethernet DAC, I2S output looped back to I2S input, and the DAC sending back the data to the PC. The bits from my WAV file were untouched, so I know it works...
Keep up !
Hi Soundcheck,
Nice to see you still are improving the 'linux' sound. It took me some time, but yesterday I managed to play songs from ecasound. It is quiet some work to first CP the wanted, upsampled track to /tmp (to play from int. memory) and then command ecasound to play the track from there.
But once you listen to the result, you don't care to stand up and command another song all the time. It realy sounds way better than XMMS. You have the feeling it could not be better.
I have one step to go though. I do not play real-time already. Until now I did not succeed in installing the Ingo Molnar real-time patch.
I found out that the kernel 2.6.20 also has some interesting real-time options.
What should be the best solution ?
Werner
Nice to see you still are improving the 'linux' sound. It took me some time, but yesterday I managed to play songs from ecasound. It is quiet some work to first CP the wanted, upsampled track to /tmp (to play from int. memory) and then command ecasound to play the track from there.
But once you listen to the result, you don't care to stand up and command another song all the time. It realy sounds way better than XMMS. You have the feeling it could not be better.
I have one step to go though. I do not play real-time already. Until now I did not succeed in installing the Ingo Molnar real-time patch.
I found out that the kernel 2.6.20 also has some interesting real-time options.
What should be the best solution ?
Werner
You say that playing a file from ramdisk with a command line tool sounds better than playing it through XMMS... interesting.
What could be the cause ? Is XMMS messing with the bits ? Did you test data integrity by looping back digital output to input, recording and comparing to the WAV you played ?
What could be the cause ? Is XMMS messing with the bits ? Did you test data integrity by looping back digital output to input, recording and comparing to the WAV you played ?
peufeu said:
What does bitferfection tell you about soundperfection? -- Nothing! It's all about jitter. Isn't it.
In this particular case we're talking about latency jitter, which is caused by nonlinearities caused by process scheduling.
Especially the PCM270X output quality heavily depends on the incoming datastream quality.
BTW. "The comand line tool" is a heavily optimised music production software, optimised for very low resource utilisation.
It allows buffer manipulations in all aspects. And of course it is realtime optimised. Beside that it allows 32bit-foat DSP volume control. XMMS had been developed with a slight different intention. However. XMMS, with all its options, is IMO better than
any other "standard player" out there.
BTW. XMMS also needs to play it's files from RAMDISK to produce best quality!
Cheers.
Werner Rem said:
Hi Werner.
The rt-preemption kernel options you need are:
Running menuconfig - under "Processor type and features"
Preemption mode - Complete preemption (default desktop)
Timer freqency - 1000Hz (default 250)
You see that you'll get a 4 times higher timer resolution as you'd have with the default setup! Latency will be heavily affected by this setting.
Ubuntu also offers now a ready made 2.6.20-9-LOWLATENCY kernel, which you can AFAIK download and install from the repositories . You might google it up. In this case, assuming that above options are set, the rt-kernel installation should be quite easy.
I'll also post my ecasound player script over the weekend. That'll give you some nice features to run ecasound much more convenient.
Cheers SC
Surely the actual bits are in fact buffered at the PC end by the USB controller, then sent isochronously through USB to the DAC. ie the USB controller in the PC does the clocking, not the software, and thus process scheduling can't affect jitter .... although it could cause flow control issues (ie buffer under-runs).
Or am I missing something?
As I understand it, the problems with USB audio are:
1) USB streaming only supports 33/44.1/48khz, 16 bit
2) Mixer apps, and soundcards resample everything to 48Khz
3) No-one is implementing USB asynchronous mode, so the DAC is clocked by the cheap PC USB controller clock.
1) is a non-issue if you are playing FLAC'ed CDs, and I guess we'll have to wait for a protocol update, or use a custom protocol of some kind for anything better.
2) Is surely solved? I see people are re-sampling to 48khz in software to avoid the soundcard doing it (badly) for them. Is this only for certain soundcards? Can't we just stream 44.1khz over USB directly to the DAC without any resampling (as in windows ASIO)?
3) This seems a trivial problem, only requiring some kind of flow control scheme, ,which the USB streaming protocol already supports through isochronous streams with asynchronous synchronisation. So it is purely an implementation issue as far as I understand?
If none of the USB DACs are doing this already, this is screaming out for a DIY solution. For example, just a very quick google turns up the TAS1020A USB audio chip , whch supports async mode, though I don't know if it can accept an external high-quality clock input. Does this Linux USB audio driver support async?
I'm not a circuit guy, and don't know much about the linux audio subsystem, so just my 2pen'orth.
jackpipe said:
The poor PC clock will have an impact that's for sure.
But keep in mind that the clock quality itself is constantly bad.
If I play from RAM, run small buffers, increase the timer precision asf. all this has an impact to the stream, that's why the changes have nothing to do with the PC clock itself.
The PC is not able to supply a constant stream. It is working in a block mode. Think about it, on a standard XP-PC it needs minimum 10ms buffers to avoid underruns. That means there are phases where the audio process does not get 10ms time to run the stream to your DAC. This is a scheduling effect causing non- linearities, mainly due to the associated buffer handling.
I agree of course, if the PC clock would run in clock-slave mode to the DAC things would be much less complicated.
Cheers SC
Cheers SC
The maudio transit is an affordable product using the TAS1020A which passes 24/96 - I think this chip requires firmware which is not readily available, so the transit really is the best starting point for a diy solution with this chip. The firmware controls the mode of operation, and im not sure what this is for the transit, but I dont think it is asynchronous.
the transit outputs spdif so would probably be best to look into tapping off i2s if you were wanting to use it with another DAC. There is a lot of discussion of usb chips and all their modes at audioasylum - you will see there that many folk realise the benefits that asynchronous mode could bring, but that there are difficulties in implementing a diy solution - not enough demand for an easy silicon solution. It is the same for firewire; the chips which dont need firmware have been measured to have poor jitter, those requiring firmware are out of reach for most diyers.
Ive been playing with the new Jacklab linux distribution (JAD) based on opensuse for recording and production and am very impressed so far. The realtime kernel is simply downloaded and installed with no compiling required. opensuse's KDE desktop is then replaced with the e17 (enlightenment) desktop, which appears to run lighter than xfce, and in my opinion looks a lot better too.
Soundcheck, thanks for pointing out the ubuntu real time kernel. Glad you are still active with this.
the transit outputs spdif so would probably be best to look into tapping off i2s if you were wanting to use it with another DAC. There is a lot of discussion of usb chips and all their modes at audioasylum - you will see there that many folk realise the benefits that asynchronous mode could bring, but that there are difficulties in implementing a diy solution - not enough demand for an easy silicon solution. It is the same for firewire; the chips which dont need firmware have been measured to have poor jitter, those requiring firmware are out of reach for most diyers.
Ive been playing with the new Jacklab linux distribution (JAD) based on opensuse for recording and production and am very impressed so far. The realtime kernel is simply downloaded and installed with no compiling required. opensuse's KDE desktop is then replaced with the e17 (enlightenment) desktop, which appears to run lighter than xfce, and in my opinion looks a lot better too.
Soundcheck, thanks for pointing out the ubuntu real time kernel. Glad you are still active with this.
rossco_50 said:
Hi Ross.
Yeah. I am enjoying my Linux setup since a while by now.
The tweak potential and fexibility of Linux is just great.
I am a bit concerned though, that Linux, with just too many ongoing projects and limited resources, is loosing momentum. Vista and OSX are pretty much catching up. These actually also manage Latencies close to 1 ms today.
The Linux developers IMO should rather concentrate on a few but
rather high quality distributions and applications, instead of wasting its powers on a million of rather low quality (still sufficiant to work with of course) applications, distros and life cycle management.
Cheers SC
The benchmark DAC1 USB claims jitter-free USB audio, and at 24/192khz too (I thought USB streaming only supported max. 16/48khz - I'll have to check).
I'll admit to some slight skepticism, in that it claims to run on standard Win2000 drivers, which suggests it does not use asynchronous mode.
Perhaps they just run a dedicated DAC clock, and a buffer between USB receiver and DAC. Or maybe custom silicon?
Sorry I'm banging on about USB, rather than just Linux, though I am a Linux guy.
I'll admit to some slight skepticism, in that it claims to run on standard Win2000 drivers, which suggests it does not use asynchronous mode.
Perhaps they just run a dedicated DAC clock, and a buffer between USB receiver and DAC. Or maybe custom silicon?
Sorry I'm banging on about USB, rather than just Linux, though I am a Linux guy.
Dont think there is any such thing as "jitter free". I think you do need special drivers for async usb, and non asio usb drivers will go through the windows kmixer with all the resampling you mentioned before.
If you search under Gordon Rankin at audioasylum you'll find quite a few postings about asynchronous usb. He got async working diy (semi diy as I think he sells products), but had drop out problems on both mac and pc. He actually winded up saying that iso was currently the best way to good results.
See the link below for a good thread discussing the current state of the art.
http://db.audioasylum.com/cgi/m.mpl?forum=pcaudio&n=15272&highlight=asynchronous&session=
Soundcheck, vista does seem to have some nice audio features - hopefully this just raises the benchmark for opensource! There is no reason why linux can not always be developed to perform better.
Ross
If you search under Gordon Rankin at audioasylum you'll find quite a few postings about asynchronous usb. He got async working diy (semi diy as I think he sells products), but had drop out problems on both mac and pc. He actually winded up saying that iso was currently the best way to good results.
See the link below for a good thread discussing the current state of the art.
http://db.audioasylum.com/cgi/m.mpl?forum=pcaudio&n=15272&highlight=asynchronous&session=
Soundcheck, vista does seem to have some nice audio features - hopefully this just raises the benchmark for opensource! There is no reason why linux can not always be developed to perform better.
Ross
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.