Hi Tolu,
http://www.focuser.com/atm/anodize/anodize.html
Be sure to use a clean container (heat-resistant glass) and distilled water for sealing.
http://www.focuser.com/atm/anodize/anodize.html
Be sure to use a clean container (heat-resistant glass) and distilled water for sealing.
For your reference.
I posted a report of Chiaki's prototype of SD memory card player capable of playing up to 24bit 192kHz WAV files.
http://www.diyaudio.com/forums/showthread.php?postid=1878367#post1878367
As it has no built in DAC and offers only I2S and S/PDIF outputs, I think it has different purpose with EC's charmful standalone player.
Bunpei
I posted a report of Chiaki's prototype of SD memory card player capable of playing up to 24bit 192kHz WAV files.
http://www.diyaudio.com/forums/showthread.php?postid=1878367#post1878367
As it has no built in DAC and offers only I2S and S/PDIF outputs, I think it has different purpose with EC's charmful standalone player.
Bunpei
soundcheck said:
Chiaki's scheme for a high-precision clocking is explained in the following post.
http://www.diyaudio.com/forums/showthread.php?postid=1879703#post1879703
However, we have measured neither phase shift noise nor Allan Variance of I2S signals yet. Therefore, we have no objective evidence for a "low jitter" profile of this equipment so far.
I'd like to know how "Isochronism" of I2S signals is ensured in the case of dsPIC33 I2S interfaces.
Bunpei
Could ec-designs publish his jitter results? - I know he is designing with low jitter in mind but jitter is such a slippery animal to tame that only by measurement can you show you have achieved a reasonably low value!
Anyway, it would be of interest to see how the figure compares with values from soundcards/CD/DVD transports?
Anyway, it would be of interest to see how the figure compares with values from soundcards/CD/DVD transports?
Hi Bunpei,
dsPIC33 runs on an exact multiple of the 11.289600 MHz master clock (on-chip frequency multiplier) providing 40 MIPS. I2S signals are generated by dedicated configurable on-chip DCI hardware.
Timing critical I2S signal (bit clock or BCK for the TDA1543), is synchronously reclocked with the 11.2896 MHz master clock.
We use I2S, 32 bits/frame, BCK = 1.4112 MHz, WS = 44.1 KHz.
dsPIC33 runs on an exact multiple of the 11.289600 MHz master clock (on-chip frequency multiplier) providing 40 MIPS. I2S signals are generated by dedicated configurable on-chip DCI hardware.
Timing critical I2S signal (bit clock or BCK for the TDA1543), is synchronously reclocked with the 11.2896 MHz master clock.
We use I2S, 32 bits/frame, BCK = 1.4112 MHz, WS = 44.1 KHz.
Dear -ecdesign-,
Thank you very much for your detailed explanations.
In terms of hardware, I believe that your system has achieved minimum jitters because your approach is somewhat similar to ours and I can imagine the good sound of your system.
Does the provider of dsPIC33 show any special description of that dedicated hardware in its datasheet or web page materials?
Does your notation, "11.289600 MHz" mean that your specially made oscillator has an accuracy of order of 1Hz (namely, less than 0.1 ppm ) ?
On the other hand, in terms of software, can you confirm that I2S output FIFO buffer has not suffered any data shortage even while MPU is very busy for handling SD memory read or human interface related events? I have to confess that we are facing a certain difficulty on this type of confirmation.
Bunpei
Thank you very much for your detailed explanations.
In terms of hardware, I believe that your system has achieved minimum jitters because your approach is somewhat similar to ours and I can imagine the good sound of your system.
-ecdesigns- said:
Does the provider of dsPIC33 show any special description of that dedicated hardware in its datasheet or web page materials?
Does your notation, "11.289600 MHz" mean that your specially made oscillator has an accuracy of order of 1Hz (namely, less than 0.1 ppm ) ?
On the other hand, in terms of software, can you confirm that I2S output FIFO buffer has not suffered any data shortage even while MPU is very busy for handling SD memory read or human interface related events? I have to confess that we are facing a certain difficulty on this type of confirmation.
Bunpei
Hi Bunpei,
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en024673
Yes I get that readout on the frequency counter and it's pretty stable. I use a discrete 3-crystal oscillator, the crystals are matched high-Q types.
It needs to run on a low noise constant power regulator. The oscillator draws approx. 1mA @ 4V (4mW) when driving 2 loads. [picture is in post #84]
Like I mentioned, the dsPIC33FJ128 has dedicated on-chip hardware like UART, DMA, and DCI module for these tasks. This way processor load stays very low. It's basically configuring and initializing required hardware modules, then let the hardware do all the work.
We took measures to maximize the margin for SD-card latency, so a buffer under-run is extremely rare when using SD/SDHC cards with specified speed rating (2 or higher).
The human interface consists of 6 keys that connect to the main processor (dsPIC33FJ128).
Display is driven by a second processor that communicates with the main controller through RS232.
Remote control functions are also handled through RS232 interface.
The SD-player uses heavily modified Microchip FAT32 libraries, it enables accessing file systems and offers SD/SDHC card support up to 32GB.
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en024673
Yes I get that readout on the frequency counter and it's pretty stable. I use a discrete 3-crystal oscillator, the crystals are matched high-Q types.
It needs to run on a low noise constant power regulator. The oscillator draws approx. 1mA @ 4V (4mW) when driving 2 loads. [picture is in post #84]
Like I mentioned, the dsPIC33FJ128 has dedicated on-chip hardware like UART, DMA, and DCI module for these tasks. This way processor load stays very low. It's basically configuring and initializing required hardware modules, then let the hardware do all the work.
We took measures to maximize the margin for SD-card latency, so a buffer under-run is extremely rare when using SD/SDHC cards with specified speed rating (2 or higher).
The human interface consists of 6 keys that connect to the main processor (dsPIC33FJ128).
Display is driven by a second processor that communicates with the main controller through RS232.
Remote control functions are also handled through RS232 interface.
The SD-player uses heavily modified Microchip FAT32 libraries, it enables accessing file systems and offers SD/SDHC card support up to 32GB.
Hi jkeny,
Here is an article of Stereophile describing the audible effects of jitter
http://www.stereophile.com/features/368/index9.html
Jitter can be split in two types:
Random jitter (affecting SNR)
Periodic jitter (affects distortion)
Jitter amplitude only specifies part of the jitter properties, the value as such tells very little about the impact on sound quality. Device with 500ps rms jitter (mainly random jitter) can sound much better than a device with 200ps rms jitter (mainly periodic jitter).
Jitter also accumulates, each sub-circuits adds specific jitter signature.
Even when using a low jitter master clock with mainly random jitter. Power supply noise and interference induced by connected loads can affect both jitter amplitude and jitter signature.
In general, it's way easier to use an ultra low jitter digital audio source that mainly outputs random jitter spectrum, instead of attempting to reduce high periodic jitter levels generated by the source and connected interfaces.
I use a special master clock, it oscillates by means of interaction between piezoelectric effects of the 3 matched high-Q crystals and a choke for temporary energy storage. The active element (source follower) acts as impedance converter (input impedance > 10 M Ohm, output impedance < 10 Ohms). The result is very low energy consumption (approx. 4mW) while the output signal can easily drive multiple loads without requiring extra energy. This way, the effect of external power supply pollution is greatly reduced (oscillator recycles energy).
By using a low-noise constant power (80mW) regulator, master clock performance is further increased.
But during clock signal distribution, jitter accumulates (interference from connected loads), synchronous reclocker driving the DAC chip. In order to reduce these effects, the master clock was designed to maintain low jitter with connected loads. The bit clock signal from the processor is derived from a frequency multiplier (datasheet specifies ultra low jitter levels), driven by the master clock. This frequency multiplier mainly produces random jitter (PLL). This bit clock is then synchronously reclocked, so the jitter that manages to seep through is mainly random jitter.
The jitter introduced by the synchronous reclocker, and the jitter from the processor are attenuated by the dynamic jitter attenuator before feeding the clock signal to the DAC chip. This way, both low jitter amplitude, and mainly random jitter signature are obtained.
That's the theory, in practice the performance was verified by selected critical music fragments that are easily affected by slightest jitter.
I could make a jitter spectrum scan at the output of the DAC chip, using a suitable test signal, but I would need jitter measurement equipment with 10 femto seconds or better resolution.
All conventional digital audio sources, interlinks and digital audio receivers add noise, interference, and jitter signatures to the sample timing signal. This is mainly periodic jitter (worst kind). This jitter is extremely difficult to attenuate, and unless the design is absolutely perfect, jitter always finds a "back door" and pollutes the entire DAC electronics like a virus. This interference spreads though wiring, components, PCB, and wireless (EM radiation). Slaving transport or sound card helps, but it won't prevent jitter from spreading among the DAC electronics as we still require the external data signal that also contains jitter.
The problem is even worse when using external DACs. Interlink, digital audio receiver interference, and jitter are added.
The easiest way of solving this problem is to create a clean digital audio source, and integrate it with the DAC chip using I2S. That's exactly what we did with the SD-player.
How will this compare to a CD player or computer? well, it would have far lower jitter and interference levels to start with, because a lot of potential jitter and interference sources are taken out of the equation. The jitter signature can be shaped much easier, obtaining mainly random jitter.
So when the digital audio sources are constructed optimally, the SD-player concept is most likely to provide best results.
Here is an article of Stereophile describing the audible effects of jitter
http://www.stereophile.com/features/368/index9.html
Jitter can be split in two types:
Random jitter (affecting SNR)
Periodic jitter (affects distortion)
Jitter amplitude only specifies part of the jitter properties, the value as such tells very little about the impact on sound quality. Device with 500ps rms jitter (mainly random jitter) can sound much better than a device with 200ps rms jitter (mainly periodic jitter).
Jitter also accumulates, each sub-circuits adds specific jitter signature.
Even when using a low jitter master clock with mainly random jitter. Power supply noise and interference induced by connected loads can affect both jitter amplitude and jitter signature.
In general, it's way easier to use an ultra low jitter digital audio source that mainly outputs random jitter spectrum, instead of attempting to reduce high periodic jitter levels generated by the source and connected interfaces.
I use a special master clock, it oscillates by means of interaction between piezoelectric effects of the 3 matched high-Q crystals and a choke for temporary energy storage. The active element (source follower) acts as impedance converter (input impedance > 10 M Ohm, output impedance < 10 Ohms). The result is very low energy consumption (approx. 4mW) while the output signal can easily drive multiple loads without requiring extra energy. This way, the effect of external power supply pollution is greatly reduced (oscillator recycles energy).
By using a low-noise constant power (80mW) regulator, master clock performance is further increased.
But during clock signal distribution, jitter accumulates (interference from connected loads), synchronous reclocker driving the DAC chip. In order to reduce these effects, the master clock was designed to maintain low jitter with connected loads. The bit clock signal from the processor is derived from a frequency multiplier (datasheet specifies ultra low jitter levels), driven by the master clock. This frequency multiplier mainly produces random jitter (PLL). This bit clock is then synchronously reclocked, so the jitter that manages to seep through is mainly random jitter.
The jitter introduced by the synchronous reclocker, and the jitter from the processor are attenuated by the dynamic jitter attenuator before feeding the clock signal to the DAC chip. This way, both low jitter amplitude, and mainly random jitter signature are obtained.
That's the theory, in practice the performance was verified by selected critical music fragments that are easily affected by slightest jitter.
I could make a jitter spectrum scan at the output of the DAC chip, using a suitable test signal, but I would need jitter measurement equipment with 10 femto seconds or better resolution.
All conventional digital audio sources, interlinks and digital audio receivers add noise, interference, and jitter signatures to the sample timing signal. This is mainly periodic jitter (worst kind). This jitter is extremely difficult to attenuate, and unless the design is absolutely perfect, jitter always finds a "back door" and pollutes the entire DAC electronics like a virus. This interference spreads though wiring, components, PCB, and wireless (EM radiation). Slaving transport or sound card helps, but it won't prevent jitter from spreading among the DAC electronics as we still require the external data signal that also contains jitter.
The problem is even worse when using external DACs. Interlink, digital audio receiver interference, and jitter are added.
The easiest way of solving this problem is to create a clean digital audio source, and integrate it with the DAC chip using I2S. That's exactly what we did with the SD-player.
How will this compare to a CD player or computer? well, it would have far lower jitter and interference levels to start with, because a lot of potential jitter and interference sources are taken out of the equation. The jitter signature can be shaped much easier, obtaining mainly random jitter.
So when the digital audio sources are constructed optimally, the SD-player concept is most likely to provide best results.
Thanks for the comprehensive reply ec-designs - I agree with all you say about jitter but then you lose me with:
I appreciate your explanations for the lengths you have gone to in this design to minimise jitter but why not send out a unit for testing to someone with the experience & test equipment to verify these claims of such low jitter. Jitter is such a difficult issue that really only a measured value at the DAC is valid. This low jitter design is what differentiates it from other players so why not put a value on it?
I know that the spectrum & type of the jitter is really the correct way to evaluate it, as you said but if your player's jitter is so low then these can be considered low also!
I'm not sure why a 3 crystal oscillator is better than a tested low jitter clock which is well implemented with low noise PS & careful buffering?
I appreciate your explanations for the lengths you have gone to in this design to minimise jitter but why not send out a unit for testing to someone with the experience & test equipment to verify these claims of such low jitter. Jitter is such a difficult issue that really only a measured value at the DAC is valid. This low jitter design is what differentiates it from other players so why not put a value on it?
I know that the spectrum & type of the jitter is really the correct way to evaluate it, as you said but if your player's jitter is so low then these can be considered low also!
I think it somewhat optimisitic that Ec would be willing to send their new design, potentially market leading at that, out to a third party for jitter analysis. it's not even released onto the market yet, and designs do have a habit of being copied very quickly these days.
Maybe Guido Tent could help out, he's trusty...
Maybe Guido Tent could help out, he's trusty...
I guess it's a marketing decision on John's part but as the player is designed for low jitter which have entailed some operational comprimises as a result (SD cards =< 2GB; basic UI; TDA1543 DAC), it would seem sensible to have the main unique selling point (jitter) verified!
As to how this is done ........?
As to how this is done ........?
jkeny said:
My idea is that to make measurements and to publish the results or not depends on his development and business policies. I do not necessarily request it because rigorous measuring is costy and not easy for small entities. Moreover, measurement results do not always represent profiles of products well in this area.
In terms of "low jitter profile", what measurement results do we want indeed? Phase noise value like -80db/10Hz for MCLK or BCLK or LRCLK?, or Allan Variance value for 1s, 100ms, 10ms? Do we want measurements only for clock signals or for output audio signals ?
As for me, I believe claims by -ecdesigns- basing not on his measurement results but on his approaches. I think his approaches are good enough.
Bunpei
jonners said:
Yes, you're correct, I was mixing this SD player with Koon's SD player limitation!
Don't get me wrong - I don't distrust ec-designs intentions but the techniques he has applied are new and unproven. I'm no e'e or RF expert so I've no basis for evaluation of these techniques.
Particularly in audio, when faced with techniques I don't have the expertise to evaluate, I run for the cover of relevant results measurements which allows me some ease of mind.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.