Linux Audio the way to go!?

[jackpipe]

I think Gordon's problems are sounding like a Windows driver issue, and may well not be a problem under Linux (he seems to be saying OS X works fine), especially with the latency-reducing stuff you've been looking at.
Anyway, thanks for the pointer - I will follow this up.

[dunndatt]

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=-
|

[peufeu]

Originally posted by soundcheck

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.

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.

The poor PC clock will have an impact that's for sure.
But keep in mind that the clock quality itself is constantly bad.

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.

What peufeu said about his maxtor SATA drives

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.

peufeu: out of curiosity, did you run the maxtor DFT? Or any other DFT?

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...

[soundcheck]

Originally posted by peufeu


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.

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

[jackpipe]

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.

[peufeu]

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.

[soundcheck]

Originally posted by jackpipe
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.

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

[jackpipe]

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.

[soundcheck]

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

[peufeu]

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.