DSD Support
Soren, a question about future DSD support.
Have you designated which J3 header pins will be assigned for incoming DSD data?
I'm working on an interface board that should enable me to use a beaglebone black, running miero's botic software, to feed I2S PCM and DSD data to the Soekris DAC; that means to future proof for DSD capability I need to include switching between I2S PCM and DSD as they emerge on separate beaglebone header pins.
I've assumed (based on other similar implementations);
J3-18 (I2S BCKL IN) = DSD BCKL
J3-20 (I2S LRCK IN) = DSD DATA 1
J3-22 (I2S DAT IN) = DSD DATA 2
Are you able to confirm?
Thanks
Ray
Soren, a question about future DSD support.
Have you designated which J3 header pins will be assigned for incoming DSD data?
I'm working on an interface board that should enable me to use a beaglebone black, running miero's botic software, to feed I2S PCM and DSD data to the Soekris DAC; that means to future proof for DSD capability I need to include switching between I2S PCM and DSD as they emerge on separate beaglebone header pins.
I've assumed (based on other similar implementations);
J3-18 (I2S BCKL IN) = DSD BCKL
J3-20 (I2S LRCK IN) = DSD DATA 1
J3-22 (I2S DAT IN) = DSD DATA 2
Are you able to confirm?
Thanks
Ray
My plan is to do DoP, then no special hardware connections is needed as the DSD data is encapsulated in a PCM stream, being sent over USB or SPDIF.....
Not gonna work, you still need filtering at 50-70 Khz and you also need to support DSD128.... My plans are the simple way, probably like everybody else, convert to PCM at 352 Khz, then filter, volume control and output....
So the DAC doesn't support native DSD. Not a problem if it is known about and, as you say, what a lot of others do.
My understanding is a bit limited in this area, so seeking to understand better. I believe most of the USB input devices (and network renderers like the Edel) likely to be used with the DAC (Amanero, Wave, etc.) present PCM output as I2S and, if supported, route DSD output over the same shared header pins? Assuming these devices can accept a DoP format data stream on their input, by implication they must process the data so the DAC won't see DoP via this route?
Thanks
Any news on whether we can expect a fix for plops and cut-outs on Fs change?
Question for Soren and others that know power supplies better than I...
I'm working on an initial implementation of my Soekris DAC in a setup where in addition to the +- supplies I need for an off-board output stage, I have 2 completely separate supplies currently configured as +11.5v each. When I say completely separate, they have separate transformers and only get a ground reference when they are connected to the powered circuit.
I could of course reconfigure one of these to a negative supply, rewiring the transformer outputs to the other side of the diodes and connecting them to the - terminal on the filter cap.
And I also believe I could just connect the wire from the - terminal on the filter cap of that supply to the - supply input and the wire from the + terminal on the filter cap to the + supply input on the Soekris DAC. And VOILA!, it is now a negative supply!
If I do this, then I don't need to rewire the supply and can more quickly, easily, and with less opportunity for making expensive mistakes change back and forth between the current DAC card in that setup (which uses two positive supplies) and the Soekris DAC (which needs both a positive and negative supply).
And of course, once I get the Soekris DAC settled (trying various powering and output stage options, plus updating the firmware and filters), I will rewire that supply into a negative one.
And I should add that I will have high-quality (modified Dexa) + & - 9v regulators at the + & - inputs to the Soekris DAC, so I won't be feeding it un-regulated 11.5v.
First, would that work ok?
Second, what are the drawbacks to doing this?
THANKS!
Greg in Mississippi
I'm working on an initial implementation of my Soekris DAC in a setup where in addition to the +- supplies I need for an off-board output stage, I have 2 completely separate supplies currently configured as +11.5v each. When I say completely separate, they have separate transformers and only get a ground reference when they are connected to the powered circuit.
I could of course reconfigure one of these to a negative supply, rewiring the transformer outputs to the other side of the diodes and connecting them to the - terminal on the filter cap.
And I also believe I could just connect the wire from the - terminal on the filter cap of that supply to the - supply input and the wire from the + terminal on the filter cap to the + supply input on the Soekris DAC. And VOILA!, it is now a negative supply!
If I do this, then I don't need to rewire the supply and can more quickly, easily, and with less opportunity for making expensive mistakes change back and forth between the current DAC card in that setup (which uses two positive supplies) and the Soekris DAC (which needs both a positive and negative supply).
And of course, once I get the Soekris DAC settled (trying various powering and output stage options, plus updating the firmware and filters), I will rewire that supply into a negative one.
And I should add that I will have high-quality (modified Dexa) + & - 9v regulators at the + & - inputs to the Soekris DAC, so I won't be feeding it un-regulated 11.5v.
First, would that work ok?
Second, what are the drawbacks to doing this?
THANKS!
Greg in Mississippi
Last edited:
Soren,
I have been testing input switching with INP_SLCT0 and INP_SLCT1 lines and have noticed some problems.
I used the connection information you posted in #901:
Input Select is:__INP SLCT0___INP SLCT1
Auto_____________N-C_______N-C
I2S______________GND______GND
SPDIF1 (Coax)_____N-C_______GND_____(Sensitive LVDS receiver)
SPDIF2 (Toslink)___GND_______N-C______(Standard 3.3V digital level)
If you don't connect anything to the input select pins it will search the three inputs for a valid signal and lock when found.
I have tested the actual voltages on J3 pins and they are 0V for GND connection and pulled up to 3.3V for N-C.
In Auto mode (both lines not connected) it works as expected, locking onto the first input that has signal. Turning on signal on other inputs after that does not change the input selection.
In I2S setting (both lines to GND) the DAC works as expected. It locks onto I2S signal if present, and does not lock on anything if I2S is missing, but SPDIF signals are present.
In SPDIF1 (Coax) setting (SLCT0 N-C, SLCT1 GND): If the dac was previously locked to I2S input, it will stay locked to I2S even if SPDIF signal is present. If the DAC had not locked on I2S before switching to this selection, it will lock on either of SPDIF inputs - not just COAX, but also TOSLINK if signal is present there.
In SPDIF2 (Toslink) setting (SLCT0 GND, SLCT1 N-C): If the dac was previously locked to I2S input, it will stay locked to I2S even if SPDIF signal is present. If the DAC had not locked on I2S before switching to this selection, it will NOT lock neither on TOSLINK nor COAX inputs.
Can anyone confirm this behaviour? Could these be firmware issues?
There is also a problem with PWRLED output (or I have not connected it correctly). I connected it to a LED through resistor to GND. Is that the correct connection of PWRLED pin?
With this connection PWRLED works in reverse to the onboard LED. When the onboard LED is on, PWRLED is off. When the onboard LED is blinking, PWRLED line blinks in reverse.
There is another small thing - if the volume pot is not connected during dac power-on, the volume will be set to 0dB. However, if the volume pot is disconnected while the dac is powered on, the volume goes to maximum +6 dB. It would be nicer if it went to 0dB level, although this is of course a lowest priority isssue.
I have been testing input switching with INP_SLCT0 and INP_SLCT1 lines and have noticed some problems.
I used the connection information you posted in #901:
Input Select is:__INP SLCT0___INP SLCT1
Auto_____________N-C_______N-C
I2S______________GND______GND
SPDIF1 (Coax)_____N-C_______GND_____(Sensitive LVDS receiver)
SPDIF2 (Toslink)___GND_______N-C______(Standard 3.3V digital level)
If you don't connect anything to the input select pins it will search the three inputs for a valid signal and lock when found.
I have tested the actual voltages on J3 pins and they are 0V for GND connection and pulled up to 3.3V for N-C.
In Auto mode (both lines not connected) it works as expected, locking onto the first input that has signal. Turning on signal on other inputs after that does not change the input selection.
In I2S setting (both lines to GND) the DAC works as expected. It locks onto I2S signal if present, and does not lock on anything if I2S is missing, but SPDIF signals are present.
In SPDIF1 (Coax) setting (SLCT0 N-C, SLCT1 GND): If the dac was previously locked to I2S input, it will stay locked to I2S even if SPDIF signal is present. If the DAC had not locked on I2S before switching to this selection, it will lock on either of SPDIF inputs - not just COAX, but also TOSLINK if signal is present there.
In SPDIF2 (Toslink) setting (SLCT0 GND, SLCT1 N-C): If the dac was previously locked to I2S input, it will stay locked to I2S even if SPDIF signal is present. If the DAC had not locked on I2S before switching to this selection, it will NOT lock neither on TOSLINK nor COAX inputs.
Can anyone confirm this behaviour? Could these be firmware issues?
There is also a problem with PWRLED output (or I have not connected it correctly). I connected it to a LED through resistor to GND. Is that the correct connection of PWRLED pin?
With this connection PWRLED works in reverse to the onboard LED. When the onboard LED is on, PWRLED is off. When the onboard LED is blinking, PWRLED line blinks in reverse.
There is another small thing - if the volume pot is not connected during dac power-on, the volume will be set to 0dB. However, if the volume pot is disconnected while the dac is powered on, the volume goes to maximum +6 dB. It would be nicer if it went to 0dB level, although this is of course a lowest priority isssue.
Last edited:
Kuribo, Søren has not been feeling well and has stated that he will be working on the manual this coming weekend. Patience...
Exactly. The bug that has been going around the world this winter is really tough. It just knocks all the energy out of you and it is very difficult to get rid of (speaking from experience here).
Soren,
I hope that you take good care of yourself and feel better. Of course, we are all jumping with enthusiasm, but your health is the most important thing.
Jac
Probably a firmware bug, I'll get it fixed for next firmware release.
LED output is active low.
eeh, the potmeter is supposed to be either soldered on or not....
Great, thanks for confirming that.
Yes, that works much better.
Ok, ok, I think we can live with that limitation
@ Soren
I had another thought about normalizing the FIR parameters. I see two potential problems (a detailed explanation below).
1.) To use the oversampling factor "os" as factor for normalizing the FIR parameters can result in potential higher distortion if the summed weight of the filter taps with offset "os" are different.
2.) All filters given in 1021filt.txt have distortion in the worst case (which might be unlikely as an audio signal).
The reasoning in detail:
Assume the range of valid signal levels is -1 ... 1. Let sign(x)=+-1 according the sign of x and abs(x) the absolute value of x.
Let x[t] be the signal, f[0],...,f[n] the filter taps, then the filter output is
y[t]= Sum_{i=0}^n x[t-i] f.
The worst case (signal level wise) you get for a signal x[n-i]=sign(f). Then
y[n]=Sum_{i=0}^n abs(f) (call that the summed weight of the filter).
As I said, this x is unlikely as audio signal, but the worst case. All filters in 1021filt.txt have summed weight greater than 1, so worst case distortion.
Now let's have a look at the oversampled case.
due to the oversampling (zero Insertion) the signal has the special form:
x[0],0,...,0,x[os],0,...,0,x[2*os],...
so z[0],z[1],z[2],... = x[0],x[os],x[2*os] was the signal before oversampling.
So we can break the computation of the output y in "os" parts with "os" independent filters g_j that are a factor "os" shorter. I.e.:
y[os*t+j]= Sum_{i=0}^m z[t-i] g_j, with g_j=f[os*i+j], for any j in 0...os-1.
A rough estimate of summed weight of the short filters g_j is that it is about a factor os smaller than the one of filter f. If you scale up the FIR coefficients with a factor os, you will roughly have the same worst case distortion as the filter f itself.
But a look at the exact values shows that there is some variation in the weighted sum of the short filters g_j. To be on the save side one should scale only with
(summed weight f)/(max(summed weight g_j | j in 0...os-1))
then distortion in the oversampled case is not worse than the distortion allowed by f.
Data from the filters in 1021filt.txt:
template:
summed weight of f
os* summed weight of the g_j
# FIR1 44.1
2.04637
1.80484 2.07875 2.28636 2.36327 2.28636 2.07875 1.80484 1.6678
# FIR1 48
1.98229
1.611 2.09698 2.41172 2.52064 2.41172 2.09698 1.611 1.09828
# FIR1 88.2
1.88444
1.87984 2.01123 1.87984 1.76685
# FIR1 96
1.84103
1.86609 2.14057 1.86609 1.49136
# FIR1 176.4
1.85111
1.93129 1.77094
# FIR1 192
1.79841
2.05415 1.54266
# FIR2 for 384 or 352
1.48224
1.40398 1.47709 1.55142 1.57766 1.55142 1.47709 1.40398 1.41527
If I try mkrom I get :
mkrom 1021fil2.txt
Soekris Engineering mkrom utility vers 0.85, 20150112
Invalid filename 1021fil2.txt
mkrom 1021fil2
Soekris Engineering mkrom utility vers 0.85, 20150112
Invalid filename 1021fil2
The file 1021fil2.txt exists in the working direktory which also contains mkrom.
What am I missing? (I am Mac guy, maybe I do somthing stupid DOS-wise
)Questions on the R-2R
first post here…
thanks for offering Le Total Dac for the masses…
i have been reading from the start and i have a couple of questions…
first, if i go ahead with this dac, what is the voltage to feed it, if i want to go DC, is it still between 7 and 8 volts or as high as 12 volts DC?
second, i would be using one of my WaveIO usb sound card… so the led on the card goes on and off depending if my iTunes server is feeding or not feeding the tracks, does that mean i get crick crack crock sound through the speakers during that time?
third, what does it take to feed it to my audio gd preamp (c-39) in the ACSS input? (current mode input), i have no clue how this krell knock off technology works.
thanks
Martin
first post here…
thanks for offering Le Total Dac for the masses…
i have been reading from the start and i have a couple of questions…
first, if i go ahead with this dac, what is the voltage to feed it, if i want to go DC, is it still between 7 and 8 volts or as high as 12 volts DC?
second, i would be using one of my WaveIO usb sound card… so the led on the card goes on and off depending if my iTunes server is feeding or not feeding the tracks, does that mean i get crick crack crock sound through the speakers during that time?
third, what does it take to feed it to my audio gd preamp (c-39) in the ACSS input? (current mode input), i have no clue how this krell knock off technology works.
thanks
Martin