• 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

The biggest issue for me are ticks during sample rate change or even track change sometimes. I have DAM connected to power amp and it gets quite loud.
BTW I tried to connect amanero in slave mode but it played only up to 96kHz. With higher resolution files dac locked but it output noise only. In master mode it plays everything. :)
 
Hi.

Taken just from my mind:

* (Detailed) Documentation missing
* Volume control via serial turns off when serial port goes into standby
* I2S interface mode setting should be changed to support majority of
USB/I2S interfaces by default
* Filter quality - several (much?) better sounding solutions have been presented from what I read
* No roadmap/changelog announced. Perhaps I missed that !?!?

Improvement proposals/feature wishlist:

* More filters (e.g. NOS,TotalCrap....)
* Dual-Mono mode
* DSD
* better output buffer (most people who report back prefer the direct out, or
built their own output stage)
* Serial control unit ( to avoid complex/complicated serial installations)
* 24 bits more then sufficiant vs 28 bit??? (ZFE comment??) If so - boards
can be build cheaper.
* shielding the resistor banks

(GLT HifiDuino)
* additional decoupling caps added below the boards
* seperate supply for clock
 
Bugs/potential issues that I know of:

  • Pops while signal locks (reported by TNT)... primarily affects Amanero users. These pops can also happen without sample rate changes (i.e. searching a particular track to a certain point can cause this). Soren has acknowledged this and will attempt to both eliminate the pops as well as reduce the amount of time the DAM1021 takes to lock onto a signal to 300ms
/QUOTE]

I can confirm that this issues happen in my setup, consisting of a banana pi pro using his I2S output... Sometimes more apparent than others...
 
And you think it is a worthy product for over e500 delivered?

There is a problem with the volume control? If it's spzzzzkt's report, I thought he mentioned it's likely soldering wasn't as good as it should be?

Glt brought up a point on how the DAC may possibly load up at full volume on power up with the pot connected - this wasn't addressed. For all we know, that may be part of the new firmware meant to reduce power on and power-off thud.

Bugs/potential issues that I know of:

  • Input selection is buggy (reported by Normunds) - it locks to USB almost always... Soren has acknowledged this and will be addressing it in the next firmware
  • Power-off thump (reported by TNT and RIP his speakers) - I run mine through Tibi's volume controller and the DAC goes off after my attenuator goes to standby so I don't have the turn-off thump.... but Glt has proposed the 1.4W load resistors on the negative rail to balance power drain as a potential workaround.
  • Turn-on pop (reported by TNT) - It's loud on my speaker setup, but not loud on my headphones [I never used the buffered output, though]. Soren acknowledged this and will likely be addressed in the next firmware
  • Pops while signal locks (reported by TNT)... primarily affects Amanero users. These pops can also happen without sample rate changes (i.e. searching a particular track to a certain point can cause this). Soren has acknowledged this and will attempt to both eliminate the pops as well as reduce the amount of time the DAM1021 takes to lock onto a signal to 300ms
  • Inputs labelled wrongly on the diagram (reported by our dear TNT, too :D). Erm... just switch the cables around... just the diagram is labelled wrongly
  • Filter errors (?) (reported by zfe). Sorry, not technically inclined enough there... but I believe Soren has acknowledged this as well.

Not sure if I missed others... but that's all I got.

From all your posts?

I see that there are no real reviews of how it sounds compared to other high quality dacs.
 
Hi.

Taken just from my mind:

* (Detailed) Documentation missing
* Volume control via serial turns off when serial port goes into standby
* I2S interface mode setting should be changed to support majority of
USB/I2S interfaces by default
* Filter quality - several (much?) better sounding solutions have been presented from what I read
* No roadmap/changelog announced. Perhaps I missed that !?!?

Improvement proposals/feature wishlist:

* More filters (e.g. NOS,TotalCrap....)
* Dual-Mono mode
* DSD
* better output buffer (most people who report back prefer the direct out, or
built their own output stage)
* Serial control unit ( to avoid complex/complicated serial installations)
* 24 bits more then sufficiant vs 28 bit??? (ZFE comment??) If so - boards
can be build cheaper.
* shielding the resistor banks

(GLT HifiDuino)
* additional decoupling caps added below the boards
* seperate supply for clock

Your request and resulting response is kind of different, or I may have misunderstood your request for a list of potential board/implementation issues? Right now you're posting a wish list essentially and a list of mods or it's kind of mixed up?

Anyways, some clarification on things that seem a little off:

I2S interface is perfectly fine (or many of us can't get it running... I think I've seen XMOS...USB Streamer...RPi already I'm sure there are more). The suggestions to adjust the pin mapping were for native DSD handling (which isn't going to happen anytime soon... and that is fine. I assume most of us want DACs to support every current format, in the best way possible. Going by what some folks here responded to earlier... it's like all sigma delta DACs should only play DSD and all R2R DACs should only play PCM :rolleyes: Different folks... different strokes.)

Volume control by serial will happen once the isolated 3.3V lines are open in the next firmware (I'm actually really looking forward to this because I can just sense that Dimdim has his code ready to go - and I, ready to leech :D) Maybe he'll be nice to create an arduino shield that's ready to go for a mass order, too? :p

In terms of the firmware/filter interface, maybe some nice programmer can pull a batch script or simple program together to help some of us who are more command-line challenged. I labored with the physical connections myself and I did find it annoying that I had to power-cycle the DAC to initiate a connection - I'm also wondering if it would be possible to do these tasks via the isolated serial TTL lines, too, which hopefully won't require the DAC to power-cycle.
 
Last edited:
From all your posts?

I see that there are no real reviews of how it sounds compared to other high quality dacs.

Fred.

This is not Audio Asylum or Computer Audiophile or HeadFi.
A/B comparisons or device reviews are not common over here.
That's for a reason.

The DAC is not an off-the-shelve product. Or end-2-end solution. It's a board. And it is still work-in-progress.
Several factors will (partly heavily) impact the sound.
Not any implementation will be the same.
How do you want to compare all that?

Build your own device. Apply (and share) all your knowledge to tweak the most out of it and then you open another thread to discuss Soekris DAC implementations and commercial DAC comparisions.

I think this is the wrong thread/wrong area (vendor section!!) to discuss it.

Cheers
 
Hi there.
I am running the dam1021 from a Raspberry pi2 (via usb to a gustard u12 and not via the gpio headers). Why you may ask? Wll because I can :). I will try direct via the GPIO headers from RPI also...
Anyway has anyone tried to control the dam1021 from a serial connection from the raspberry pi? The rpi has UART headers on the GPIO.
If so I may be able to connect to the umanager "remote" from any pc to the rpi (ssh) and from there to the dam1021 umanager.
Not bothering with serial cables etc...
It should work in theory?
 
...
* 24 bits more then sufficient vs 28 bit??? (ZFE comment??) If so - boards
can be build cheaper.
That was a question asking for what the 28bits could be good for (a real one, not a disguised hypocrite statement).

As far as I see, we can not avoid the thermal noise from the resistor(s) of the ladder (and the DAM S/N-ratio is pretty close to that limit).
The RMS voltage level of that noise is proportional to the square root of the (Absolute temperature * Resistance * bandwidth of the measurement)
To increase the S/N ratio, i.e. the number of bits we could rise the DACs FS voltage, lower the ladder resistance or decrease the ladder temperature ... all things that would make it an new DAC design and do, due the square root, have not a huge influence, if we stay within realistic limits.

So the only parameter which could lead to an answer of the question (as far as I see) is the bandwidth of the measurement.
For our listening "application", is that really the audio bandwidth of ~20kHz?
Or can it be argued that while listening, very small bandwidth situations appear (e.g. small variations of a dominating sine tone which we hear), and that these are bandwidths in the sense of the noise law and thus we have here, locally a much better S/N-ratio (i.e. more useful bits).
Or ... well if I knew it I would not ask. ;)
 
Hi there.
I am running the dam1021 from a Raspberry pi2 (via usb to a gustard u12 and not via the gpio headers). Why you may ask? Wll because I can :). I will try direct via the GPIO headers from RPI also...
Anyway has anyone tried to control the dam1021 from a serial connection from the raspberry pi? The rpi has UART headers on the GPIO.
If so I may be able to connect to the umanager "remote" from any pc to the rpi (ssh) and from there to the dam1021 umanager.
Not bothering with serial cables etc...
It should work in theory?

Well it did not work out via the GPIO headers direct.
I guess the dam umanager doesn't wake up with 3.3v (I think Søren said this before) but needs 5v? - it is supposed to work with a later firmware.

Connect the brainbox usb-serial into the rpi and connect that to the dam1021 works just fine :)
Just testing the 10k linear pot when connected to the umanager with the rpi. Output is as this:

It should not be a problem really connecting it to a small lcd display controlling with a motorized potentiometer?

Does anyone know of a "cheap" remote controlled linear 10k (or can I use other values?) motorized volume control potentiometer kit?
 

Attachments

  • volume_ssh.PNG
    volume_ssh.PNG
    7.2 KB · Views: 679
Last edited:
DSD over I2S

The problem is that afaik, there is no standard how to transfer native DSD over I2S, while DoP is a documented standard.

Soren, yes, while there is no official standard for multiplexing DSD signals on I2S lines, there is a commonly used way to do this. I work with Sonore, and we make a USB interface (USB-I2S) which carries DSD over the I2S output. We use the pinout arrangement which is compatible with the ESS 9018 chip's I2S inputs for both DSD and PCM. On the commercial front, this pin mapping is also compatible with the PS Audio DS DAC, and the Wyred 4 Sound DACs; both of these DACs feature I2S inputs (LVDS).
So while not an official "standard" I would suggest using this mapping:

BCLK (PCM)......................BCLK (DSD)
LRCLK (PCM).................... DSD Data Left
Data (PCM)......................DSD Data Right
MCLK (PCM)......................MCLK (DSD, if used)

I am also aware of the ABC-PCB Ethernet-I2S interface which also offers the same mappiong on its I2S output for DSD, so I encourage people to continue to use the same mapping, in the hope that it will become the defacto "standard".
 
That was a question asking for what the 28bits could be good for (a real one, not a disguised hypocrite statement).

As far as I see, we can not avoid the thermal noise from the resistor(s) of the ladder (and the DAM S/N-ratio is pretty close to that limit).
The RMS voltage level of that noise is proportional to the square root of the (Absolute temperature * Resistance * bandwidth of the measurement)
To increase the S/N ratio, i.e. the number of bits we could rise the DACs FS voltage, lower the ladder resistance or decrease the ladder temperature ... all things that would make it an new DAC design and do, due the square root, have not a huge influence, if we stay within realistic limits.

So the only parameter which could lead to an answer of the question (as far as I see) is the bandwidth of the measurement.
For our listening "application", is that really the audio bandwidth of ~20kHz?
Or can it be argued that while listening, very small bandwidth situations appear (e.g. small variations of a dominating sine tone which we hear), and that these are bandwidths in the sense of the noise law and thus we have here, locally a much better S/N-ratio (i.e. more useful bits).
Or ... well if I knew it I would not ask. ;)

I remember to have read somewhere that the ear can actually hear signals at least 20 db below the noise level....

Or the 28 bits are just for the bragging rights.... The last bits are cheap anyway as they don't use the really precise resistors....
 
Soren, yes, while there is no official standard for multiplexing DSD signals on I2S lines, there is a commonly used way to do this. I work with Sonore, and we make a USB interface (USB-I2S) which carries DSD over the I2S output. We use the pinout arrangement which is compatible with the ESS 9018 chip's I2S inputs for both DSD and PCM. On the commercial front, this pin mapping is also compatible with the PS Audio DS DAC, and the Wyred 4 Sound DACs; both of these DACs feature I2S inputs (LVDS).
So while not an official "standard" I would suggest using this mapping:

BCLK (PCM)......................BCLK (DSD)
LRCLK (PCM).................... DSD Data Left
Data (PCM)......................DSD Data Right
MCLK (PCM)......................MCLK (DSD, if used)

I am also aware of the ABC-PCB Ethernet-I2S interface which also offers the same mappiong on its I2S output for DSD, so I encourage people to continue to use the same mapping, in the hope that it will become the defacto "standard".

Noted.
 
Auralic Vega

Can almost promise a report of a shoot-out between:

- DCS Debussy
- Auralic Vega
- The DAM
- maybe some more...

sometimes Sunday.

//


:) It would be really nice to see how dam scores against Auralic Vega. John Atkinson of Stereophile writes, "Auralic's Vega D/A processor offers measured performance that is beyond reproach". I believe John Atkinson is the most objective audio reviewer of all times.
 
DAM construcion - yet another way

Here's some pictures still under construcion.

I've chosen a battery operation for better quality taken a diode bridge off bypassed.
I prefer raw output then cut off the strip lines to a buffered output.

I had sent the DAM to one who's ears are top grade:)
He said the sound from the raw output is much better than opamps.
So I followed it.

Raw output goes to the transformer direct (600:10K) made by TANGO (not available any more)
and following to hi-end line stage and to 300B SET amp.

16bit CD audio source comes from the hi-end transport via S/PDIF at the present.
I've been working on I2S but still not working because of TTL interface.
Maybe I'll try it later together with a Raspberry Pi 2 MPD I'm working on now.


The sound is incredible! Thank you Soren.

Kohjin
 
Last edited:
DAM construcion - yet another way

Here's some pictures still under construcion.

I've chosen a battery operation for better quality taken a diode bridge off bypassed.
I prefer raw output then cut off the strip lines to a buffered output.

I had sent the DAM to one who's ears are top grade:)
He said the sound from the raw output is much better than opamps.
So I followed it.

Raw output goes to the transformer direct (600:10K) made by TANGO (not available any more)
and following to hi-end line stage and to 300B SET amp.

16bit CD audio source comes from the hi-end transport via S/PDIF at the present.
I've been working on I2S but still not working because of TTL interface.
Maybe I'll try it later together with a Raspberry Pi 2 MPD I'm working on now.


The sound is incredible! Thank you Soren.

Kohjin
 

Attachments

  • battery charging.jpg
    battery charging.jpg
    588.8 KB · Views: 798
  • IMG_0111.jpg
    IMG_0111.jpg
    794 KB · Views: 798
  • IMG_0113.jpg
    IMG_0113.jpg
    883.2 KB · Views: 791
  • IMG_0115.jpg
    IMG_0115.jpg
    874.7 KB · Views: 796
  • TANGO(600to10K).jpg
    TANGO(600to10K).jpg
    659.4 KB · Views: 696
debianx,

Well done! I am doing basically the same as you. Wish I had some of those treasured TANGO transformers ...

Had been considering removing those op-amps since I have no need for them. The raw output is up to the task of driving a multi-amp system in my case. Why waste power on them?

I agree the sound is well beyond what any device selling for this price could ever be expected to deliver.

For most folks following your advice would result in great musical enjoyment.

I have considered using transformers mainly to offer an easy way to change polarity of the signal.

(WAVE IO I2S and DAM work well together)

Thanks for your posts.
 
Here's some pictures still under construcion.

I've chosen a battery operation for better quality taken a diode bridge off bypassed.
I prefer raw output then cut off the strip lines to a buffered output.

I had sent the DAM to one who's ears are top grade:)
He said the sound from the raw output is much better than opamps.
So I followed it.

Raw output goes to the transformer direct (600:10K) made by TANGO (not available any more)
and following to hi-end line stage and to 300B SET amp.

16bit CD audio source comes from the hi-end transport via S/PDIF at the present.
I've been working on I2S but still not working because of TTL interface.
Maybe I'll try it later together with a Raspberry Pi 2 MPD I'm working on now.


The sound is incredible! Thank you Soren.

Kohjin

do you think removal of the output OPAMPS helped the sound quality ?

I got good result from powering 3.3v with battery
 
Rick - check changstar.com; a friend is selling a couple of tango transformers. Not cheap, but really nice.

Here's some pictures still under construcion.

I've chosen a battery operation for better quality taken a diode bridge off bypassed.
I prefer raw output then cut off the strip lines to a buffered output.

I had sent the DAM to one who's ears are top grade:)
He said the sound from the raw output is much better than opamps.
So I followed it.

Raw output goes to the transformer direct (600:10K) made by TANGO (not available any more)
and following to hi-end line stage and to 300B SET amp.

16bit CD audio source comes from the hi-end transport via S/PDIF at the present.
I've been working on I2S but still not working because of TTL interface.
Maybe I'll try it later together with a Raspberry Pi 2 MPD I'm working on now.


The sound is incredible! Thank you Soren.

Kohjin