• These commercial threads are for private transactions. diyAudio.com provides these forums for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members, use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 KHz

Hi. Been using the dam1021 since it came out :)

It plays very well. But from time to time it just get silent in a second or two before I get this loud "crack/pop" from the speakers and music starts playing again. Sometimes after half an hour. Sometimes after 15 minutes. Sometimes after several hours. It's just random. The poweoff/on crack/pop mod has been done but it did not get rid of it all.
Running 0.99 firmware.
I don't recall having this issue with the former firmware.
I dont know if it looses the signal or just do a powercycle by itself? Anyone else experience this?

BTW: Running rpi2 direct to dam1021 (i2s). And direct into a poweramp.
Hi, I don't have such experience. I read in earlier post (2-3 months ago?) that rpi (&rpi2) has issue of clock freq not exact to the required value. Do you have other source?
 
Just happened again. About 2 seconds mute and a big pop/bang in the speakers. Happens right in the middle og a song. This time I was in the umanager and it loads the filter once more.
Seems almost like the dam takes a reboot now and then.. Quite annoying.

If you can connect to uManager all the time, it's suggested that you keep connecting when playing music. Whenever there's malfunction, you print screen, then you can provide more information to Soren and others for troubleshooting.
 
Thanks alot for good answers.
Ok I thought in my quiet mind that the dam1021 acts like a "master" and reclocks the signal (FIFO buffer), so it is more or less immune to those kind of issues? But I might be way off here..... (I am not all into this technology yet :) ).
Anyway, I don't have any other source I am afraid.
Well I have several rpi's if that is of any help :)

It happens with both 44.1khz material, 96khz material and so on.

The only thing umanager tells me when it happens is for instance "L096" when it locks again.

If the dam1021 rev1 did not have these issues with cracks and pops when powering up and so on, it would not be a problem really.. Of course that issue is better with 0.99 firmware and that "pop-mod" (2k7 resistor - was it?) connected, but its still there I'll tell you. With 96dB sensitive speakers and the DAM connected direct into the poweramp it sure is quite loud.

Are there any options to rpi that can be used like I am using it? I am running picoreplayer with it connected to a Logitech Media Server (on my NAS).. The soundquality is great.
 
Last edited:
Thanks alot for good answers.
Ok I thought in my quiet mind that the dam1021 acts like a "master" and reclocks the signal (FIFO buffer), so it is more or less immune to those kind of issues? But I might be way off here..... (I am not all into this technology yet :) ).
Anyway, I don't have any other source I am afraid.
Well I have several rpi's if that is of any help :)

It happens with both 44.1khz material, 96khz material and so on.

The only thing umanager tells me when it happens is for instance "L096" when it locks again.

If the dam1021 rev1 did not have these issues with cracks and pops when powering up and so on, it would not be a problem really.. Of course that issue is better with 0.99 firmware and that "pop-mod" (2k7 resistor - was it?) connected, but its still there I'll tell you. With 96dB sensitive speakers and the DAM connected direct into the poweramp it sure is quite loud.

Are there any options to rpi that can be used like I am using it? I am running picoreplayer with it connected to a Logitech Media Server (on my NAS).. The soundquality is great.
Actually I have the same thought as you before, but I read such problem raised by another member before. :eek:
 
If it is indeed an issue of clock drift you can try Hifiberry's DAC+ Pro board. It slaves the RPi to its own high quality clock so it should have a proper I2S output.

If there are some issues with RPi on-board clock then it's cheaper to buy a new RPi2 board instead. It's quite easy to check whether the clock is seriously flawed. Turn off ntp service and run:

Code:
$ echo 'for i in $(seq 250); do ntpdate  -q 0.pool.ntp.org >> /tmp/time.skew.log; sleep 2 ; done'  | at now

Wait approx. 0.5h. If there are significant offset changes (esp non-monotone ones) over the time in /tmp/time.skew.log file, then this might indicate some clock problems.

Whatsoever I found the dam1021 insensitive to the crappy default RPi2 clock; worked from the day one. It's a way more sensitive to lousy i2s connections tough.
 
Member
Joined 2002
Paid Member
...It's a way more sensitive to lousy i2s connections tough.
Using plugable jumpers to DIYINHK Xmos, mine would not lock on power up sometimes.
Reseating connectors resolved it temporarily for a day or so.
With the input switching PCB from group buy, e USB input and the direct connect to rPi2 it is solid. No more lock issues.

Without seeing the reclock buffer architecture, I wonder if the blip is in the buffer and while the firmware may wait for good lock before accepting data in the buffer, what was already there will clock out. If the buffer was purged or zeroed when signal is lost, perhaps that would help.
This may be how the latest firmware works already??
 
This is according to Sorens manual:
Clocking and FIFO
The DAC have a low jitter digital controlled oscillator (SiLabs si570), data is sent though a short
FIFO and the FPGA and uC work together to measure incoming bitrate and adjust clock as needed,
basically a digital PLL with very fast lock and very slow filtering. So the DAC itself only need
serial data, word clock and bit clock, no master clock is needed, it will sync to whatever you feed it.

So in theory it should work out fine?
But the dam has one "i2s mclk out" pin. Is that usable for something?

I read in the thread that more people have the same issue.

Like this for instance
DAM1021-12 rev.2 sometimes loses lock on input signal during playback. There is 2-3 seconds no sound and then everything is OK!

Does anyone else have this problem or?

USB-I2S is Diyinhk.
But that is the rev2 board which I guess don't have that power off blopp. ?
 
Last edited:
DAM1021-12 rev.2 sometimes loses lock on input signal during playback. There is 2-3 seconds no sound and then everything is OK!

Does anyone else have this problem or?

USB-I2S is Diyinhk.

I'm new to the dam1021. Use Diyinhk usb too.
My dam doesn't lose lock when i'm using my PC as source, but when playing from a new Mac this happens like 4-5 times every 30 min playtime.
Dont know why there is a diffrens from PC or Mac over usb.
Regards //Daniel
 
I use 10 cm cables between the rpi2 and the dam. The rpi2 header is just next to the header of the dam.
It is possible to shorten them.

I read somewhere connecting a resistor (approx 100ohm?) on the source side of the i2s dataline might "tame" the overshoot of the rpi i2s signal transfer.
r2ri2s.jpg


But I only run 1 gnd cable from the dam to the rpi.. Could that be an issue?

The isolated side is powered from a high quality 3.3v ldo.
 
Last edited:
Power supply for DAM1021

I have put together some snubbered, regulated LT1963A based power supply PCBs that can be used for powering DAM1021. They will fit into a 1U (40mm) height case. The details are posted on the input board GB thread, along with the Gerber and Eagle files. I have a couple of extra PCBs that I can sell, but this is not a group buy. Feel free to order the PCBs directly or tweak the designs to fit your needs.
 
And I found another issue regarding signal locking, in hifiduino, it mentioned that for the I2S input, USB-I2S interface might output a clock that the dam1021 lock on to….
https://hifiduino.wordpress.com/2015/03/16/soekris-dam-1021-r-2r-dac-users-guide/

I do have this behavior in my dam, it doesn't really change the signal LED to solid green, however, in uManager I see L44 returns, so it thought there is 44.1 signal detected.

Is this a bug? Will it be able to fix in future firmware release? Thanks Soren.

Screenshot 2016-01-22 13.42.44.png
 
Did try to use another two gnd cables between the dam and rpi2.
And for the fun of it, and to test: Took a 330r resistor on the dataline between the rpi2 and dam.
Improving signal quality on Raspberry Pi I2S data lines | Crazy Audio

Initially I actually felt it sounded a tiny bit better but it's probably subjective :)

Anyway the setup has been playing all night and I tried to "pipe" out the result from /dev/ttyAMA0 (the serial data from the dam)... "cat /dev/ttyAMA0 > dam.log &" I have to say, that caused some problems with the dam totally "locked" and I had to powercycle to make it work again. That dam.log file looked strange.

So insted I used an option in "minicom" which is the serial program I use on linux to connect to the dam. "minicom -C dam.log".

Anyway - it seems that the dam has lost signal only once during the night on 96khz material. (loaded 2 times. ) I can live with that.

Will try the same with 44.1khz material.