Re: Re: Re: i2s
It seems that the Envy 24ht might be a significant consideration. (How long until 24 bits are insufficient?
) The same chip is incorporated into ESI interfaces of any age. Even for the discontinued equipment the most recent driver supports Vista 32 and 64 and was updated only a few months ago.
http://download.esi-audio.com/?w=esi&p=30&g=1&l=en
Regarding the ESI card, there are no crystals on the rack-mount board so the only clock seems to be on the PCI card. I'm not an engineer, but I think an external clock may be generally desirable because even with the transceiver chips I observed that the length of the cable to the DACs affects sound quality. The stock cable is 3 meters. I replaced that with one that is ~80cm and improved SQ noticably (from the stock AKM DACs). I have not compared cables now that I have stuffed 3 TP Opus DACs into the little rack box. There is no space for ASRCs so I will live with whatever jitter exists.
One wonders what is the limit of interface jitter that the new ES9018 can ignore? It seems like a very different beast.
Regards,
Frank in Mpls.
Telstar said:
It seems that the Envy 24ht might be a significant consideration. (How long until 24 bits are insufficient?
) The same chip is incorporated into ESI interfaces of any age. Even for the discontinued equipment the most recent driver supports Vista 32 and 64 and was updated only a few months ago.http://download.esi-audio.com/?w=esi&p=30&g=1&l=en
Regarding the ESI card, there are no crystals on the rack-mount board so the only clock seems to be on the PCI card. I'm not an engineer, but I think an external clock may be generally desirable because even with the transceiver chips I observed that the length of the cable to the DACs affects sound quality. The stock cable is 3 meters. I replaced that with one that is ~80cm and improved SQ noticably (from the stock AKM DACs). I have not compared cables now that I have stuffed 3 TP Opus DACs into the little rack box. There is no space for ASRCs so I will live with whatever jitter exists.
One wonders what is the limit of interface jitter that the new ES9018 can ignore? It seems like a very different beast.
Regards,
Frank in Mpls.
Re: Re: Re: Re: i2s
24 "real" bits should be enough forever, unless we want a digital volume control*, but I dont care for this.
Some products are not supported in vista but others are.
This concerns me a bit. Are you talking about a rca cable using the AKM dacs in their cards or something else?
The ESS is a different beast for jitter. With that solution (that most people will adopt especially for cost reasons), an ultra-low jitter master clock is not needed.
For my project, which is based on several pcm1704, it is and I think I have found something suitable.
[* the ESS SAbre has 44 bits for digital volume control to be done in hardware, so for that solution is also not a problem]
francolargo said:
It seems that the Envy 24ht might be a significant consideration. (How long until 24 bits are insufficient?
24 "real" bits should be enough forever, unless we want a digital volume control*, but I dont care for this.
Some products are not supported in vista but others are.
This concerns me a bit. Are you talking about a rca cable using the AKM dacs in their cards or something else?
The ESS is a different beast for jitter. With that solution (that most people will adopt especially for cost reasons), an ultra-low jitter master clock is not needed.
For my project, which is based on several pcm1704, it is and I think I have found something suitable.
[* the ESS SAbre has 44 bits for digital volume control to be done in hardware, so for that solution is also not a problem]
Re: Re: Re: Re: Re: i2s
The cable from the PCI card to the rack box containing the ADCs and DACs, etc. is a standard DB25M/M cable. Similar to this:
http://www.cablestogo.com/product.asp?cat_id=917&sku=02664
Most of the stock 3 meter cable sat coiled on the floor. Before making any other mods, I replaced it with a shorter (and better?) cable from a dead Zip drive.
IIRC, 5 of the 25 wires in the cable are unused. The PCI card has input pins for an external master clock and this is supported in software. Thus, it may not be difficult to re-clock the system from an external source through the DB25/f connector on the back plate of the PCI card. Remember also that the sample rate is selectable in software and goes as high as 192kHz. However, changing the DAC requires that it be programmed independently in coordination with the driver software.
Back to the "from the ground up" proposition for this thread, methinks that the controller chip of choice plus the software to run it are central issues in this chain of information. What would produce the highest quality source? Isn't the VIA Envy 24ht getting old and isn't there anything significantly better? Farther along, can't you engineers just 'use a bigger hammer' as it were to improve transmission and 'fidelity' of the original I2S signal ???
All the best!
Frank in Mpls.
Telstar said:
The cable from the PCI card to the rack box containing the ADCs and DACs, etc. is a standard DB25M/M cable. Similar to this:
http://www.cablestogo.com/product.asp?cat_id=917&sku=02664
Most of the stock 3 meter cable sat coiled on the floor. Before making any other mods, I replaced it with a shorter (and better?) cable from a dead Zip drive.
IIRC, 5 of the 25 wires in the cable are unused. The PCI card has input pins for an external master clock and this is supported in software. Thus, it may not be difficult to re-clock the system from an external source through the DB25/f connector on the back plate of the PCI card. Remember also that the sample rate is selectable in software and goes as high as 192kHz. However, changing the DAC requires that it be programmed independently in coordination with the driver software.
Back to the "from the ground up" proposition for this thread, methinks that the controller chip of choice plus the software to run it are central issues in this chain of information. What would produce the highest quality source? Isn't the VIA Envy 24ht getting old and isn't there anything significantly better? Farther along, can't you engineers just 'use a bigger hammer' as it were to improve transmission and 'fidelity' of the original I2S signal ???
All the best!
Frank in Mpls.
Re: Re: Re: Re: Re: Re: i2s
I am afraid Envy24HT was the peak in high-fidelity sound card technology. It does its job - moving data from memory to I2S via DMA, clocked by separate crystal-based clocks for 44.1kHz and 48kHz families, plus simple mixer and integrated SPDIF transmitter. Complete documentation freely available, without signing an NDA. Reasonable range of supported latencies. No DSP, effects, synthesis, PLL'd clocks to spare the second crystal.
All new generation soundchips are made to save money on BOM, not to provide top sound quality. The only PCIe card with double crystals I have been able to find so far is the aforementioned http://www.esi-audio.com/products/esp1010e/ which I suspect somehow runs on the Envy24 chip too (perhaps some custom-made variant with PCIe support) - check out the board picture.
francolargo said:
Back to the "from the ground up" proposition for this thread, methinks that the controller chip of choice plus the software to run it are central issues in this chain of information. What would produce the highest quality source? Isn't the VIA Envy 24ht getting old and isn't there anything significantly better? Farther along, can't you engineers just 'use a bigger hammer' as it were to improve transmission and 'fidelity' of the original I2S signal ???
I am afraid Envy24HT was the peak in high-fidelity sound card technology. It does its job - moving data from memory to I2S via DMA, clocked by separate crystal-based clocks for 44.1kHz and 48kHz families, plus simple mixer and integrated SPDIF transmitter. Complete documentation freely available, without signing an NDA. Reasonable range of supported latencies. No DSP, effects, synthesis, PLL'd clocks to spare the second crystal.
All new generation soundchips are made to save money on BOM, not to provide top sound quality. The only PCIe card with double crystals I have been able to find so far is the aforementioned http://www.esi-audio.com/products/esp1010e/ which I suspect somehow runs on the Envy24 chip too (perhaps some custom-made variant with PCIe support) - check out the board picture.
Re: i2s
Interesting information. Thanks!
I believe you are correct. In the picture of the PCI board I believe the Envy 24 chip has the ESI logo on the bottom right of the board. I also see that there are what look like 10 channel transceiver chips up near the main connector. Also, this main connector is changed from the older version with which I'm familiar (3 vs. 2 rows of pins).
The discussion I would hope for here is clearly not in my league
, so the last thing I'll mention here about the ESI stuff is that mods within the rack box are not the simplest. The rack boxes are slim and have one large circuit board incorporating board-mount interfaces towards the front and rear. Therefore, adding significant circuitry requires either a compact board hanging downwards from the top of the case (PIA!) or a new larger case with quite a few external connectors to re-configure... I opted for simply replacing DACs and am very pleased with the bang/buck. I used DACs that needed no additional i/v conversion because there is no room for added boards...
Best wishes to all,
Frank in Mpls.
phofman said:
Interesting information. Thanks!
I believe you are correct. In the picture of the PCI board I believe the Envy 24 chip has the ESI logo on the bottom right of the board. I also see that there are what look like 10 channel transceiver chips up near the main connector. Also, this main connector is changed from the older version with which I'm familiar (3 vs. 2 rows of pins).
The discussion I would hope for here is clearly not in my league
, so the last thing I'll mention here about the ESI stuff is that mods within the rack box are not the simplest. The rack boxes are slim and have one large circuit board incorporating board-mount interfaces towards the front and rear. Therefore, adding significant circuitry requires either a compact board hanging downwards from the top of the case (PIA!) or a new larger case with quite a few external connectors to re-configure... I opted for simply replacing DACs and am very pleased with the bang/buck. I used DACs that needed no additional i/v conversion because there is no room for added boards...Best wishes to all,
Frank in Mpls.
I've been looking at ESI and RME products, it is interesting to see that both manufacturers share a common trend, which is to build a small PCI or PCI-Express board to put in the PC, which has several FireWire sockets, which do not use the FireWire protocol, but a proprietary one, presumably using some form of serial LVDS communication. Then they sell addons ("breakout boards") which talk to the PC using this protocol.
So it seems that high-end pro audio gear makers are perfectly aware that putting analog stuff inside a PC is wrong wrt noise (and also unapplicable to laptops) and it seems they are searching for a better way, which is exactly the point of this thread...
When I said earlier that FireWire is dead, this is exactly it : both those manufacturers developed their own protocol to solve USB / FireWire shortcomings.
FireWire is too complex, and USB is too simple...
However for living room use where larger latencies are acceptable, I believe USB will be perfectly OK for the job, and it is not going away anytime soon. This is why I chose it.
It is a pity that the protocols are closed. There is the MADI protocol, though, which looks interesting. Does anyone have a link on the PDF with the specs, that the AES wants to sell for $30 ?
So it seems that high-end pro audio gear makers are perfectly aware that putting analog stuff inside a PC is wrong wrt noise (and also unapplicable to laptops) and it seems they are searching for a better way, which is exactly the point of this thread...
When I said earlier that FireWire is dead, this is exactly it : both those manufacturers developed their own protocol to solve USB / FireWire shortcomings.
FireWire is too complex, and USB is too simple...
However for living room use where larger latencies are acceptable, I believe USB will be perfectly OK for the job, and it is not going away anytime soon. This is why I chose it.
It is a pity that the protocols are closed. There is the MADI protocol, though, which looks interesting. Does anyone have a link on the PDF with the specs, that the AES wants to sell for $30 ?
Re: Re: Re: Re: Re: Re: Re: i2s
I think this would be my best bet. I see no reason why not to use the envy24ht just for digital signal transport through i2s.
The lack of shielding *should* not be an issue, and pci-e is to be preferred since possess greater bandiwth and it is future-proof. To the one preaching the death of firewire, pci will die sooner.
About crystals, i do indeed plan to run two master clocks in my dac, one for 44.1k and one for 48k and multiplies.
More importantly, there is a pin for wordclock input?
About software, how is the sample rate selected? I know that RME drivers are transparent, in the way that they do not change arbitrarily the sample rate of the track playing.
phofman said:
I think this would be my best bet. I see no reason why not to use the envy24ht just for digital signal transport through i2s.
The lack of shielding *should* not be an issue, and pci-e is to be preferred since possess greater bandiwth and it is future-proof. To the one preaching the death of firewire, pci will die sooner.
About crystals, i do indeed plan to run two master clocks in my dac, one for 44.1k and one for 48k and multiplies.
More importantly, there is a pin for wordclock input?
About software, how is the sample rate selected? I know that RME drivers are transparent, in the way that they do not change arbitrarily the sample rate of the track playing.
peufeu,
RME did not abandon firewire. They made a custom firewire 800 chip for their FF800. The MADI line is older. But the MADI protocol is very good indeed. I do not think it would be easy to find a receiver to use in a diy DAC, like it can be done for i2s.
About i2s, I forgot to post previously what I plan to use:
http://www.coreworks-sa.com/index.p...er=CWda16&ipcore_id=11&category=AudioWorks%99
RME did not abandon firewire. They made a custom firewire 800 chip for their FF800. The MADI line is older. But the MADI protocol is very good indeed. I do not think it would be easy to find a receiver to use in a diy DAC, like it can be done for i2s.
About i2s, I forgot to post previously what I plan to use:
http://www.coreworks-sa.com/index.p...er=CWda16&ipcore_id=11&category=AudioWorks%99
Re: Re: Re: Re: Re: Re: Re: Re: i2s
Sorry if I was misleading. I cannot speak to the 1010e - the photos of which don't show obvious connectors. It probably has some kind of sync capability. the manuals are available for download.
If you look at the older board (photo attached to post 119), there are two black plastic connectors in the upper right corner of the board. One is sync-in and one is sync-out - used when multiple cards are installed.
For the older board, the drivers are straightforward. A small screen containing I/O and level controls has a sample rate section. One can choose 'auto', in which case it detects the rate of the source and passes it on. In manual mode you can output anything from 8kHz up to 192kHz in predictable increments of 44.1 or 48. In either mode the output frequency is displayed. Again, the manual is available for download from the ESI site.
Question to wise readers regarding 'jitter' and re-sampling: Without resampling *after* Envy 24ht output, would you expect better DAC performance from I2S at 'native' frequency (e.g. 44.1 kHz recordings) or would you expect better performance by upsampling in software prior to the Envy 24ht input? [If that is threadjacking, please feel free to reply via forum e-mail.]
Frank in Mpls.
Telstar said:
Sorry if I was misleading. I cannot speak to the 1010e - the photos of which don't show obvious connectors. It probably has some kind of sync capability. the manuals are available for download.
If you look at the older board (photo attached to post 119), there are two black plastic connectors in the upper right corner of the board. One is sync-in and one is sync-out - used when multiple cards are installed.
For the older board, the drivers are straightforward. A small screen containing I/O and level controls has a sample rate section. One can choose 'auto', in which case it detects the rate of the source and passes it on. In manual mode you can output anything from 8kHz up to 192kHz in predictable increments of 44.1 or 48. In either mode the output frequency is displayed. Again, the manual is available for download from the ESI site.
Question to wise readers regarding 'jitter' and re-sampling: Without resampling *after* Envy 24ht output, would you expect better DAC performance from I2S at 'native' frequency (e.g. 44.1 kHz recordings) or would you expect better performance by upsampling in software prior to the Envy 24ht input? [If that is threadjacking, please feel free to reply via forum e-mail.]
Frank in Mpls.
i2s
OK, perfect. I assume the other boards have similar drivers (they must call it unified for a reason).
My opinion is that higher sampling rates are more sensitive to jitter, but less sensitive to noise.
About performance, and here i mean sound quality, all depends on the way that the oversampling is done. I do not like the sound of sigma-delta converters.
About resampling, my opinion is that a computer is ALWAYS a better choice (therefore before the envy24ht output), with the current technology available in both PCs and electronic devices.
francolargo said:
OK, perfect. I assume the other boards have similar drivers (they must call it unified for a reason).
francolargo said:
My opinion is that higher sampling rates are more sensitive to jitter, but less sensitive to noise.
About performance, and here i mean sound quality, all depends on the way that the oversampling is done. I do not like the sound of sigma-delta converters.
About resampling, my opinion is that a computer is ALWAYS a better choice (therefore before the envy24ht output), with the current technology available in both PCs and electronic devices.
> About performance, and here i mean sound quality, all > depends on the way that the oversampling is done.
Definitely... Well, I mean if you make an apple to apple comparison with the same DAC etc :
If oversampling (say, with sox) from 44.1 to 192k sounds better (on the exact same hardware) it can mean various things :
- maybe the filtering you use is better that the one in the chip (roundoff errors, precision, response, etc)
- maybe there is a PLL based clock generator that produces a lot more jitter on 44.1k based rates than on 48k based rates (in this case try 176.4k instead of 192 to check)
- maybe shutting down the resampler in the DAC makes the on-chip noise and jitter lower
Lots of possible causes, but they all end up to the same conclusion...
> My opinion is that higher sampling rates are more sensitive to jitter
In theory, not necessarily, since jitter effects are proportional to the difference between two consecutive samples, which is likely to be inversely proportional to the sample rate.
> About resampling, my opinion is that a computer is
> ALWAYS a better choice
I'd not say a computer, I'd say a general-purpose device like a computer, a FPGA or a DSP, the key point here being able to use your own algorithm with a good precision, response length and dithering. I think FPGA/DSP would use less power, hence easier to do a fanless PC.
About your CoreWorks I²S core : you plan to use a FPGA ? Implementing I²S is quite straightforward, a few hours of work, so I'd not consider buying a core for this...
Definitely... Well, I mean if you make an apple to apple comparison with the same DAC etc :
If oversampling (say, with sox) from 44.1 to 192k sounds better (on the exact same hardware) it can mean various things :
- maybe the filtering you use is better that the one in the chip (roundoff errors, precision, response, etc)
- maybe there is a PLL based clock generator that produces a lot more jitter on 44.1k based rates than on 48k based rates (in this case try 176.4k instead of 192 to check)
- maybe shutting down the resampler in the DAC makes the on-chip noise and jitter lower
Lots of possible causes, but they all end up to the same conclusion...
> My opinion is that higher sampling rates are more sensitive to jitter
In theory, not necessarily, since jitter effects are proportional to the difference between two consecutive samples, which is likely to be inversely proportional to the sample rate.
> About resampling, my opinion is that a computer is
> ALWAYS a better choice
I'd not say a computer, I'd say a general-purpose device like a computer, a FPGA or a DSP, the key point here being able to use your own algorithm with a good precision, response length and dithering. I think FPGA/DSP would use less power, hence easier to do a fanless PC.
About your CoreWorks I²S core : you plan to use a FPGA ? Implementing I²S is quite straightforward, a few hours of work, so I'd not consider buying a core for this...
Re: i2s
I have appreciated the comments on this question and now have some evidence from my own system: ESI PCI interface card to rack-mount external DACs - I have upgraded those DACs to TPA Opus WM8741 w/ separate power supply; everything else is 'stock'.
Of course, N=1 but...
As predicted, the best performance for lossless redbook sources is obtained by upsampling in software to 176.4kHz. For those tracks, NOS operation is still very good. However, the reverse is true for MPEG-4 files. Sound quality of MPEG-4 sources is clearly superior at 44.1kHz compared to 176.4kHz. When MPEG-4 files are oversampled the sound is unacceptably "hollow". Thus, I'm setting up to easily switch the sample rate and digital filters of the DACs to accomodate the format and properties of the sources. This can easily be done manually in hardware mode because the output sample rate is always visible in the hardware driver control window.
[Why MPEG-4? I have a large collection of digitized 78's.]
Regards,
Frank in Mpls.
francolargo said:
I have appreciated the comments on this question and now have some evidence from my own system: ESI PCI interface card to rack-mount external DACs - I have upgraded those DACs to TPA Opus WM8741 w/ separate power supply; everything else is 'stock'.
Of course, N=1
but...As predicted, the best performance for lossless redbook sources is obtained by upsampling in software to 176.4kHz. For those tracks, NOS operation is still very good. However, the reverse is true for MPEG-4 files. Sound quality of MPEG-4 sources is clearly superior at 44.1kHz compared to 176.4kHz. When MPEG-4 files are oversampled the sound is unacceptably "hollow". Thus, I'm setting up to easily switch the sample rate and digital filters of the DACs to accomodate the format and properties of the sources. This can easily be done manually in hardware mode because the output sample rate is always visible in the hardware driver control window.
[Why MPEG-4?
I have a large collection of digitized 78's.]Regards,
Frank in Mpls.
Re: Re: i2s
Does it mean, that 44.1 kHz MPEG-4, converted to wav (a.wav), upsampled x4 to 176.4kHz, sounds worse than the 44.1kHz a.wav, while regular 44.1kHz b.wav upsampled by the same algorhithm to 176.4kHz sounds better than the original 44.1kHz b.wav?
francolargo said:However, the reverse is true for MPEG-4 files. Sound quality of MPEG-4 sources is clearly superior at 44.1kHz compared to 176.4kHz. When MPEG-4 files are oversampled the sound is unacceptably "hollow".
[Why MPEG-4?
Does it mean, that 44.1 kHz MPEG-4, converted to wav (a.wav), upsampled x4 to 176.4kHz, sounds worse than the 44.1kHz a.wav, while regular 44.1kHz b.wav upsampled by the same algorhithm to 176.4kHz sounds better than the original 44.1kHz b.wav?
Re: Re: Re: i2s
Yes, in the above axample a.wav and b.wav sound very different.
I can not speak to the mechanisms of MPEG-4 decoding, but remember the following:
1) the file producing a.wav has a data 'density' of (in my system) 256 kbits/sec. I suppose I could use variable bit rate but hard disc space is so ridiculously cheap these days...
2) the file producing b.wav has a data 'density' that is variable but exceeds 1.4 mbits/sec. In other words, b.wav contains about 6 times as much information as a.wav even though the frequencies of both are the same.
It may be that other audio compression/decompression schemes would not produce as much disparity between oversampled and non-oversampled presentation to the DAC. I'd like to know more about that.
Concerning the Wolfson chip here is a possible (and naive!) explanation. This difference in SQ might suggest that there is some kind of interpolation whereby redundant data from oversampling is smoothed. Low bit-rate data at 44.1 kHz might not be 'stretched' beyond the algorithm's 'window', whereas when one upsamples that same amount of data to 176.4kHz, the same interpolation function might produce artifacts because there are four times as many redundant data points. ...all speculation, of course!!!
Somebody around here probably knows what actually happens on the chip. Whether the DAC chip or the MPEG decoder is responsible, in terms of SQ, the difference between a.wav and b.wav is not subtle!
Thanks for your insights.
Frank in Mpls.
phofman said:
Yes, in the above axample a.wav and b.wav sound very different.
I can not speak to the mechanisms of MPEG-4 decoding, but remember the following:
1) the file producing a.wav has a data 'density' of (in my system) 256 kbits/sec. I suppose I could use variable bit rate but hard disc space is so ridiculously cheap these days...
2) the file producing b.wav has a data 'density' that is variable but exceeds 1.4 mbits/sec. In other words, b.wav contains about 6 times as much information as a.wav even though the frequencies of both are the same.
It may be that other audio compression/decompression schemes would not produce as much disparity between oversampled and non-oversampled presentation to the DAC. I'd like to know more about that.
Concerning the Wolfson chip here is a possible (and naive!) explanation. This difference in SQ might suggest that there is some kind of interpolation whereby redundant data from oversampling is smoothed. Low bit-rate data at 44.1 kHz might not be 'stretched' beyond the algorithm's 'window', whereas when one upsamples that same amount of data to 176.4kHz, the same interpolation function might produce artifacts because there are four times as many redundant data points. ...all speculation, of course!!!
Somebody around here probably knows what actually happens on the chip. Whether the DAC chip or the MPEG decoder is responsible, in terms of SQ, the difference between a.wav and b.wav is not subtle!
Thanks for your insights.
Frank in Mpls.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.