Linux Software RAID:
No doubts it can be quite amazing. I use it on many of my servers...and I dumped a RAID card in favor of software just because it trashed out and I couldn't recover my data (thanks to rsync to another computer in a cron job, I wasn't TOL). Just be aware that in higher performance transfers, the CPU does all the work and will be slower than a dedicated card (usually at least). This isn't a big deal for audio playback boxes, but it can become an issue if you've got a real time video editing workstation (but that's another forum).
One thing people tend to miss about linux software RAID is that the RAID block devices can be "stacked" on top of each other for some of the more esoteric RAID modes that seem to get popularity in bursts. One of the more common ones is a pair of stripes mirrored giving very fast read times with disk redundancy (tolerable write times, though).
One thing that must be pointed out: RAID does not guarantee against data corruption. It only protects against disk failure. What's the difference? Data corruption can happen with the disk fully operational. Data corruption can happen when a program crashes, hardware overheats, power gets lost, and so on. A failed disk becomes a door stop.
What peufeu said about his maxtor SATA drives is one of the few things that scares the hell out of me. (...and this is part of the reason I don't buy the cheaper drives any more) Intermittent corruption is the absolute worst and can give a good system (or a system that should at least be good) a really bad name and start all kinds of flame wars over wrong reasons. One also doesn't want to post stating the CD player is great and the USB DAC is tolerable when in reality the rip'd file on disk got corrupted somehow.
Oh yeah, things like peufeu's disk problem may or may not show up with the DFT testing I mentioned earlier. "Technically" his drives were good (at least as far as maxtor was concerned) but just couldn't fully speak the right controller language. DFT floppies "should" see this problem, but they may only implement a simple control sub-set as they are more designed to see problems on the platter than stress the controller's full language capabilities.
peufeu: out of curiosity, did you run the maxtor DFT? Or any other DFT?
I mentioned CRC checking in my previous post. For those with large collections, I would encourage at the very least md5 (built into most unix) or sfv. These two are relatively quick but offer no repair functionality. For that use par2:
par2 create -s102400 -r10 myArtist.par2 *.flac
This is best done on an album by album basis. To check and repair:
par2 repair myArtist.par2
Both of these commands aren't overly fast, but they have proven themselves to be true. Read up on "man par2" for variations of the command.
-----
Switching gears to USB chips...
I think the TAS1020A is depreciated in favor of the TUSB3200 (also by TI). I read somewhere that the 3200 had easier ROM programming. I'm a bit curious about the 3200 as it "should" appear as a generic USB audio device that linux should be able to handle. I really like the idea of it having DMA buffers, but I'm not so sure of my ROM programming capabilities to get it all working. Maybe the buffers on the 3200, good DAC, and decent reclocking in some combination can remove some of the problems associated with USB?
I really like the idea of linux+usb sound in some generic/easy form like this, but I'm still months away from testing this on my own. I still plan on starting out much simpler with a PCM2906+external clock first.
On a side note, I remember some late night delirium reading about some of the smarter (not cheaper) USB2 hubs with separate per port USB1 compatibility step down having internal buffering (similar to a 10/100 switch in the networking world). Has anyone tried to stick one of these in between the USB DAC to see if sound stability improves? Does anyone know how hard it would be to do a clock stability upgrade on one of these hubs? It's an interesting idea at least.
|
-=D=-
|
No doubts it can be quite amazing. I use it on many of my servers...and I dumped a RAID card in favor of software just because it trashed out and I couldn't recover my data (thanks to rsync to another computer in a cron job, I wasn't TOL). Just be aware that in higher performance transfers, the CPU does all the work and will be slower than a dedicated card (usually at least). This isn't a big deal for audio playback boxes, but it can become an issue if you've got a real time video editing workstation (but that's another forum).
One thing people tend to miss about linux software RAID is that the RAID block devices can be "stacked" on top of each other for some of the more esoteric RAID modes that seem to get popularity in bursts. One of the more common ones is a pair of stripes mirrored giving very fast read times with disk redundancy (tolerable write times, though).
One thing that must be pointed out: RAID does not guarantee against data corruption. It only protects against disk failure. What's the difference? Data corruption can happen with the disk fully operational. Data corruption can happen when a program crashes, hardware overheats, power gets lost, and so on. A failed disk becomes a door stop.
What peufeu said about his maxtor SATA drives is one of the few things that scares the hell out of me. (...and this is part of the reason I don't buy the cheaper drives any more) Intermittent corruption is the absolute worst and can give a good system (or a system that should at least be good) a really bad name and start all kinds of flame wars over wrong reasons. One also doesn't want to post stating the CD player is great and the USB DAC is tolerable when in reality the rip'd file on disk got corrupted somehow.
Oh yeah, things like peufeu's disk problem may or may not show up with the DFT testing I mentioned earlier. "Technically" his drives were good (at least as far as maxtor was concerned) but just couldn't fully speak the right controller language. DFT floppies "should" see this problem, but they may only implement a simple control sub-set as they are more designed to see problems on the platter than stress the controller's full language capabilities.
peufeu: out of curiosity, did you run the maxtor DFT? Or any other DFT?
I mentioned CRC checking in my previous post. For those with large collections, I would encourage at the very least md5 (built into most unix) or sfv. These two are relatively quick but offer no repair functionality. For that use par2:
par2 create -s102400 -r10 myArtist.par2 *.flac
This is best done on an album by album basis. To check and repair:
par2 repair myArtist.par2
Both of these commands aren't overly fast, but they have proven themselves to be true. Read up on "man par2" for variations of the command.
-----
Switching gears to USB chips...
I think the TAS1020A is depreciated in favor of the TUSB3200 (also by TI). I read somewhere that the 3200 had easier ROM programming. I'm a bit curious about the 3200 as it "should" appear as a generic USB audio device that linux should be able to handle. I really like the idea of it having DMA buffers, but I'm not so sure of my ROM programming capabilities to get it all working. Maybe the buffers on the 3200, good DAC, and decent reclocking in some combination can remove some of the problems associated with USB?
I really like the idea of linux+usb sound in some generic/easy form like this, but I'm still months away from testing this on my own. I still plan on starting out much simpler with a PCM2906+external clock first.
On a side note, I remember some late night delirium reading about some of the smarter (not cheaper) USB2 hubs with separate per port USB1 compatibility step down having internal buffering (similar to a 10/100 switch in the networking world). Has anyone tried to stick one of these in between the USB DAC to see if sound stability improves? Does anyone know how hard it would be to do a clock stability upgrade on one of these hubs? It's an interesting idea at least.
|
-=D=-
|
soundcheck said:
Okay, this is the stardard old problem...
The current crop of USB chips has the same problem as good old SPDIF, ie. the clock is in the wrong place (in the source instead of in the DAC where it should be) therefore anything that alters jitter on the way changes the sound.
This spawns an endless quest for better sound by changing digital cables, or kernels versions, all things that should have no influence whatsoever on the fidelity had the system been designed right in the first place...
That is why I stated in my first post that "USB sucks". Same as "SPDIF sucks", same old problem, same solution : remove the problem.
What you are hearing are interactions between the various PC subsystems. Since the USB DAC has poor jitter rejection, and no isolation from the PC, any perturbation in the PC clock and ground potential gets heard.
The PC clock is influences by its power supply and also the noise in the PC board.
Therefore, things like hard disk activity or CPU utilization, which cause large spikes in the PC power draw (harddisks are like loudspeakers, moving coil actuators, and to move the head from one point to another in less than 10 ms requires a very large current pulse which causes large amounts of supply noise)
Therefore, it is logical that playing from RAM sounds better than playing from the harddisk. I am pretty sure you will also get better sound by putting the harddisk to sleep (hdparm -y) or runnin diskless and booting from the network.
All these should not hide the fact that you are really trying to improve something that is flawed by design, ie. a system with imperfect clock recovery from a rather jittery source.
That is why I used Ethernet in my project : the master clock is in the DAC. The small FPGA based computer talks to the PC via ethernet and exchanges packetized audio. A simple protocol handles handshaking so the PC sends at the right rate and the onboard buffers are kept at a decent fill state. The other major selling point for Ethernet is that you don't need a driver ; actually the first "driver" was a plain Python script.
The FPGA board has a master clock input and I2S inputs/outputs. I can split the available 100Mbps between any number of channels, but since my DAC board only supports 16 bits at 88.2k that's what I use.
Yes, it was a real pain !
Actually Linux software RAID 1 and 5 have a check mode where it will scan the entire volume and either check that both mirrors are really mirrors, or that the pairity really XORs to zero. It is reassuring to launch this once in a while, but it takes quite long since it has ot read the whole drive.
It only runs from a floppy disk, and I don't have a floppy drive in any of my PCs since something like 2000. Why they don't make this available as a bootable CD ISO is beyond me.
But the three maxtor SATA HDDs crashed : a linux box, a windoze box, they even crash when in a USB enclosure, after about 2 hours of working perfect.
FLAC is nice because when you decompress a file it will check for errors. So, you can check integrity by running a batch decompression...
peufeu said:
I am pretty well aware of the power dependencies of the PC clock. Still, scheduling plays a major role here.
There are more than one source causing issues to the stream,
thats for sure.
I've also looked at your solution earlier. I am not saying that it is
bad, not at all. I am just saying that it needs some simple Linux tweaks to squeeze extreme nice sound out of a very simple USB DAC, such as my DDDAC. No doubt that there is improvement potential.
At this cost and effort the quality of sound is just outstanding.
If I look at my current sound and the "default" sound (before tweaking Linux and the data) the difference I'd call day and night.
I think I brought it quite far. Though I don't think I get much further on this track.
I'd be happy to try your FPGA board on my DDDAC. Of course I'd also would have to build a Masterclock.
Perhaps you'd share some information. I remember reading stuff
about it on your homepage some time ago. Perhaps you can post the link again.
Cheers SC
soundscape, I'll have to disagree with Gordon's conclusion (in the link you gave above) that USB async is not worth the hassle, and that synchronous sounds just as good sonically.
Having the clock at the source is the root of all evil for USB audio.
Not only is the (already skewy) clock potentially affected by anything going on on the PC, but there is also potential for jitter on the cable from PC to DAC. And finally, for synchronous mode at least, the DAC gets to follow a 12MHz clock. Thats fine if your data is 48KHz, since 12MHz/48KHz divides nicely. Not so 44.1KHz, hence another reason for all the resampling.
I'll take a look at TUSB3200 also, thanks.
peufeu, your ethernet solution looks very nice indeed. There's no reason USB shouldn't be able to achieve the same - the key is decoupling the clocks, and in order to do that you need flow control, or a large buffer and an optimistic attitude.
Having the clock at the source is the root of all evil for USB audio.
Not only is the (already skewy) clock potentially affected by anything going on on the PC, but there is also potential for jitter on the cable from PC to DAC. And finally, for synchronous mode at least, the DAC gets to follow a 12MHz clock. Thats fine if your data is 48KHz, since 12MHz/48KHz divides nicely. Not so 44.1KHz, hence another reason for all the resampling.
I'll take a look at TUSB3200 also, thanks.
peufeu, your ethernet solution looks very nice indeed. There's no reason USB shouldn't be able to achieve the same - the key is decoupling the clocks, and in order to do that you need flow control, or a large buffer and an optimistic attitude.
Yes, audio is just like any other data transfer as long as you do it asynchronously with flow control, the pipe doesn't matter : USB, ethernet, firewire... Except a buffer underrun on copying files is not important, while on audio it's a nice loud skip.
You can read about my stuff at http://audio.peufeu.com ; I'd have no problems sharing the source files but if someone wants to replicate it you need the same FPGA board, Xilinx EDK and knowledge of embedded coding and Verilog.
Right now it works but it would still need some polishing and especially a JACK driver for brutefir. I'll do this when I build a multichannel DAC... someday
Also I believe FireWire for instance derives its isochronous clock directly from the hardare PC clock whereas for USB it's an interrupt.
You can read about my stuff at http://audio.peufeu.com ; I'd have no problems sharing the source files but if someone wants to replicate it you need the same FPGA board, Xilinx EDK and knowledge of embedded coding and Verilog.
Right now it works but it would still need some polishing and especially a JACK driver for brutefir. I'll do this when I build a multichannel DAC... someday
Also I believe FireWire for instance derives its isochronous clock directly from the hardare PC clock whereas for USB it's an interrupt.
jackpipe said:
USB cables do make a difference. I am using a Monster Ultimate, which makes quite a difference. I couldn't find a better cable yet.
To get more stability on the clock, you need at least a 400W power supply. 500W is even better.
I am converting all my 44.1 material to 48kHz offline with a batch script I wrote. I am using Shibatch ssrc_hp for it. You might read Werners comments above.
The result is so much better, you won't believe it. Realtime SRC
you better forget.
Just give it a try.
My PCM2707 is also equipped with a 12MHZ precision Tent clock.
From that perspective im fine. I am running the same sample rate
throughout the whole chain and end up at a NONOS DAC.
Pretty straight forward.
Cheers
Sounds like a nice setup.
I'm sure software re-sampling to 48k is MUCH better than doing it realtime in hardware. My point is that you shouldn't need to do it at all.
Also, I think the PCM chip only does adaptive clocking, which means that it slews your 12MHz local clock one way or another in order to match the USB bus clock, to avoid flow control problems. This effectively performs a low-pass filter on the cheap USB controller's clock, which probably clears up 99% of any jitter problems.
But at the expense of the actual sample rate deviating slightly from reference as the effective clock is slewed back and forth.
That's my understanding, though I'm no expert, and just looking into this for the first time. My thinking is that it should be relatively easy to get a bit-accurate and perfectly-timed recreation of your music (or rather, your digital data) to the I2S inputs of a good DAC - which is where the "magic" begins.
I'm sure software re-sampling to 48k is MUCH better than doing it realtime in hardware. My point is that you shouldn't need to do it at all.
Also, I think the PCM chip only does adaptive clocking, which means that it slews your 12MHz local clock one way or another in order to match the USB bus clock, to avoid flow control problems. This effectively performs a low-pass filter on the cheap USB controller's clock, which probably clears up 99% of any jitter problems.
But at the expense of the actual sample rate deviating slightly from reference as the effective clock is slewed back and forth.
That's my understanding, though I'm no expert, and just looking into this for the first time. My thinking is that it should be relatively easy to get a bit-accurate and perfectly-timed recreation of your music (or rather, your digital data) to the I2S inputs of a good DAC - which is where the "magic" begins.
peufeu.
Just looked at your solution. I think it's just to complex to build and still comes with a bunch of obstacles, at least for me as an average DIYer it's a NOGO at this stage .
There are too many things in there, which I can't influence.
The FGPA seems to be a very tricky piece of silicon. ( and 200ms latency?)
As the best solution IMO I'd still prefer tapping off I2S from a PCI soundcard slaving an Envy chip to a master clock. This seems to be a much easier and managable solution if I want to get rid of USB/SPDIF asf.
Anyhow. This shouldn't be the topic of this thread.
How do you configure brutefir:
1. the alsa interface with its buffer/period asf parameters
2. the filters
hdparm:
You mentioned hdparm earlier.
I figured out that you need to put /var/log/ /dev asf on a RAMDISK
otherwise the HD starts spinning every other minute.
What did you do here?
Cheers
Just looked at your solution. I think it's just to complex to build and still comes with a bunch of obstacles, at least for me as an average DIYer it's a NOGO at this stage .
There are too many things in there, which I can't influence.
The FGPA seems to be a very tricky piece of silicon. ( and 200ms latency?)
As the best solution IMO I'd still prefer tapping off I2S from a PCI soundcard slaving an Envy chip to a master clock. This seems to be a much easier and managable solution if I want to get rid of USB/SPDIF asf.
Anyhow. This shouldn't be the topic of this thread.
How do you configure brutefir:
1. the alsa interface with its buffer/period asf parameters
2. the filters
hdparm:
You mentioned hdparm earlier.
I figured out that you need to put /var/log/ /dev asf on a RAMDISK
otherwise the HD starts spinning every other minute.
What did you do here?
Cheers
FPGAs are not tricky. They do what you want, but it takes some learning. Verilog is simple, but like any language, has its quirks. Actually even a low-end part like a Spartan3 packs quite a lot of power, and the high end parts from Xilinx (Virtex 4-5) are way, way over the insane level.
I'm completely aware that my solution isn't easy I also did it as a challenge, and for fun. I had never done verilog or embedded stuff before.
I do nothing special about my harddisks... but if you want your box to operate without harddisks you have two choices :
- you run a diskless box : this is a good option as your PC will be in your listening room, and HDDs are noisy. You can boot from a Flash drive, like a compactflash card, or use the NetBoot feature on your BIOS to boot from a server. But then you need a server.
- you can have a HDD in your HiFi PC and use noflush to put said HDD to sleep once it has booted.
I haven't tried either so can't advise...
Since ripping takes a lot of time, and I don't care about reinstalling stuff everytime a hard drive dies, I store my audio on a RAID5 as I said, so the PC isn't silent enough to be in the listening room. It is not noisy though. It's sitting there as I type, noticeable but not annoying.
"tapping off I2S from a PCI soundcard"
Been there, done that, it's actually pretty easy, I used a RME Digi96 ; others may also work. I have a master clock in my DAC and used a SPDIF encoder (actually a slaved CD723) to turn this clock into a SPDIF signal of silence. The soundcard auto slaves to this, a LED shows slave operation. The only thing to do is enable it in alsa config.
Then you look on the scope, the master DAC clock on channel one and the clock recovered by the SPDIF decoder on channel two ; plug the SPDIF into the card's input, it slaves to it, the LED lights, and the two scope traces lock and stay locked.
Basically if you don't require anything more than SPDIF can handle (wrt sample rate and frequency) the best solution WRT jitter is a DAC with master clock and spdif encoder, and a soundcard slaved to it. Optical if you want, this is better, no ground problems.
Right now I don't use BruteFIR. My DAC is only stereo, so I can't. My Ethernet rig has horrible latencies since the driver uses a pipe from sox to resample the audio. I am pretty sure I can get very low latencies usable for playing back video when I have the time to finish my Jack driver.
I have experimented with BruteFIR and an 8 way soundcard and amps ; the sonics of the soundcard weren't stellar but experimenting with different crossovers and drivers was real fun ; and the sound of an active system is more open, more dynamic, very enjoyable.
So, the next stage of my project is a multichannel DAC. One day.
I'm completely aware that my solution isn't easy
I also did it as a challenge, and for fun. I had never done verilog or embedded stuff before.I do nothing special about my harddisks... but if you want your box to operate without harddisks you have two choices :
- you run a diskless box : this is a good option as your PC will be in your listening room, and HDDs are noisy. You can boot from a Flash drive, like a compactflash card, or use the NetBoot feature on your BIOS to boot from a server. But then you need a server.
- you can have a HDD in your HiFi PC and use noflush to put said HDD to sleep once it has booted.
I haven't tried either so can't advise...
Since ripping takes a lot of time, and I don't care about reinstalling stuff everytime a hard drive dies, I store my audio on a RAID5 as I said, so the PC isn't silent enough to be in the listening room. It is not noisy though. It's sitting there as I type, noticeable but not annoying.
"tapping off I2S from a PCI soundcard"
Been there, done that, it's actually pretty easy, I used a RME Digi96 ; others may also work. I have a master clock in my DAC and used a SPDIF encoder (actually a slaved CD723) to turn this clock into a SPDIF signal of silence. The soundcard auto slaves to this, a LED shows slave operation. The only thing to do is enable it in alsa config.
Then you look on the scope, the master DAC clock on channel one and the clock recovered by the SPDIF decoder on channel two ; plug the SPDIF into the card's input, it slaves to it, the LED lights, and the two scope traces lock and stay locked.
Basically if you don't require anything more than SPDIF can handle (wrt sample rate and frequency) the best solution WRT jitter is a DAC with master clock and spdif encoder, and a soundcard slaved to it. Optical if you want, this is better, no ground problems.
Right now I don't use BruteFIR. My DAC is only stereo, so I can't. My Ethernet rig has horrible latencies since the driver uses a pipe from sox to resample the audio. I am pretty sure I can get very low latencies usable for playing back video when I have the time to finish my Jack driver.
I have experimented with BruteFIR and an 8 way soundcard and amps ; the sonics of the soundcard weren't stellar but experimenting with different crossovers and drivers was real fun ; and the sound of an active system is more open, more dynamic, very enjoyable.
So, the next stage of my project is a multichannel DAC. One day.
ecasound player script
Hi Werner and others who might want to try ecasound.
Below script is optimised for realtime playback.
As you can see I am running a 1 sample!! buffer size towards Alsa.
You can use the digital volume control. It comes with a linear scale!
I am listing as you can see below the linear and logarithmic scale to make life easier. ( I couldn't find a function in bash to prepare a formula doing that)
Note: I am not using an external volume control or pre-amp. Below gave me best results when doing it digital. I mainly never go below -14db attentuation. In
average I am running -12db (equals 2 bits). I am applying the to me best volume level to each album and save the particular volume in a volume-flag-file!
The limited dynamics I loose here are much less of a problem than the sound degradation I'd experienced with other equipment in the chain ( e.g. Stevens & Billington TX102 - transformer pot, which is IMO one of the best attentuators available )
I am also switching off a lot of stuff such as deamons, swap etc off before starting
the playback.
Actually, lately I am booting up in single user mode without even starting up the X environment. You won't get a faster system
Howto:
Copy below script into a file and save it under e.g. "eca".
Copy it to /usr/bin and chmod 770
Go to your music directory and just start eca. First time it'll ask you for the
best volume. Usually 20 is a good value.
You can stop the script by typing CTRL-C a couple of times.
I can post the stop script and the play-next song script later on if you like to have it.
Here we go.
Let me know if you run into problems.
Perhaps there are also some freaks around, who might tell me how to improve
below script.
I got one problem left with this setup. ecasound is not dithering when using the 32bit-DSP and then falling back to 16bit. They are working on it.
For that purpose I am thinking to use brutefir. I'd pipe ecasound 32bit into brutefir, which would do the dithering. I havn't really figured it out how to do it.
Cheers SC
------------------------------------------------------------------------------------------------------
#!/bin/bash
#
# The audio playback script using ecasound
# by soundcheck
#
# Rev.0.2 March-25-2007
#
# start script as root from the music file directory with $eca for full directory playback or with eca "searchstring" for playing a particular song. "searchsting" must be part of the filename
#
#
#
DEVICE="-o:alsahw,1,0"
PARAMS="-f:16,2,48000"
VOLUME="20"
VOLSRC=".volflg"
AUDIO_DIR=`pwd`
TEMP_DIR=/tmp # /tmp used as ramdisk. Enter string "tmpfs /tmp tmpfs defaults,size=1028m 0 0" to /etc/fstab for a 1 GB Ramdisk
ROOT_UID=0 # Only users with $UID 0 have root privileges.
LINES=50 # Default number of lines saved.
E_NOTROOT=67 # Non-root exit error.
E_WRONGARGS=65 # Non-numerical argument (bad arg format)
#-----------------------------------------------------------------------
# Run as root
#-----------------------------------------------------------------------
if [ "$UID" -ne "$ROOT_UID" ]
then
echo "Must be root to run this script."
exit $E_NOTROOT
fi
#-----------------------------------------------------------------------
# Prepare environment
#-----------------------------------------------------------------------
swapoff -a > /dev/null 2>&1
ps axco pid,command |grep xscreensaver | awk '{ print $1; }' | xargs kill -9 > /dev/null 2>&1
/etc/init.d/apmd stop > /dev/null 2>&1
/etc/init.d/networking stop > /dev/null 2>&1
/etc/init.d/cron stop > /dev/null 2>&1
/etc/init.d/klogd stop > /dev/null 2>&1
/etc/init.d/sysklogd stop > /dev/null 2>&1
/etc/init.d/acpid stop > /dev/null 2>&1
#--------------------------------------------------------------------------------------------------
# Prepare playlist. Example file name format: 01-Eric_Clapton-Unplugged-Tears_in_Heaven-48.wav
#--------------------------------------------------------------------------------------------------
if [ "$#" = 0 ]
then
fs=`find . -name "*.wav"`
else
if [ "$1" = "q" ]
then
shift
exit 0
fi
fs=`find . -name "*"$1"*.wav"`
fi
echo "Tracklist:"
for f in $fs
do
echo $f | mawk ' { gsub("_"," ") ; print } ' | mawk ' { gsub("48.wav","") ; print } ' | mawk ' { gsub("./","") ; print } '
done
#--------------------------------------------------------------------------------------------
# Check for default volume level stored in .volflg file
#--------------------------------------------------------------------------------------------------
if [ ! -f $VOLSRC ]
then
echo
echo "Could not locate <best-volume> flag. Default flag will be generated!"
touch $VOLSRC
chmod 666 $VOLSRC
echo "Linear/% 100 95 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10 5"
echo "Log/-db 0.00 0.4 1.4 1.9 2.5 3.1 3.7 4.4 5.2 6.0 6.9 8.0 9.1 10.5 12.0 14.0 16.5 20.0 26.0"
echo "Please enter best-volume (linear scale in %):"
read VOL
echo $VOL > $VOLSRC
VOLUME=$VOL
else
if [ -z $VOLSRC ]
then
echo $VOLUME > $VOLSRC
else
VOLUME=`cat $VOLSRC`
fi
fi
#--------------------------------------------------------------------------------------------
# Enter volume for current playback
#--------------------------------------------------------------------------------------------
echo "Linear/% 100 95 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10 5"
echo "Log/-db 0.00 0.4 1.4 1.9 2.5 3.1 3.7 4.4 5.2 6.0 6.9 8.0 9.1 10.5 12.0 14.0 16.5 20.0 26.0"
echo
echo "Volume (1-100) best( "$VOLUME" ) please enter new volume (linear scale in %) or type enter"
read VOL
case "$VOL" in
"" ) VOLUME=$VOLUME;;
* ) VOLUME=$VOL;;
esac
clear
echo "eca audio player - playing at volume: $VOLUME"
echo "________________________________________________________"
echo
sleep 2
#--------------------------------------------------------------------------------------------
# Main
#--------------------------------------------------------------------------------------------
xset dpms force off > /dev/null 2>&1 # switch off screen
for f in $fs ;
do
echo $f | mawk ' { gsub("_"," ") ; print } ' | mawk ' { gsub("48.wav","") ; print } ' | mawk ' { gsub("./","") ; print } '
xset dpms force off > /dev/null 2>&1
cp $f $TEMP_DIR
cd $TEMP_DIR
ecasound -r:98 -B:rtlowlatency -b:1 $PARAMS -i:$f -ea:"$VOLUME" $DEVICE > /dev/null 2>&1
cd $AUDIO_DIR
rm -rf $TEMP_DIR/*.wav > /dev/null 2>&1
done
#-----------------------------------------------------------------------
# Establish environment
#-----------------------------------------------------------------------
xset dpms force on > /dev/null 2>&1
# swapon -a > /dev/null 2>&1
# /etc/init.d/networking start > /dev/null 2>&1
# /etc/init.d/cron start > /dev/null 2>&1
echo "eca audio player - Hope you enjoyed it! - done"
exit 0
----------------------------------------------------------------------------------------------------------------------------------
Hi Werner and others who might want to try ecasound.
Below script is optimised for realtime playback.
As you can see I am running a 1 sample!! buffer size towards Alsa.
You can use the digital volume control. It comes with a linear scale!
I am listing as you can see below the linear and logarithmic scale to make life easier. ( I couldn't find a function in bash to prepare a formula doing that)
Note: I am not using an external volume control or pre-amp. Below gave me best results when doing it digital. I mainly never go below -14db attentuation. In
average I am running -12db (equals 2 bits). I am applying the to me best volume level to each album and save the particular volume in a volume-flag-file!
The limited dynamics I loose here are much less of a problem than the sound degradation I'd experienced with other equipment in the chain ( e.g. Stevens & Billington TX102 - transformer pot, which is IMO one of the best attentuators available )
I am also switching off a lot of stuff such as deamons, swap etc off before starting
the playback.
Actually, lately I am booting up in single user mode without even starting up the X environment. You won't get a faster system
Howto:
Copy below script into a file and save it under e.g. "eca".
Copy it to /usr/bin and chmod 770
Go to your music directory and just start eca. First time it'll ask you for the
best volume. Usually 20 is a good value.
You can stop the script by typing CTRL-C a couple of times.
I can post the stop script and the play-next song script later on if you like to have it.
Here we go.
Let me know if you run into problems.
Perhaps there are also some freaks around, who might tell me how to improve
below script.
I got one problem left with this setup. ecasound is not dithering when using the 32bit-DSP and then falling back to 16bit. They are working on it.
For that purpose I am thinking to use brutefir. I'd pipe ecasound 32bit into brutefir, which would do the dithering. I havn't really figured it out how to do it.
Cheers SC
------------------------------------------------------------------------------------------------------
#!/bin/bash
#
# The audio playback script using ecasound
# by soundcheck
#
# Rev.0.2 March-25-2007
#
# start script as root from the music file directory with $eca for full directory playback or with eca "searchstring" for playing a particular song. "searchsting" must be part of the filename
#
#
#
DEVICE="-o:alsahw,1,0"
PARAMS="-f:16,2,48000"
VOLUME="20"
VOLSRC=".volflg"
AUDIO_DIR=`pwd`
TEMP_DIR=/tmp # /tmp used as ramdisk. Enter string "tmpfs /tmp tmpfs defaults,size=1028m 0 0" to /etc/fstab for a 1 GB Ramdisk
ROOT_UID=0 # Only users with $UID 0 have root privileges.
LINES=50 # Default number of lines saved.
E_NOTROOT=67 # Non-root exit error.
E_WRONGARGS=65 # Non-numerical argument (bad arg format)
#-----------------------------------------------------------------------
# Run as root
#-----------------------------------------------------------------------
if [ "$UID" -ne "$ROOT_UID" ]
then
echo "Must be root to run this script."
exit $E_NOTROOT
fi
#-----------------------------------------------------------------------
# Prepare environment
#-----------------------------------------------------------------------
swapoff -a > /dev/null 2>&1
ps axco pid,command |grep xscreensaver | awk '{ print $1; }' | xargs kill -9 > /dev/null 2>&1
/etc/init.d/apmd stop > /dev/null 2>&1
/etc/init.d/networking stop > /dev/null 2>&1
/etc/init.d/cron stop > /dev/null 2>&1
/etc/init.d/klogd stop > /dev/null 2>&1
/etc/init.d/sysklogd stop > /dev/null 2>&1
/etc/init.d/acpid stop > /dev/null 2>&1
#--------------------------------------------------------------------------------------------------
# Prepare playlist. Example file name format: 01-Eric_Clapton-Unplugged-Tears_in_Heaven-48.wav
#--------------------------------------------------------------------------------------------------
if [ "$#" = 0 ]
then
fs=`find . -name "*.wav"`
else
if [ "$1" = "q" ]
then
shift
exit 0
fi
fs=`find . -name "*"$1"*.wav"`
fi
echo "Tracklist:"
for f in $fs
do
echo $f | mawk ' { gsub("_"," ") ; print } ' | mawk ' { gsub("48.wav","") ; print } ' | mawk ' { gsub("./","") ; print } '
done
#--------------------------------------------------------------------------------------------
# Check for default volume level stored in .volflg file
#--------------------------------------------------------------------------------------------------
if [ ! -f $VOLSRC ]
then
echo
echo "Could not locate <best-volume> flag. Default flag will be generated!"
touch $VOLSRC
chmod 666 $VOLSRC
echo "Linear/% 100 95 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10 5"
echo "Log/-db 0.00 0.4 1.4 1.9 2.5 3.1 3.7 4.4 5.2 6.0 6.9 8.0 9.1 10.5 12.0 14.0 16.5 20.0 26.0"
echo "Please enter best-volume (linear scale in %):"
read VOL
echo $VOL > $VOLSRC
VOLUME=$VOL
else
if [ -z $VOLSRC ]
then
echo $VOLUME > $VOLSRC
else
VOLUME=`cat $VOLSRC`
fi
fi
#--------------------------------------------------------------------------------------------
# Enter volume for current playback
#--------------------------------------------------------------------------------------------
echo "Linear/% 100 95 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10 5"
echo "Log/-db 0.00 0.4 1.4 1.9 2.5 3.1 3.7 4.4 5.2 6.0 6.9 8.0 9.1 10.5 12.0 14.0 16.5 20.0 26.0"
echo
echo "Volume (1-100) best( "$VOLUME" ) please enter new volume (linear scale in %) or type enter"
read VOL
case "$VOL" in
"" ) VOLUME=$VOLUME;;
* ) VOLUME=$VOL;;
esac
clear
echo "eca audio player - playing at volume: $VOLUME"
echo "________________________________________________________"
echo
sleep 2
#--------------------------------------------------------------------------------------------
# Main
#--------------------------------------------------------------------------------------------
xset dpms force off > /dev/null 2>&1 # switch off screen
for f in $fs ;
do
echo $f | mawk ' { gsub("_"," ") ; print } ' | mawk ' { gsub("48.wav","") ; print } ' | mawk ' { gsub("./","") ; print } '
xset dpms force off > /dev/null 2>&1
cp $f $TEMP_DIR
cd $TEMP_DIR
ecasound -r:98 -B:rtlowlatency -b:1 $PARAMS -i:$f -ea:"$VOLUME" $DEVICE > /dev/null 2>&1
cd $AUDIO_DIR
rm -rf $TEMP_DIR/*.wav > /dev/null 2>&1
done
#-----------------------------------------------------------------------
# Establish environment
#-----------------------------------------------------------------------
xset dpms force on > /dev/null 2>&1
# swapon -a > /dev/null 2>&1
# /etc/init.d/networking start > /dev/null 2>&1
# /etc/init.d/cron start > /dev/null 2>&1
echo "eca audio player - Hope you enjoyed it! - done"
exit 0
----------------------------------------------------------------------------------------------------------------------------------
Hi there.
Just a hint regarding my earlier post.
You should be careful with switching off the apcid deamon as stated in the last line of
the environment setup.
Just put a # in front of it or just delete it. AFAIK it is only for logging purposes. It works fine with my PC.
But you never know. ACPI issues might cause severe damage to the PC.
Don't blame me if something gets smoked
BTW - I am running the script on Ubuntu 6.10, a 2.6.20 Kernel and a Lenovo T60p.
Cheers
Just a hint regarding my earlier post.
You should be careful with switching off the apcid deamon as stated in the last line of
the environment setup.
Just put a # in front of it or just delete it. AFAIK it is only for logging purposes. It works fine with my PC.
But you never know. ACPI issues might cause severe damage to the PC.
Don't blame me if something gets smoked
BTW - I am running the script on Ubuntu 6.10, a 2.6.20 Kernel and a Lenovo T60p.
Cheers
Hi folks.
I made great progress yesterday.
Now my script checks available space on the RAMDISC.
It then copies the whole CD (directory) to the RAMDISC for gapless playback.
If there is not sufficiant space on the RAMDISC, in case the directory content is larger than the RAMDISC, it'll copy track by track.
I also managed to put /var and /dev on the RAMDISC. This was needed to prevent the disk from spinning up every other minute.
My hardisk can be spinned down now with hdparm -y /dev/sda while playing back music. (What's strange though - sdparm is not working even though I got a SATA drive installed!)
I am doing the spindown only if I store the whole directory on the RAMDISC .
Spinning down the disc every other song might cause damage to the harddisc on the long run.
During the coming days I'll do some listening tests to see if it makes an audible difference.
However, gapless playback and spindown of the disc due to power consumption savings on my notebook are reasons enough to leave it as it is right now.
I also got very close to get brutefir up'n running.
To be continued!
Cheers SC
I made great progress yesterday.
Now my script checks available space on the RAMDISC.
It then copies the whole CD (directory) to the RAMDISC for gapless playback.
If there is not sufficiant space on the RAMDISC, in case the directory content is larger than the RAMDISC, it'll copy track by track.
I also managed to put /var and /dev on the RAMDISC.
This was needed to prevent the disk from spinning up every other minute.My hardisk can be spinned down now with hdparm -y /dev/sda while playing back music. (What's strange though - sdparm is not working even though I got a SATA drive installed!)
I am doing the spindown only if I store the whole directory on the RAMDISC .
Spinning down the disc every other song might cause damage to the harddisc on the long run.
During the coming days I'll do some listening tests to see if it makes an audible difference.
However, gapless playback and spindown of the disc due to power consumption savings on my notebook are reasons enough to leave it as it is right now.
I also got very close to get brutefir up'n running.
To be continued!
Cheers SC
Hi Soundcheck
Thanks for sharing the ecosound playback script.
After I got it working it sounded like crap. But ofcoarse I have no lowlatency running, so the 1 sample does not work. (it sounded like half speed with a lot of distortion). After putting -b: to 256 in stead of 1 things started to work.
I tried to get the ubuntu 2.6.20 lowlatency kernel to work but too much things do not compare to the HOWTO's I find on the net. (no lilo.config, no grub.config, no bzImage found etc)
While doing the old.config I found out that there is about 95% in a kernel that you do not need to play music. I realy would like a small fast kernel without all the **** I don' need, but I'll first have to be a linux pro to arrange that I guess
Thank again Soundcheck
regards
Werner
Thanks for sharing the ecosound playback script.
After I got it working it sounded like crap. But ofcoarse I have no lowlatency running, so the 1 sample does not work. (it sounded like half speed with a lot of distortion). After putting -b: to 256 in stead of 1 things started to work.
I tried to get the ubuntu 2.6.20 lowlatency kernel to work but too much things do not compare to the HOWTO's I find on the net. (no lilo.config, no grub.config, no bzImage found etc)
While doing the old.config I found out that there is about 95% in a kernel that you do not need to play music. I realy would like a small fast kernel without all the **** I don' need, but I'll first have to be a linux pro to arrange that I guess
Thank again Soundcheck
regards
Werner
peufeu said:
The network playback I tried before. I doesn't work well when copying the tracks to
the ramdisk, as I do it. 100Mbit is just too slow, with 1GB ethernet it would be acceptable. If you do it track by track you'll get a gap in the range of 10s
between the tracks and for a full CD it takes more than a minute to download the
whole stuff..
Cheers
Werner Rem said:
Hi Werner.
Good to see that the script works. The kernel work is a bit tricky I can understand that. It took me also a while to get on top of it. You'll learn a lot while digging into it.
Tom, another guy trying my setup on a DDDAC, reported also great results with
the player script. He managed to get the rt-kernel working and is running
1 sample buffer size now.
I am still working on a HD spindown issue, I realized today. Since I am starting ecasound every time I play back a song I'll cause spin-ups by doing it this way,
I need to copy all programmes and tools to the RAMDISK to avoid disk-reads. That issue I solved in the new version.
The main problem I still have. ecasound reads every time it starts an /etc/ecasoundrc config-file and ~/.ecasound file, which are causing disk access.
I'll check tommorow with the ecasound folks, if i can get around it.
I guess that'll only work if I could start ecasound with an option, where I could specify the configfiles to be used.
If I manage to solve that issue, I'll sent you the new version of the script.
Perhaps I'll also look for a memory-stick/usb-stick installation of ubuntu, that would
resolve some issues.
Cheers
peufeu said:
Perhaps the networkstreaming is worth a try.
Still, from RAM to the processor is a much shorter way, I'd expect less latencies in the chain.
Beside that I have my audio rig completely isolated from mains.
I'd need to deploy an optical ethernet connection first to get my network drive
hooked on to the PC. (That'll cost me another 200€)
Cheers
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.