As for making crossovers etc in software DSP. there is a better solution than that (IMO) Creamware has a 3 SHARC card that you could use for very good quality output (with ADAT converter). and they will shortly be releasing the SDK for non profit use. so you can have REAL TIME crossovers and even sample accurate delays (for driver offset)
once a project is loaded into DSP it uses ZERO CPU cycles. in fact it will still work even if windows crashes (as i found out
)
check out "scope home"
http://www.cwaudio.de/
I have been using their products ever since they released the first pulsar, and i am always amazed at how good the sound is from them.
now i would like to measure jitter but i don't have any idea how to do that anyone know how to measure jitter in software without the recording or input itself affecting the measurement?
or is there a way to do it with a cheapo ocilloscope? (20mhz)
once a project is loaded into DSP it uses ZERO CPU cycles. in fact it will still work even if windows crashes (as i found out
)check out "scope home"
http://www.cwaudio.de/
I have been using their products ever since they released the first pulsar, and i am always amazed at how good the sound is from them.
now i would like to measure jitter but i don't have any idea how to do that
anyone know how to measure jitter in software without the recording or input itself affecting the measurement?or is there a way to do it with a cheapo ocilloscope? (20mhz)
It seems to me that ADAT is the way to go with a PC as source, unless one wants more than 2x24/192, but even then, if one wants more channels one could add more budget ADAT cards.
The Wavefront Al1402 receiver costs 18 euro shipped to Germany from http://www.profusionplc.com. A group buy would significantly reduce costs.
Here is a Adat project http://www.anidian.com/audio/construct/adac_1.shtml
a thread
http://www.anidian.com/audio/construct/adac_1.shtml
The Wavefront Al1402 receiver costs 18 euro shipped to Germany from http://www.profusionplc.com. A group buy would significantly reduce costs.
Here is a Adat project http://www.anidian.com/audio/construct/adac_1.shtml
a thread
http://www.anidian.com/audio/construct/adac_1.shtml
Sharc bait
We seem to be moving this discussion toward design of an external dac that can:
1. input from usb 2.0
2. buffer substantial amount of data (large fraction of a song)
3. provide all clocking so the dac needs no timing info from the pc
4. provide dsp volume control
5. provide dsp crossover (max = 3-way?)
6. provide dsp delay corrections to each channel
Neutron is advocating Sharcs's to perform the dsp functions on the dac card and I'm assuming they would be setup via USB in our case. I like that the functionality of the Sharcs could change with software unlike fixed purpose dacs. I intend to investigate these DSP's over the next week or two, but at this point don't know much about them. Could you post a concise tutorial? How much do they cost? How conducive to diy pcb construction? Would we need to have a professional board stuffer make these boards?
I'm with peufeu on the use of Linux for this project, but others will probably want Windows and Mac. That's another benefit of putting all the dsp into the external dac and limiting the function of the pc to hosting files and providing setup to the dsp chips. The software would be highly transportable.
For my own purposes, I really don't care if the project gets costly. My intent is to end up with a better player than any cd transport.
Thanks for posting such well-considered ideas everyone!
Regarding neutron's call for help on jitter measurement in his system, we really need this expertise badly for this thread. At the moment, I don't even know how to measure overall jitter such as is done by Stereophile. Their method still seems to me to be a good starting point for us. If we could all measure jitter output from our analog or amp outputs, we could then test changes and compare results.
Who in this forum has the expertise on jitter measurements? We need their help.
-Robert
We seem to be moving this discussion toward design of an external dac that can:
1. input from usb 2.0
2. buffer substantial amount of data (large fraction of a song)
3. provide all clocking so the dac needs no timing info from the pc
4. provide dsp volume control
5. provide dsp crossover (max = 3-way?)
6. provide dsp delay corrections to each channel
Neutron is advocating Sharcs's to perform the dsp functions on the dac card and I'm assuming they would be setup via USB in our case. I like that the functionality of the Sharcs could change with software unlike fixed purpose dacs. I intend to investigate these DSP's over the next week or two, but at this point don't know much about them. Could you post a concise tutorial? How much do they cost? How conducive to diy pcb construction? Would we need to have a professional board stuffer make these boards?
I'm with peufeu on the use of Linux for this project, but others will probably want Windows and Mac. That's another benefit of putting all the dsp into the external dac and limiting the function of the pc to hosting files and providing setup to the dsp chips. The software would be highly transportable.
For my own purposes, I really don't care if the project gets costly. My intent is to end up with a better player than any cd transport.
Thanks for posting such well-considered ideas everyone!
Regarding neutron's call for help on jitter measurement in his system, we really need this expertise badly for this thread. At the moment, I don't even know how to measure overall jitter such as is done by Stereophile. Their method still seems to me to be a good starting point for us. If we could all measure jitter output from our analog or amp outputs, we could then test changes and compare results.
Who in this forum has the expertise on jitter measurements? We need their help.
-Robert
Please define ADAT
swak,
Many who are not familiar with recording do not know much about ADAT and why it has applicability here.
Would you please carefully define what about ADAT is useful for us?
All I know about ADAT would fit on the head of a pin. It's an 8-track 20-bit format that's an upgrade of an original 16-bit version that was/is used to record onto S-VHS video tape. I believe part of the standard definition includes optical interface. What else?
-Robert
swak,
Many who are not familiar with recording do not know much about ADAT and why it has applicability here.
Would you please carefully define what about ADAT is useful for us?
All I know about ADAT would fit on the head of a pin. It's an 8-track 20-bit format that's an upgrade of an original 16-bit version that was/is used to record onto S-VHS video tape. I believe part of the standard definition includes optical interface. What else?
-Robert
here is what i know about it.
* was originally for Alesis ADAT tape machines but they are not used much any more, most pro sound cards and interfaces use the standard now.
* uses same optical cables and connectors as sp/dif (optical)
* 8 channels uni directional per fiber optic cable
* most ADAT interfaces are now 24 bit.
* wordclock can be any 1 device in chain.
* a dead mechanism Alesis ADAT machine can be used for a cheap ADAT interface, but it is only 20 bit (maybe less i forget) you could probably pull the guts out and put it in a 1u case.
i had an idea for a music player/crossover testing PC
tiny VIA EDEN fanless motherboard.
http://www.viavpsd.com/product/epia_MII_spec.jsp?motherboardId=202
Creamware Scope HOME in PCI slot
VERY quiet seagate 7000.1 hard drive
linear regulated home built power supply from custom wound torroid! these days you do not need -5 and -12 volts to supply motherboards, so it would only need +5 and +12 at about 160VA each(did not calculate. thats a guess.).
standby for ATX switch/relay can be low power trafo.
sharp 5.5 inch LCD display (i have some allready sitting gathering dust)
seperate PSU and good wordclock for ADAT output (seperate case)
the only noise making moving part would be the hard drive, and it can be not used at all with boot from USB chip drive or boot from network. I would leave it in for standalone use though.
* was originally for Alesis ADAT tape machines but they are not used much any more, most pro sound cards and interfaces use the standard now.
* uses same optical cables and connectors as sp/dif (optical)
* 8 channels uni directional per fiber optic cable
* most ADAT interfaces are now 24 bit.
* wordclock can be any 1 device in chain.
* a dead mechanism Alesis ADAT machine can be used for a cheap ADAT interface, but it is only 20 bit (maybe less i forget) you could probably pull the guts out and put it in a 1u case.
i had an idea for a music player/crossover testing PC
tiny VIA EDEN fanless motherboard.
http://www.viavpsd.com/product/epia_MII_spec.jsp?motherboardId=202
Creamware Scope HOME in PCI slot
VERY quiet seagate 7000.1 hard drive
linear regulated home built power supply from custom wound torroid! these days you do not need -5 and -12 volts to supply motherboards, so it would only need +5 and +12 at about 160VA each(did not calculate. thats a guess.).
standby for ATX switch/relay can be low power trafo.
sharp 5.5 inch LCD display (i have some allready sitting gathering dust)
seperate PSU and good wordclock for ADAT output (seperate case)
the only noise making moving part would be the hard drive, and it can be not used at all with boot from USB chip drive or boot from network. I would leave it in for standalone use though.
ADAT
Can we hear more about ADAT? Is it used by many forum members? What does it excel at and what is not so good? Is it applicable to high-end consumer audio equipment? Why isn't it more common today, compared with s/pdif?
I'm just not familiar with it so that's why all the probably idiot questions.
Please all of you with ADAT project experience, would you weigh-in on this topic? Should the world's best music player use ADAT as the interfacing format?
-Robert
Can we hear more about ADAT? Is it used by many forum members? What does it excel at and what is not so good? Is it applicable to high-end consumer audio equipment? Why isn't it more common today, compared with s/pdif?
I'm just not familiar with it so that's why all the probably idiot questions.
Please all of you with ADAT project experience, would you weigh-in on this topic? Should the world's best music player use ADAT as the interfacing format?
-Robert
Re: ADAT
Do you have a studio with multitrack recording devices? Do you have a need for multitrack I/O for your editng workstation? If not, then you probably do not need ADAT. ADAT and SPDIF perform similar functions in different arenas. It isn't more common in this arena, for much the same reason as SMPTE259,AES10 and a myriad of other i/f standards. It is not relevant and does not make economic sense.
Probably not. ADAT is fine and may or may not be better than SPDIF or the more relevant AES/EBU interface but if one was insane enough to contemplate such excesses there are far more capable interfaces out there.
If you want to know more about ADAT, visting the Alesis website
http://www.alesis.com and seeing the products it was designed for would be a good start. The chipset datasheets are at
http://www.alesis-semi.com/index.html.
ray
RFScheer said:
Do you have a studio with multitrack recording devices? Do you have a need for multitrack I/O for your editng workstation? If not, then you probably do not need ADAT. ADAT and SPDIF perform similar functions in different arenas. It isn't more common in this arena, for much the same reason as SMPTE259,AES10 and a myriad of other i/f standards. It is not relevant and does not make economic sense.
Probably not. ADAT is fine and may or may not be better than SPDIF or the more relevant AES/EBU interface but if one was insane enough to contemplate such excesses there are far more capable interfaces out there.
If you want to know more about ADAT, visting the Alesis website
http://www.alesis.com and seeing the products it was designed for would be a good start. The chipset datasheets are at
http://www.alesis-semi.com/index.html.
ray
Re: Sharc bait
Would be nice !
Not necessarily. Buffering about a second is OK if the computer can push the data without too much latency. I think Linux can do this.
Definitely.
I'm against digital volume controls.
This can be done in software on the computer with free software which works. I do not see any necessity to reimplement it. Brutefir works perfectly. A cheap Duron will have way too much crunching power, and it can work in very low latency too. Developing a custom DSP system is a lot of work.
Brutefir already provides this (set delay = number of samples)
The chips are cheap, but :
These are SMD parts with many pins and will need a double sided, if not multilayer, plated-through board. Difficult to solder, etc. I wouldn't embark on the design of a DSP solution as my PC already does this for free !
Not necessarily.
A PC with Linux installed will be cheaper than a DSP board. Windowes, why not ? Mac is Unix now, so you get BruteFIR too.
I think it's cheaper, easier and faster to develop to use the PC for DSP. You can do as you wish, of course, but if you're not a professional DSP developer, you'll need many months full time to get it right. And you need a good knowledge of DSP to implement algorithms that sound good.
So I'd definitely go with an USB2 DAC which would take data from the PC at any useful sample rate and bitwidths, and implement the rest of the stuff on the PC.
Concerning Volume control, I'd do it with relays or an integrated potentiometer IC.
Have fun !
Would be nice !
Not necessarily. Buffering about a second is OK if the computer can push the data without too much latency. I think Linux can do this.
Definitely.
I'm against digital volume controls.
This can be done in software on the computer with free software which works. I do not see any necessity to reimplement it. Brutefir works perfectly. A cheap Duron will have way too much crunching power, and it can work in very low latency too. Developing a custom DSP system is a lot of work.
Brutefir already provides this (set delay = number of samples)
The chips are cheap, but :
These are SMD parts with many pins and will need a double sided, if not multilayer, plated-through board. Difficult to solder, etc. I wouldn't embark on the design of a DSP solution as my PC already does this for free !
Not necessarily.
A PC with Linux installed will be cheaper than a DSP board. Windowes, why not ? Mac is Unix now, so you get BruteFIR too.
I think it's cheaper, easier and faster to develop to use the PC for DSP. You can do as you wish, of course, but if you're not a professional DSP developer, you'll need many months full time to get it right. And you need a good knowledge of DSP to implement algorithms that sound good.
So I'd definitely go with an USB2 DAC which would take data from the PC at any useful sample rate and bitwidths, and implement the rest of the stuff on the PC.
Concerning Volume control, I'd do it with relays or an integrated potentiometer IC.
Have fun !
An easier solution would be to use a RME Hammerfall soundcard which has a ton of ADAT output and use one ADAT per 24-192 channel. No drivers to write, but you need several optical fibers. Not really a problem...
Maybe some programmable logic will be needed to put all the bits together in the DAC.
The soundcard can be slaved to the DAC's clock via a dummy ADAT channel.
Even better, the DAC can contain an ADC to generate this input ADAT channel, to use the digital crossover with Vinyl, a tuner, anything...
Maybe some programmable logic will be needed to put all the bits together in the DAC.
The soundcard can be slaved to the DAC's clock via a dummy ADAT channel.
Even better, the DAC can contain an ADC to generate this input ADAT channel, to use the digital crossover with Vinyl, a tuner, anything...
Re: Re: Sharc bait
Can someone explain this particular oddity to me. Surely once the crossover points are chosen, they are set till you change the speakers unless you think of crossovers as tone controls and have an attendant need to fiddle with them. Seems much more sensible to me to work out your coefficients, load your dsp board and have done with it. Seems like a solution in search of a problem to me.
Their is more than a hint of the tail wagging the dog here, with the system skewed to work from the PC when it clearly isn't necessary. Why setup via USB? It clearly isn't necessary. Two buttons and an LCD is all you actually need but where's the fun in that?
ray.
peufeu said:
Can someone explain this particular oddity to me. Surely once the crossover points are chosen, they are set till you change the speakers unless you think of crossovers as tone controls and have an attendant need to fiddle with them. Seems much more sensible to me to work out your coefficients, load your dsp board and have done with it. Seems like a solution in search of a problem to me.
RFScheer said:
Their is more than a hint of the tail wagging the dog here, with the system skewed to work from the PC when it clearly isn't necessary. Why setup via USB? It clearly isn't necessary. Two buttons and an LCD is all you actually need but where's the fun in that?
ray.
Re: Re: Re: Re: Re: Re: Sharc bait
Defining "better" is a tricky one here. For example, in a fraction of the time it take a PC to boot up,a pocket calculator can carry out a variety of mathematical functions simply because it is dedicated to that purpose but does that make it "better"? As far as the audio is concerned the digital crossover is a process in the audio path and there is no user interaction. As I see it, it is a case of six of one and half a dozen of the other and there is no real objective basis for going one way or the other. That being the case, a combination of an AD Tigersharc and Virtex or Stratix or two make for a considerably smaller, if a little pricey, footprint than a PC.
Not that one needs them in this case, the only limitation on the size of FFT one can process is the amount of memory available and the tolerable latency and that applies whatever method of processing one chooses. Setup time is irrelevant as it is only done when changing coefficients.
ray
MWP said:
Defining "better" is a tricky one here. For example, in a fraction of the time it take a PC to boot up,a pocket calculator can carry out a variety of mathematical functions simply because it is dedicated to that purpose but does that make it "better"? As far as the audio is concerned the digital crossover is a process in the audio path and there is no user interaction. As I see it, it is a case of six of one and half a dozen of the other and there is no real objective basis for going one way or the other. That being the case, a combination of an AD Tigersharc and Virtex or Stratix or two make for a considerably smaller, if a little pricey, footprint than a PC.
Not that one needs them in this case, the only limitation on the size of FFT one can process is the amount of memory available and the tolerable latency and that applies whatever method of processing one chooses. Setup time is irrelevant as it is only done when changing coefficients.
ray
Explanation
Right, once you're happy with the crossover points you probably don't fiddle. The issue is whether the crossover dsp is crunched in the pc or in the soundcard. peufeu advocates that there is already free software available for Linux (and Windows also) that many people successfully run today that does it in the pc so why waste time reinventing it for a custom dsp soundcard? So the coefficients that determine crossover points are stored in BruteFIR setup file.
Back to the definition of our system. At the moment, peufeu seems to be making a good point that it would be an inappropriate waste to redesign software that already works well just because we're infatuated with sharcs or whatever. Let's make sure that he's correct.
Let's imagine a reference system in which we have stereo speakers. Later on we can talk about surrounds but for now let's keep simple. Our stereo reference system has 3 channels left (lo, mid and hi) and 3 for right. Let's assume for now that these 6 channels are delivered from Linux BruteFIR to the soundcard through a usb interface. Correct?
Is there any chance that these 6 channels can lose perfect synchrony with each other somewhere in the soundcard/dac chain?
Does anyone know whether BruteFIR algorithms for crossover filtering are capable of lossless volume control? It seems like this should be a no-brainer if we have original 16 bit information being upsampled to 24 bits delivered to the soundcard. Those extra 8 bits provide 48dB of lossless attenuation right? I'm just trying to be logical, but don't really understand this stuff yet. More reading required.
-Robert
Right, once you're happy with the crossover points you probably don't fiddle. The issue is whether the crossover dsp is crunched in the pc or in the soundcard. peufeu advocates that there is already free software available for Linux (and Windows also) that many people successfully run today that does it in the pc so why waste time reinventing it for a custom dsp soundcard? So the coefficients that determine crossover points are stored in BruteFIR setup file.
Back to the definition of our system. At the moment, peufeu seems to be making a good point that it would be an inappropriate waste to redesign software that already works well just because we're infatuated with sharcs or whatever. Let's make sure that he's correct.
Let's imagine a reference system in which we have stereo speakers. Later on we can talk about surrounds but for now let's keep simple. Our stereo reference system has 3 channels left (lo, mid and hi) and 3 for right. Let's assume for now that these 6 channels are delivered from Linux BruteFIR to the soundcard through a usb interface. Correct?
Is there any chance that these 6 channels can lose perfect synchrony with each other somewhere in the soundcard/dac chain?
Does anyone know whether BruteFIR algorithms for crossover filtering are capable of lossless volume control? It seems like this should be a no-brainer if we have original 16 bit information being upsampled to 24 bits delivered to the soundcard. Those extra 8 bits provide 48dB of lossless attenuation right? I'm just trying to be logical, but don't really understand this stuff yet. More reading required.
-Robert
I'm jumping into this thread late, as I haven't had much 'forum time' lately. I've been poking/plodding along the PC-based multichannel DSP/xover/room correction path for quite a while, so here are some thoughts.
- for anything that has a DIY component to it, SPDIF is still likely to be the best/easiest way to go. Anything else will require a fairly high degree of custom engineering, and doing that with *high quality* will be expensive and time consuming. There's simply so much DIY work around spdif out there that it makes the most sense.
- ADAT is attractive, but not for DIY. The alesis chips are limited to 48k, and if you use word-splitting and other ways to push 96kHz+ data down ADAT you're probably going to be limited to pro converters. GOOD adat converters are expensive.
- USB - you have to be joking??!?! Unless you go completely async and clock the output completely independent of the USB clocks, this will probably be worse than spdif. The existing USB->IIS chips appear to derive the 12.xx MHz clock from the 11.xx USB clock (as they would have to in order to ensure they don't suffer from stall/overrun) - expecting this to be lower-jitter than a well implemented SPDIF solution is optimistic at best. A solution that simply did bulk transfer over USB2 treating it like a network might be an interesting approach but
a) you'lll end up building something that looks a lot like a computer to translate/buffer the data out to the DAC
b) since this is no longer USB audio, you have to write custom drivers on the PC
c) running ethernet to a VIA Epia run from a good DC source with a LynxTwo card will be cheaper, easier, quicker, and unless you're an analog circuit design whiz, better. (you can actually probably do this with jack right now using jack.udp....)
- the need to isolate signals from the 'noisy' pc environment is vastly overblown. Lynx and RME have cards that are measurably as good as almost anything out there - analog noise floors that are -110+ dB down. Plus, any good card is going to xformer-couple the spdif outputs, and if you xformer couple the inputs on the DAC you simply don't have to worry about noise leakage. Acoustic noise is the big problem with PC's IMHO.
IMHO the most practical (ie can be done NOW without ground breaking design work) approach is to create a DAC which incorporates a high-quality clock source, and (in addition to feeding the DAC chips) send the clock OUT over spdif. Use this spdif signal as the master clock for your soundcard, and then use the spdif output from the PC as your signal. This clock sync will ensure that there is no drift-over-time between the source and DAC, although the recovered I2S clocks from the spdif receivers will have unknown phase relationships with the original master - I *think* this is fine based on my experience so far.
The Lynx AES16 is the obvious card to use, giving 8 or 16 channels (4 or 8 pairs) of AES3 output - if you use the SPDIF adapters I think you're limited to 4 pairs/8 channels. The big downside is that it doesn't appear to work under Linux at the moment. 4Front has just released drivers for the other Lynx cards, so there's hope that the AES16 might be supported soon.
My personal plan is to continue using my Delta 1010 with BruteFIR/Jack until I get the results I'm looking for (I *THINK* I'm pretty close...), and then take stock of the situation. 4x spdif out to a stack of the Panasonic digital receivers for my 3.5 way system is looking pretty attractive.
- for anything that has a DIY component to it, SPDIF is still likely to be the best/easiest way to go. Anything else will require a fairly high degree of custom engineering, and doing that with *high quality* will be expensive and time consuming. There's simply so much DIY work around spdif out there that it makes the most sense.
- ADAT is attractive, but not for DIY. The alesis chips are limited to 48k, and if you use word-splitting and other ways to push 96kHz+ data down ADAT you're probably going to be limited to pro converters. GOOD adat converters are expensive.
- USB - you have to be joking??!?! Unless you go completely async and clock the output completely independent of the USB clocks, this will probably be worse than spdif. The existing USB->IIS chips appear to derive the 12.xx MHz clock from the 11.xx USB clock (as they would have to in order to ensure they don't suffer from stall/overrun) - expecting this to be lower-jitter than a well implemented SPDIF solution is optimistic at best. A solution that simply did bulk transfer over USB2 treating it like a network might be an interesting approach but
a) you'lll end up building something that looks a lot like a computer to translate/buffer the data out to the DAC
b) since this is no longer USB audio, you have to write custom drivers on the PC
c) running ethernet to a VIA Epia run from a good DC source with a LynxTwo card will be cheaper, easier, quicker, and unless you're an analog circuit design whiz, better. (you can actually probably do this with jack right now using jack.udp....)
- the need to isolate signals from the 'noisy' pc environment is vastly overblown. Lynx and RME have cards that are measurably as good as almost anything out there - analog noise floors that are -110+ dB down. Plus, any good card is going to xformer-couple the spdif outputs, and if you xformer couple the inputs on the DAC you simply don't have to worry about noise leakage. Acoustic noise is the big problem with PC's IMHO.
IMHO the most practical (ie can be done NOW without ground breaking design work) approach is to create a DAC which incorporates a high-quality clock source, and (in addition to feeding the DAC chips) send the clock OUT over spdif. Use this spdif signal as the master clock for your soundcard, and then use the spdif output from the PC as your signal. This clock sync will ensure that there is no drift-over-time between the source and DAC, although the recovered I2S clocks from the spdif receivers will have unknown phase relationships with the original master - I *think* this is fine based on my experience so far.
The Lynx AES16 is the obvious card to use, giving 8 or 16 channels (4 or 8 pairs) of AES3 output - if you use the SPDIF adapters I think you're limited to 4 pairs/8 channels. The big downside is that it doesn't appear to work under Linux at the moment. 4Front has just released drivers for the other Lynx cards, so there's hope that the AES16 might be supported soon.
My personal plan is to continue using my Delta 1010 with BruteFIR/Jack until I get the results I'm looking for (I *THINK* I'm pretty close...), and then take stock of the situation. 4x spdif out to a stack of the Panasonic digital receivers for my 3.5 way system is looking pretty attractive.
How many out there are learning this stuff?
I love this discussion and am trying to consider everyone's point of view. Not always possible to reconcile due to different assumptions and levels of knowledge. My own level of knowledge is obviously much lower than many of you and I hope my education process, which I feel this thread is doing partly, is helping others out there.
Are there others out there who are learning from this?
dwk123 - many good points, but regarding your astonishment at usb interfacing, yes we have been thinking of totally asynchronous, not wanting any timing info at all over usb. Regarding your point about pc emi noise, I'm with you there, or at least don't think it's a serious obstacle. I also agree with you that noise has been solved by soundcard designers, however we disagree that these soundcards, when slaved to a clock of negligible jitter will deliver the world's best audio.
We may not understand how to define "world's best" audio quality, because there are different preferences for what sounds best, but we know commercial soundcards are using opamps and passive components and power supplies at least in the analog sections that can be improved by anyone's standard. Also, it seems to me that a "world's best" system would need to have options for customizing the sound such as tube i/v stages and so on. So unless someone can be very convincing, I'm assuming there is no Lynx or RME card that by itself is good enough. Sure, they are good enough for beautiful sounding music and no normal person really needs better than that, I agree. However, we're talking about degrees of abnormality here and we want to be out there in the fringes past 3 standard deviations.
With that said, let me point out one more time. We still have NO DATA on the result of jitter reduction efforts on soundcards and soundcard/dac combo's beyond the 2000 review of the RME card in Stereophile posted earlier. I'm looking for real serious data. It isn't a sign of high intelligence to build a better mousetrap without a way of proving it's better. We have no objective standard atm.
-Robert
I love this discussion and am trying to consider everyone's point of view. Not always possible to reconcile due to different assumptions and levels of knowledge. My own level of knowledge is obviously much lower than many of you and I hope my education process, which I feel this thread is doing partly, is helping others out there.
Are there others out there who are learning from this?
dwk123 - many good points, but regarding your astonishment at usb interfacing, yes we have been thinking of totally asynchronous, not wanting any timing info at all over usb. Regarding your point about pc emi noise, I'm with you there, or at least don't think it's a serious obstacle. I also agree with you that noise has been solved by soundcard designers, however we disagree that these soundcards, when slaved to a clock of negligible jitter will deliver the world's best audio.
We may not understand how to define "world's best" audio quality, because there are different preferences for what sounds best, but we know commercial soundcards are using opamps and passive components and power supplies at least in the analog sections that can be improved by anyone's standard. Also, it seems to me that a "world's best" system would need to have options for customizing the sound such as tube i/v stages and so on. So unless someone can be very convincing, I'm assuming there is no Lynx or RME card that by itself is good enough. Sure, they are good enough for beautiful sounding music and no normal person really needs better than that, I agree. However, we're talking about degrees of abnormality here and we want to be out there in the fringes past 3 standard deviations.
With that said, let me point out one more time. We still have NO DATA on the result of jitter reduction efforts on soundcards and soundcard/dac combo's beyond the 2000 review of the RME card in Stereophile posted earlier. I'm looking for real serious data. It isn't a sign of high intelligence to build a better mousetrap without a way of proving it's better. We have no objective standard atm.
-Robert
Re: Explanation
AFAIK rfbrw isnt talking about building a PCI card with a powerful DSP... he is talking about an external from the PC DSP.
No.
See this is why i was left wondering why you guys are talking about USB.
There would be no way to make sure that the audio is sycnronised perfectly out of the 3 USB recievers... and you cant just setup a master clock of similar to try and fix it.
SPDIF/I2S is the only way.
With USB Yes... as above.
Using a single soundcard, no... they will be perfect.
Using multiple soundcards, no.. they will be perfect if using a master clock.
There is no such thing.
You are always going to loose resolution by doing digital volume control... there is no way around that.
AFAIK rfbrw isnt talking about building a PCI card with a powerful DSP... he is talking about an external from the PC DSP.
No.
See this is why i was left wondering why you guys are talking about USB.
There would be no way to make sure that the audio is sycnronised perfectly out of the 3 USB recievers... and you cant just setup a master clock of similar to try and fix it.
SPDIF/I2S is the only way.
With USB Yes... as above.
Using a single soundcard, no... they will be perfect.
Using multiple soundcards, no.. they will be perfect if using a master clock.
There is no such thing.
You are always going to loose resolution by doing digital volume control... there is no way around that.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.