pretty cool,
When I am on the road my high end system is my EPC with music encoded in flak into a AMB Y1 DAC, into a AMD Mini3, and my AKG K701. I like this project as it will not require a PC to boot up, a shame you can't offer 2 versions on with just I2S out that would fit in a smaller case (ideal would be the same case used by the AMB). I still may buy one (if they become available) to add to my many small boxes that drive the TSA people nuts at the airports.
Bill
When I am on the road my high end system is my EPC with music encoded in flak into a AMB Y1 DAC, into a AMD Mini3, and my AKG K701. I like this project as it will not require a PC to boot up, a shame you can't offer 2 versions on with just I2S out that would fit in a smaller case (ideal would be the same case used by the AMB). I still may buy one (if they become available) to add to my many small boxes that drive the TSA people nuts at the airports.
Bill
Hi merlin2069er,
Yes,
Fragmented files are mainly a problem with a HDD where you have different seek times depending on the physical location of sectors on the disk. Continuous reads (non-fragmented) mainly have track to track delays that are smaller compared to random read delays (fragmented files).
With the SD-card these delays are different and mainly depend on SD-card on-chip controller properties.
We tried to maximize margin for errors by using fastest possible data transfers between SD-card and DCI module:
- We use double SPI clock speed compared to Koons project.
- The SD-card data is directly loaded into the DCI module without byte swapping or stuffing bytes with the value 0 (required for 64 bits / frame). This is possible by using 32 bits / frame.
- Microchip FAT16/32 libraries are used.
Yes,
Fragmented files are mainly a problem with a HDD where you have different seek times depending on the physical location of sectors on the disk. Continuous reads (non-fragmented) mainly have track to track delays that are smaller compared to random read delays (fragmented files).
With the SD-card these delays are different and mainly depend on SD-card on-chip controller properties.
We tried to maximize margin for errors by using fastest possible data transfers between SD-card and DCI module:
- We use double SPI clock speed compared to Koons project.
- The SD-card data is directly loaded into the DCI module without byte swapping or stuffing bytes with the value 0 (required for 64 bits / frame). This is possible by using 32 bits / frame.
- Microchip FAT16/32 libraries are used.
Hi SunRa,
Main objective was designing a digital audio source that eliminates major drawbacks of conventional digital audio sources, thus providing much better digital audio playback quality. Other advantage is the possible construction of small portable audiophile players, running on batteries.
Both front panel PCB and SD-card PCB design have been completed. I attached a screen shot of the design.
The front panel PCB is tailor-made to the standard aluminum housing. It contains 2 blue LED displays (SMD), one orange LED for play / pause indication, segment / digit buffers, and keys.
In the center there is a slot for the replaceable SD-card holder module (lower PCB). The front panel PCB is directly soldered to the main PCB under a 90 degree angle, using double-row pin headers. The SD-card holder module is mounted to the main board using brass hexagonal spacers.
Main board schematics are almost completed.
We also performed some more comparisons with conventional digital audio sources. These appear to be unable to achieve SD-player performance, regardless of DAC chip, reclocker, analogue stages, digital audio interface or power supply.
Note that the SD-card prototype runs on a cheap mains adapter only, power consumption while playing is around 3.5 watts. Required minimum input voltage equals approx. 7 ... 8 volts. All circuits (including the 3-crystal super clock) run on either 3.3 or 5V.
We also fixed two minor software bugs that were discovered during extensive testing. Player now appears to perform rock-solid, card type or brand are not critical, as long as the SD-cards aren't exceptionally slow like some of the first 128 or 256Mb cards. In general SD-card speed rating of 2 or higher works excellent.
Main objective was designing a digital audio source that eliminates major drawbacks of conventional digital audio sources, thus providing much better digital audio playback quality. Other advantage is the possible construction of small portable audiophile players, running on batteries.
Both front panel PCB and SD-card PCB design have been completed. I attached a screen shot of the design.
The front panel PCB is tailor-made to the standard aluminum housing. It contains 2 blue LED displays (SMD), one orange LED for play / pause indication, segment / digit buffers, and keys.
In the center there is a slot for the replaceable SD-card holder module (lower PCB). The front panel PCB is directly soldered to the main PCB under a 90 degree angle, using double-row pin headers. The SD-card holder module is mounted to the main board using brass hexagonal spacers.
Main board schematics are almost completed.
We also performed some more comparisons with conventional digital audio sources. These appear to be unable to achieve SD-player performance, regardless of DAC chip, reclocker, analogue stages, digital audio interface or power supply.
Note that the SD-card prototype runs on a cheap mains adapter only, power consumption while playing is around 3.5 watts. Required minimum input voltage equals approx. 7 ... 8 volts. All circuits (including the 3-crystal super clock) run on either 3.3 or 5V.
We also fixed two minor software bugs that were discovered during extensive testing. Player now appears to perform rock-solid, card type or brand are not critical, as long as the SD-cards aren't exceptionally slow like some of the first 128 or 256Mb cards. In general SD-card speed rating of 2 or higher works excellent.
Attachments
Hi bear,
There is no jitter free source material (master clock jitter during A/D conversion).
For ease of mind you could use EAC or CD paranoia, I currently use use Grip under Ubuntu / Linux, this application uses CD paranoia.
After ripping, the WAV files can be written to the SD card as follows:
1) First make sure the SD-card is formatted correctly, use FAT32 and include boot sector.
2) Place each CD in a separate directory. All these directories must be placed in the root directory. The directory name must start with a two-digit number, example: 01 - Audiophile Voices Volume I - Various Artists.
3) Copy all WAV files (tracks) of a CD to the corresponding directory. The track names must also start with a two-digit number, example 01 - Over The Rainbow - Jane Monheit.
So it's basically using correct numbering of both directories and tracks, and copy the WAV files to the SD-card.
Suitable SD-card readers are quite cheap (around $5), I use a Transcend SD-card reader. These readers are plugged into a USB socket, SD-card is inserted, and appears as a drive on the desktop.
It's also possible to use micro-SD cards with an adapter.
The player currently supports SD/SDHC cards with a capacity up to 32Gb. This provides room for approx. 50 CDs / card. When the 64Gb cards are available, this is increased to approx. 100 CDs / card.
There is no jitter free source material (master clock jitter during A/D conversion).
For ease of mind you could use EAC or CD paranoia, I currently use use Grip under Ubuntu / Linux, this application uses CD paranoia.
After ripping, the WAV files can be written to the SD card as follows:
1) First make sure the SD-card is formatted correctly, use FAT32 and include boot sector.
2) Place each CD in a separate directory. All these directories must be placed in the root directory. The directory name must start with a two-digit number, example: 01 - Audiophile Voices Volume I - Various Artists.
3) Copy all WAV files (tracks) of a CD to the corresponding directory. The track names must also start with a two-digit number, example 01 - Over The Rainbow - Jane Monheit.
So it's basically using correct numbering of both directories and tracks, and copy the WAV files to the SD-card.
Suitable SD-card readers are quite cheap (around $5), I use a Transcend SD-card reader. These readers are plugged into a USB socket, SD-card is inserted, and appears as a drive on the desktop.
It's also possible to use micro-SD cards with an adapter.
The player currently supports SD/SDHC cards with a capacity up to 32Gb. This provides room for approx. 50 CDs / card. When the 64Gb cards are available, this is increased to approx. 100 CDs / card.
Hi EC
Any progress with gapless playback?
One wish: switch display between minutes/seconds and CD/track
Has anyone more info to the QA-550 SD-card WAV player of www.qlshifi.com ?
Any progress with gapless playback?
One wish: switch display between minutes/seconds and CD/track
Has anyone more info to the QA-550 SD-card WAV player of www.qlshifi.com ?
So edit period of last post ended!
I got some information of QA-550 SD Card WAV player!
It is a similar concept like that of ECdesign. But there are some differences:
It has just S/PDIF outputs (optical/coaxial) and can be steered by a remote. It has a display and can be powered by battery. It has no analog outputs.
Cost: 51 € or ~70$ which is a bargain if sonically good!
I got some information of QA-550 SD Card WAV player!
It is a similar concept like that of ECdesign. But there are some differences:
It has just S/PDIF outputs (optical/coaxial) and can be steered by a remote. It has a display and can be powered by battery. It has no analog outputs.
Cost: 51 € or ~70$ which is a bargain if sonically good!
Problem is - how well implemented is this SD reader compared to ECdesigns?:
- it doesn't have a built-in DAC so not as tightly controlled & implemented as ecdesigns seems to be
- clock implementation is a big deciding factor in the delivery of great sound
- 2 ppm clock (QA-550) means nothing without specifying the measurement freq (ecdesigns - what clock(s) are you using & what phase noise?)
- it doesn't have a built-in DAC so not as tightly controlled & implemented as ecdesigns seems to be
- clock implementation is a big deciding factor in the delivery of great sound
- 2 ppm clock (QA-550) means nothing without specifying the measurement freq (ecdesigns - what clock(s) are you using & what phase noise?)
Is anything known about the contact reliability of these SD-cards? How many times can they be inserted? Since they are mostly used in digital cameras, where they are rarely moved in and out, I'm not sure how much attention manufacturers have given to this. Could this be a potential lifetime problem if the cards are frequently switched?
QA-550 SD Card Player
> It is a similar concept like that of ECdesign.
I think you might be missing the point of the exercise.
If you just want a player without any mechanical drive, there are many to choose from -- any MP3 player (some even support WAV or FLAC), Squeezebox, TEAC WAP2200, any modern laptop with SPDIF output ......
They ALL have one problem -- SPDIF. Then you end up with the well known receiver problem of matching the DAC clock to the source, and getting rid of source jitter. There are tons of way to do so, but apparently the Sabre seems to be particularly good.
What Koon & John have done is to avoid this problem in the first place by using the same clock to drive both DAC and digital source, like in a normal CD player, but to remove the mechanics. There are people who have done similar things before in commecial products. If I am not wrong, Meridian used to have a player which read CD multiple times until error free, and put the data into a memory buffer and played from there.
I would have also liked to believe the QA550 would do the same job.
Pay the 50 Euros, feed it to the Sabre. Done.... That still is one viable, probably very good solution.
What is posted here is John, and to an extent earlier by Koon, is something else. And John has explained it in detail multiple times. You just need to read carefully, and understand.
Patrick
> It is a similar concept like that of ECdesign.
I think you might be missing the point of the exercise.
If you just want a player without any mechanical drive, there are many to choose from -- any MP3 player (some even support WAV or FLAC), Squeezebox, TEAC WAP2200, any modern laptop with SPDIF output ......
They ALL have one problem -- SPDIF. Then you end up with the well known receiver problem of matching the DAC clock to the source, and getting rid of source jitter. There are tons of way to do so, but apparently the Sabre seems to be particularly good.
What Koon & John have done is to avoid this problem in the first place by using the same clock to drive both DAC and digital source, like in a normal CD player, but to remove the mechanics. There are people who have done similar things before in commecial products. If I am not wrong, Meridian used to have a player which read CD multiple times until error free, and put the data into a memory buffer and played from there.
I would have also liked to believe the QA550 would do the same job.
Pay the 50 Euros, feed it to the Sabre. Done.... That still is one viable, probably very good solution.
What is posted here is John, and to an extent earlier by Koon, is something else. And John has explained it in detail multiple times. You just need to read carefully, and understand.
Patrick
If clock is the only problem then yes can be done.
You still get SPDIF, which you need a receiver chip to convert to I2S for your DAC, unless your DAC can take SPDIF directly.
As said, QA500 + Clock (and probably the internal one might already be good enough) + Sabre is one solution.
Then we are down to details -- power supply quality, ....., etc.
Patrick
You still get SPDIF, which you need a receiver chip to convert to I2S for your DAC, unless your DAC can take SPDIF directly.
As said, QA500 + Clock (and probably the internal one might already be good enough) + Sabre is one solution.
Then we are down to details -- power supply quality, ....., etc.
Patrick
> It will be a relatively low-cost ready-made product, it will be available with or without housing.
I guess you didn't mean 70 Euros.
It would be generous of you to provide a conventional (i.e. not only for TDA154x) I2S-out option.
I know it is a piece of art, and one should take what the artist offers, as one piece.
Patrick
I guess you didn't mean 70 Euros.
It would be generous of you to provide a conventional (i.e. not only for TDA154x) I2S-out option.
I know it is a piece of art, and one should take what the artist offers, as one piece.
Patrick
Hi jkeny,
Yes the master clock is extremely important, but that's only part of the "solution".
Suppose you could buy a perfect master clock, based on a new technology that provides zero phase noise / jitter regardless of power supply quality.
Next you connect it to your DAC, using clock buffers (required), perhaps a flip-flop for synchronous reclocking or a counter for dividing. Next the clock signal travels along the DAC on-chip circuits until it finally reaches the output latch or circuit that determines exact moment of D/A conversion.
Now every circuit AFTER the master clock adds jitter, resulting in cumulated jitter, still ending up with timing jitter during the exact moment of D/A conversion.
Logical conclusion, in order to achieve zero timing jitter during D/A conversion the master clock can't have zero jitter (when using real-world circuits). The other way around, when using a perfect master clock you have the certainty that you won't have perfect timing during D/A conversion.
So even when using the best master clock in a conventional design, it won't do much good.
I use a 3-crystal super clock with time correction. It's based on selected discrete circuits (no ICs), and is screened by laminated copper foil / ferrite foil. Super clock intrinsic timing jitter (3-crystal version) should be below approx. 400 femto seconds rms (DC and up). This initial value will rise significantly after time correction (see above explanation).
Good quality conventional master clocks running on a clean power supply without capacitive load and suitable screening would achieve around 2 ... 5 ps rms. It's important that this low value is maintained over the audio frequency spectrum.
The main problem with these is relatively low Q factor (crystal), high sensitivity to power supply noise, and sensitivity to (capacitive) load fluctuations (increases jitter).
So a master clock that measures well on the test bench can still produce higher than specified jitter when connected to a different power supply and loads. And there is the problem of cumulated jitter AFTER the master clock.
Yes the master clock is extremely important, but that's only part of the "solution".
Suppose you could buy a perfect master clock, based on a new technology that provides zero phase noise / jitter regardless of power supply quality.
Next you connect it to your DAC, using clock buffers (required), perhaps a flip-flop for synchronous reclocking or a counter for dividing. Next the clock signal travels along the DAC on-chip circuits until it finally reaches the output latch or circuit that determines exact moment of D/A conversion.
Now every circuit AFTER the master clock adds jitter, resulting in cumulated jitter, still ending up with timing jitter during the exact moment of D/A conversion.
Logical conclusion, in order to achieve zero timing jitter during D/A conversion the master clock can't have zero jitter (when using real-world circuits). The other way around, when using a perfect master clock you have the certainty that you won't have perfect timing during D/A conversion.
So even when using the best master clock in a conventional design, it won't do much good.
I use a 3-crystal super clock with time correction. It's based on selected discrete circuits (no ICs), and is screened by laminated copper foil / ferrite foil. Super clock intrinsic timing jitter (3-crystal version) should be below approx. 400 femto seconds rms (DC and up). This initial value will rise significantly after time correction (see above explanation).
Good quality conventional master clocks running on a clean power supply without capacitive load and suitable screening would achieve around 2 ... 5 ps rms. It's important that this low value is maintained over the audio frequency spectrum.
The main problem with these is relatively low Q factor (crystal), high sensitivity to power supply noise, and sensitivity to (capacitive) load fluctuations (increases jitter).
So a master clock that measures well on the test bench can still produce higher than specified jitter when connected to a different power supply and loads. And there is the problem of cumulated jitter AFTER the master clock.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.