Linux Audio the way to go!? - Page 23 - diyAudio
Go Back   Home > Forums > Source & Line > PC Based

PC Based Computer music servers, crossovers, and equalization

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 9th August 2007, 11:16 AM   #221
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
Quote:
Originally posted by peufeu


What do you mean by weak ?
FPGA should never be used to process an audio clock, for instance, you have to reclock at the DAC. Otherwise, it rocks


My point is:

* Reclocking the stream at the DAC won't recover the "jitterless" source data if these are messed up earlier upstream.
* The latency you get into the stream due to the FGPA we discussed
some time ago. This will need some extra buffering.
* RAM is pretty limited on your FGPA but might be sufficiant for
streaming purposes
* I wonder if DSP (brutefir) would be done by the FGPA or on your
server. I doubt that your FGPA does the DSP work - right?
* Below GBit-ethernet, I wouldn't touch ethernet in context of
uncompressed audio transfer for storage and full-file buffering purposes.
* BTW. the ethernet interface is eating up quite some resources on the server. That might have an impact on the other IRQ managed processes and devices. You would have to increase buffers again.

You know -- I don't like buffers!


However. If everything in the chain is in sync, your approach could work.

I'll follow your progress.


Cheers
  Reply With Quote
Old 9th August 2007, 03:05 PM   #222
diyAudio Member
 
Join Date: Feb 2002
Quote:
Originally posted by soundcheck

The only advantage I see is the clocking issue. But I think there are more easy solutions to achieve this.
I really have to say that I completely fail to understand your perspective and approach. You seem to be missing the point that if you solve the clocking issue, then nothing else matters AT ALL. Assuming fixed DAC/analog components, the ONLY ways that a digital playback system can influence the sound are
a) data corruption
b) clock corruption

We know that a) isn't happening in any sanely constructed system. Therefore if your system sounds different every time you touch something, then you're clearly dealing with b. Why would you continue with an approach that has proven itself so sensitive to clock corruption that you can't sneeze without it sounding different? Peufeu's approach eliminates b about as well as any approach can; I may be going out on a limb, but I'd suggest that any system containing a PLL will be inferior.

The only comparable diy-ish system I've run across is Empiricals Pace Car, where Steve is 'exporting' the master clock back to the source. Being a boutique supplier though, this is very expensive and also requires modifying the souce.

SPDIF loopback used to slave the PC to a clock in a combined AD/DA unit can accomplish much the same thing, but there currently seems to be a dearth of units that support this. The Art DI/O does/did, but was compromised by marginal parts quality.

If there are other 'easier' ways to solve the clock problem, I'd ask
a) what are they?
b) why aren't you using them?

(hint: if your answer to a uses a pll, then try again)

Quote:

You know -- I don't like buffers!
Sure you do. What do you think you're doing when you read the entire file into RAM for playback? You're buffering the data. By removing the buffers from the output end and placing them at the source end you're compromising the isolation of the device from system activity, and then trying to compensate by reducing system activity in the first place. The fact that you end up with a multi-GHz cpu with GB+ levels of ram to basically do nothing but move data from a set of I/O buffers to a set of output DMA buffers and yet *still* have a system that is sensitive to activity suggests that there is something rather inefficient in the basic approach.

Quote:

* Reclocking the stream at the DAC won't recover the "jitterless" source data if these are messed up earlier upstream.
Perhaps this is the fundamental problem. The is no *RE*clocking. There is only *clocking*. Jitter can not be introduced 'upstream', because for the clock there is no 'upstream'.
  Reply With Quote
Old 10th August 2007, 02:16 PM   #223
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
Quote:
Originally posted by dwk123


The only comparable diy-ish system I've run across is Empiricals Pace Car, where Steve is 'exporting' the master clock back to the source. Being a boutique supplier though, this is very expensive and also requires modifying the souce.

If there are other 'easier' ways to solve the clock problem, I'd ask
a) what are they?
b) why aren't you using them?



Sure you do. What do you think you're doing when you read the entire file into RAM for playback? You're buffering the data. By removing the buffers from the output end and placing them at the source end you're compromising the isolation of the device from system activity, and then trying to compensate by reducing system activity in the first place. The fact that you end up with a multi-GHz cpu with GB+ levels of ram to basically do nothing but move data from a set of I/O buffers to a set of output DMA buffers and yet *still* have a system that is sensitive to activity suggests that there is something rather inefficient in the basic approach.

1. Steve reported that even his pacecar does show differences if you improve
the situation further upstream. Your reasoning is not at all plausible to me.
Perhaps you have better benchmarks then Steves pacecar.
2. Why don't you just take a PCI soundard, slave it to your external masterclock
and tap off the I2S for you own DAC. That's the easiest solution I see.
I doubt that it's gonna be worse than Peufeus approach.
3. I am not doing it - running for a more complicated approach - because the
sound I get from my tweaked USB setup is that good, that I actually don't have
the feeling that I'd need it any better. Nor I have the drive to spent thousends
of dollars for off-the-shelve HW. I burned enough money during my audio-life.
4. Sorry, but the RAM-buffer you're refering to, is not a buffer. It is a
filesystem. That I'd call somewhat a slight difference!

dwk123 - How about any constructive comments to improve the Linux setup?
(The DAC discussions are a bit off-topic!)

Cheers
  Reply With Quote
Old 10th August 2007, 03:30 PM   #224
peufeu is online now peufeu  France
diyAudio Member
 
Join Date: Mar 2001
Location: Lyon, France
Quote:
2. Why don't you just take a PCI soundard, slave it to your external masterclock and tap off the I2S for you own DAC. That's the easiest solution I see. I doubt that it's gonna be worse than Peufeus approach.
I tried it, it works well, with a RME Digi96/8 on Linux. I put the clock in the DAC, used a SPDIF encoder to send it to the soundcard, and the soundcard sent SPDIF back to the DAC, in sync with the master clock.

It's the easy easy way to do it if you want a format that SPDIF can handle (stereo...) For multichannel, you'd have to use ADAT with several fiber optics, and bunching channels together for higher sample rates (since ADAT supports 48k), then it tends to get a bit complex.
  Reply With Quote
Old 10th August 2007, 04:45 PM   #225
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
Quote:
Originally posted by peufeu


I tried it, it works well, with a RME Digi96/8 on Linux. I put the clock in the DAC, used a SPDIF encoder to send it to the soundcard, and the soundcard sent SPDIF back to the DAC, in sync with the master clock.

It's the easy easy way to do it if you want a format that SPDIF can handle (stereo...) For multichannel, you'd have to use ADAT with several fiber optics, and bunching channels together for higher sample rates (since ADAT supports 48k), then it tends to get a bit complex.

What I mean:
Just take the I2Sout from a VIA chip. The VIA chip has a master clock input - right, so it can easly be slaved. NO SPDIF or similar conversions in between. You just have to be very close to the VIA chip with the DAC, due to the known I2S limitations.
But that would be the same in your FPGA setup with an I2S out. What you'll lack with the PCI approach compared to ethernet is the galvanic isolation. (One question remains though: is the galvanic ethernet isolation really lossless in audio terms?)
If you run your AUDIO PCI interface at highest priority under Linux it'll most probably rock. I guess you won't find a shorter path in a PC environment ( HW- and SWwise).

If I had some more time I'd immediately start with above project, because it would also get me multiple synched channels for an active speaker setup.

Cheers
  Reply With Quote
Old 10th August 2007, 06:08 PM   #226
Radian is offline Radian  Germany
diyAudio Member
 
Join Date: Jun 2004
Location: Wiesbaden
Quote:
Originally posted by soundcheck



What I mean:
Just take the I2Sout from a VIA chip. The VIA chip has a master clock input - right, so it can easly be slaved. NO SPDIF or similar conversions in between. You just have to be very close to the VIA chip with the DAC, due to the known I2S limitations.
If I am not mistaken, what you discribe here is a PCI soundcard .
I2S from a chip to the Dac is exactly what happens in my Bluegears. After all the tweaks I did to it, the resulting sound is much better than my USB DDDac.
Now if I had a better clock and a dedicated PS for the card no telling......

Makes me wonder if the PC inviroment has as much bearing on the sound as some make us believe.

Klaus
  Reply With Quote
Old 10th August 2007, 06:24 PM   #227
Radian is offline Radian  Germany
diyAudio Member
 
Join Date: Jun 2004
Location: Wiesbaden
Speaking of PCI, I got a questions:

is there a cable that can be slit in the PCI slot and then taken out of the computer to attach the soundcard to?

Sorry for the little excursion from the topic.

Greets,
Klaus
  Reply With Quote
Old 10th August 2007, 06:31 PM   #228
diyAudio Member
 
Join Date: Jun 2004
Location: uk
Default PCI Extender

Klaus,

I can recommend this company for PI extenders both rigid and flexible.

http://www.adexelec.com/pci32.htm
  Reply With Quote
Old 10th August 2007, 06:45 PM   #229
Radian is offline Radian  Germany
diyAudio Member
 
Join Date: Jun 2004
Location: Wiesbaden
Wow exactly what I was looking for.

Thank you so much barryblue.

With the first one on the page I could even isolate the card from the motherbord's ground.

Greets,
Klaus
  Reply With Quote
Old 10th August 2007, 11:02 PM   #230
diyAudio Member
 
Join Date: Feb 2002
Quote:
Originally posted by soundcheck



What I mean:
Just take the I2Sout from a VIA chip. The VIA chip has a master clock input - right, so it can easly be slaved. NO SPDIF or similar conversions in between. You just have to be very close to the VIA chip with the DAC, due to the known I2S limitations.
If the budget allows, such a product already exists - the M-Audio Delta 1010. It brings the I2S lines to a DB25 port for connection to the external dac box. Pull the existing crystals and replace them with a good clock, and then either mod the heck out of the dac box or just route the I2S signals to your own setup. [I own one, and such a project has been on my 'maybe' list for quite a while]

Quote:

But that would be the same in your FPGA setup with an I2S out. What you'll lack with the PCI approach compared to ethernet is the galvanic isolation.
Well, there are other differences, although it's still a good approach. You have (probably) longer I2S lines, less EMI isolation, and less ability to remote the PC. Keeping the clock power supply clean might be the biggest challenge - both from a power/ground perspective and from an EMI perspective.

Quote:

(One question remains though: is the galvanic ethernet isolation really lossless in audio terms?)
I don't understand this statement. Are you suggesting that a transformer coupled ethernet connection between devices might introduce some *audio* artifacts?

Quote:

If I had some more time I'd immediately start with above project, because it would also get me multiple synched channels for an active speaker setup.
Cheers
There are many off-the-shelf ways to get multiple sync'd channels already, so this type of project (or the FPGA for that matter) is hardly a necessary precursor. I was doing active xovers using BruteFIR and a Delta 66 soundcard 8+ years ago, and the quality of multi-channel cards has only gotten better. IMHO worrying about the quality of the soundcard "up front" is a mistake - get the system architecture right first, the speaker/xover right second, and only after that worry about the sound card output.

However, even my Emu 1820M (which I think is a VERY good source in it's own right) falls a step short of ultimate sound quality in stock form, so if you want truly state-of-the-art reproduction for multi-channel output, you probably wont' get it without some degree of DIY. This is exactly why I'm so interested in the FPGA approach - it's the first thing I've come across that appears to offer a true upgrade over what I have.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



New To Site? Need Help?

All times are GMT. The time now is 06:53 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2