MicroSD Memory Card Transport Project

Hi, Guglielmo,

Thank you very for the information. The device is very interesting for some aspects. I will tell Chiaki about this.
However, NDK is recently offering more reasonable prices and Si570 is also a rather expensive one. (Does anyone kindly tell me its actual price in a market?)

In principle, Chiaki and Bunpei used to have such a policy "avoid using PLL in a clock circuit as possible".

Bunpei
 
PCM to DSD256 conversion

Some SDTrans users may want to try a play of DSD256 sources. As DSD256 sources originally recorded on the rate are very rare, as a matter of fact, just one that I have ever listened to, we need to prepare them by converting existing PCM WAV files.
I'd like to recommend you use a program, WAV2DFF.exe, released by Sunacchi for that purpose. You can find some useful information http://www.diyaudio.com/forums/digital-source/200818-dsd-playback-system-dsf-player-usb-ddc-dsd-amplifier-11.html#post3136488
 
As the SDTrans firmware may be using the conditional LSB extension routines I previously specified and requested for my own use I am now posting a warning here....

When music data in 16 bit two´s complement format is sent to devices with 24 or 32 bit depth the data must be LSB extended to the required bit depth.
This is also true for any music data like 24 bit as long as the source bit depth is lower than the destination bit depth.

The I2S «standard» states that 0 padding should be used for both positive and negative samples.
This method is creating an error for negative samples that varies with the inverse of the signal level-
For 0 dB FS (16 bit) (maximum level) the error is ca. 0.0035% and for a minimum signal level (1 bit signal) close to 100%.

It would have been more correct to conditionally LSB extend- «0» padding for positive samples and «1» for negative as this would have corrected the error for the negative samples,
but due to the ´two´s complement format error´ this conditional correction method will create its own errors..

This «combination effect» was discovered this when re-checking and re-calculating the conditional LSB extension method to provide updated data for the LSB extension white paper.

A proprietary method was invented that both allows for correct LSB extension and also correction of the ´two´s complement format error´- and is included directly into the discrete DAC128 state machine a DAC I now are finishing. This result in a output that is free of both the LSB extension error / distortion and the bipolar offset error normally created as a result of the ´two´s complement format error´, and also the "combination error" that will be created if corrections is not implemented correctly.

This solution was selected after extensive analysis of where and how the LSB extension errors and the ´two´s complement format error´ can / will occur and the effects it causes.

The bipolar offset caused by the ´two´s complement format error´ that causes a asymmetrical transfer function around bipolar zero have been addressed in many DAC designs - here a attachment showing how it was done in the PCM1702 DAC chips:


As a result of these findings the conditional LSB extension method as previously described should NOT be used directly without also implementing a correction of the ´two´s complement format error´...

Here is the simplest and gravest error the conditional LSB extension method will cause if used without the ´two´s complement format error´ correction routine:

The value -1 cannot be conditionally LSB extended due to the new value will still be -1.
Here shown with -1 and +1 to make it easy to "view":

A negative 16 bit value of -1:
1111111111111111 = -1
Extended "normally" to 32 bit:
11111111111111110000000000000000 = -65536
Extended "conditionally" to 32 bit:
11111111111111111111111111111111 = -1

A positive 16 bit value of 1:
0000000000000001 = 1
Extended "normally" to 32 bit:
00000000000000010000000000000000 = 65536
Extended "conditionally" to 32 bit:
00000000000000010000000000000000 = 65536

Regardless of what bit depth -1 is extended to the result will continue to be -1 with conditional extension...

More information regarding the combined "conditional LSB extension and the ´two´s complement format error´ routine" will be published when the white paper regarding this is finished.

In addition to the proprietary method (hardware) implemented and used for correct LSB extension and also correction of the ´two´s complement format error´- in the discrete DAC128 state machine in my DAC- I am also working on a software implementation that can be used together with other existing DAC chips.
 

Attachments

  • BB PCM1702.jpg
    BB PCM1702.jpg
    93.6 KB · Views: 785
The I2S «standard» states that 0 padding should be used for both positive and negative samples.
This method is creating an error for negative samples that varies with the inverse of the signal level-
For 0 dB FS (16 bit) (maximum level) the error is ca. 0.0035% and for a minimum signal level (1 bit signal) close to 100%.

I can't understand at all the "error" you claimed.
Would you please show the error showing clear examples?
I think there is no error on the "0 padding".

To SDTrans users,

Please read the post I once wrote;

SDTrans192 outputs I2S signal of BCLK frequency, 64*fs. This means formal bit length of one channel data is always 32 bit while effective bit length of actual data is 16, 24, or 32 bit depending on its sources. Therefore, in the case of 16 or 24 bit audio data, residual 16 or 8 bit space must be padded with dummy data.

As you may know, LPCM data in audio file is represented in a signed integer representation of 2's compliment.
Current FPGA program on SDTrans192 pads binary 0 for a positive value and binary 1 for a negative value. Originally, padding 0 for all values were adopted. One over seas user requested changing the method and we made the change because two users including the requesting person said "The new method brings better sonic effect."
However, the current way of padding, "binary 0 for positive value and binary 1 for negative value" is mathematically incorrect.

When we extend, for example, 24 bit signed integer to 32 bit signed integer, a method called "signed extension" should be used. In this operation, the sign of original integer is padded for "left side extended space"; binary 1 for a negative value and binary 0 for a positive value, respectively.
However, if we use this direct value for a play, dB value becomes small. Therefore, we should multiply 8 bit number. This requires "arithmetic left shift" that pads eight 0 to its right space. This operation is not sign dependent but involving only fixed 0.

I prefer a pragmatic approach. Even if the operation is "scientifically unsound", I agree with it as long as it results "better sounds".
One practical explanation supporting the "operation padding binary 0 for positive value and binary 1 for negative value" might be "possible favorable effects on power supply conditions for related digital circuits".

If any SDTrans384 users have questions on this point, please post your questions here. I will answer to you.

Bunpei
 
Dear Alan,

I appreciated your request very much.
As I am not directly involved in Chiaki's DAC project, I have not listened to its resulting sounds. Within a month or so, he will give me a chance. I will report his DAC here then.

His DAC board is announced to have the following features;
- ES9018 dual mono for stereo use
- Crystek 45.1584 and 49.152 MHz oscillators on board
- MCLKs are sent back to SDTrans so that I2S/DSD signals may be synchronous to DAC MCLKs
- No I/V module
- Five +5V independent power supply systems

He has not told me any release plan including a price yet.

Bunpei
 
His DAC board is announced to have the following features;
- ES9018 dual mono for stereo use
- Crystek 45.1584 and 49.152 MHz oscillators on board
- MCLKs are sent back to SDTrans so that I2S/DSD signals may be synchronous to DAC MCLKs
- No I/V module
- Five +5V independent power supply systems

He has not told me any release plan including a price yet.

Bunpei

Hello Bunpei
I have often thought to go mono with ESS, but then you have 2 clocks that are not syncronous. Now I read that exactly this has been done: Your friend sends the 2 clocks back to the drive, and I2S is synchronous? Can you explain?
thank you
André
 
... I have often thought to go mono with ESS, but then you have 2 clocks that are not syncronous. Now I read that exactly this has been done: Your friend sends the 2 clocks back to the drive, and I2S is synchronous? Can you explain? ...

Hi, André,

I'm afraid my summary of the features were not exact enough.
The transort, SDTrans requires both 44.1kHz x 512 and 48kHz x 512 master clock signals for fs of 44.1kHz series and 48kHz series.
That's why the DAC board has 45.1584 and 49.152 MHz oscillators. Output of one of these oscillators is enabled by selection logic signal from the transport side and the single output is forked into two ES9018 DACs.
One of selected output of oscillator is also sent back to the transport in order to generate I2S/DSD signals in synchronous manner in the transport.

I hope you can understand my explanation.

Bunpei
 
Hi, André,

I'm afraid my summary of the features were not exact enough.
The transort, SDTrans requires both 44.1kHz x 512 and 48kHz x 512 master clock signals for fs of 44.1kHz series and 48kHz series.
That's why the DAC board has 45.1584 and 49.152 MHz oscillators. Output of one of these oscillators is enabled by selection logic signal from the transport side and the single output is forked into two ES9018 DACs.
One of selected output of oscillator is also sent back to the transport in order to generate I2S/DSD signals in synchronous manner in the transport.

I hope you can understand my explanation.

Bunpei


I had exactly the same idea, to use the highest possible CCHD-975 XOs in DAC, switched by request remotely from SDtrans :) But there is a little problem here as not all DSD/PCM modes are supported by oversampling filter in Sabre DAC clocked under 50Mhz, so one must disable OSF for higher DSD/PCM mods.
Right now this is the only afordable solution ... or wait until Crystek make, if ever, 98.3040Mhz 90.3168Mhz versions of CCHD-957
 
Hi, André,

I'm afraid my summary of the features were not exact enough.
The transort, SDTrans requires both 44.1kHz x 512 and 48kHz x 512 master clock signals for fs of 44.1kHz series and 48kHz series.
That's why the DAC board has 45.1584 and 49.152 MHz oscillators. Output of one of these oscillators is enabled by selection logic signal from the transport side and the single output is forked into two ES9018 DACs.
One of selected output of oscillator is also sent back to the transport in order to generate I2S/DSD signals in synchronous manner in the transport.

I hope you can understand my explanation.

Bunpei

I thank you for this detailed reply. I am interested, because I would like to slave my transport to the ESS Dac, and this is the same task.
There are not many people who have done it, and I am surprised to learn, that each of these clocks can drive both 2 dac chips and a sender chip.
I have seen in the data sheets, that the max load to the clocks is 15pF. You have a few cm to every chip, if it is located between the boards, and another few cm to the sender. I would be happy to see, that this works without loosing slightly of the fine qualities of these clocks. Then I hurry to buy a 25Mhz clock, suitable for my transport.
Thank you very much for your patience.
André
 
Post 332 from Bunpei himself:

Chiaki and Bunpei would like to recommend ES9018 DAC chip users try "synchronous master clocking" scheme on the chip.
In order to try this, the first thing you need to do is removing (temporarily) an original clock device on your DAC board.

The second step is to connect MCLK output pin of I2S connector of SDTrans to ES9018 XI pin.
There are two ways at this stage. The easier way is to provide 22.5792 or 24.576 MHz MCLK. In this case, you need to set "OSF =OFF" on ES9018 so as to maintain a stable lock on ES9018 from 44.1 to 384 kHz. You need neither EEPROM upgrade nor hardware jumper change. The users of SDTrans192 Rev. 2.1 can also try this.

I think I mean this post. They just slaved the DAC then and went to slave the drive later, which is better.
Bunpei, how do I set "OSF=OFF", when I need "neither EEPROM nor hardware jumper change"?
 
... They just slaved the DAC then and went to slave the drive later, which is better.
Bunpei, how do I set "OSF=OFF", when I need "neither EEPROM nor hardware jumper change"? ...

Hi, roll,

What kind of transport and ES9018-based DAC do you have?
In the case of TPA Buffalo III DAC, you can set "OSF=OFF" by a simple DIP switch setting. In the other cases, you need a special mechanism for ES9018 register setting.
"Jumpering ..." and "EEPROM upgrade" are explanations for our transport "SDTrans384".

Bunpei
 
Hi, roll,

What kind of transport and ES9018-based DAC do you have?
In the case of TPA Buffalo III DAC, you can set "OSF=OFF" by a simple DIP switch setting. In the other cases, you need a special mechanism for ES9018 register setting.
"Jumpering ..." and "EEPROM upgrade" are explanations for our transport "SDTrans384".

Bunpei

Thank you for this explanation. I still use my "old" LipoFe driven 24bit TPA board, the drive is a Lampizator modified Denon 3910 with tube-SPdif output, which is really better than my beloved Teac P2s transport. I have the manual, it has a 24,576 Mhz quartz, but I assume, that my old chip will not work this way.
André