I think It is caused by RuneAudio on Odroid C1+.
I can play same song of DSD256 on Jriver from PC but not RuneAudio on Odroid C1+.
probably because of DOP limit, as far as I know, rune audio , aka he MpD has no native dsd support, can only be dop
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
ODROID C1+ with RuneAudio confirm support DSD DoP.
The key question is up to which spec.
DSD64 and DSD128 already confirm supported.
The DAM supports DSD256 only in native mode. Doing DSD256 with DoP would require the interface to work at 768KHz, which is not supported.
So to get DSD256 first you would need to get the ODROID to support native DSD.
The Nativity of Native DSD
The Nativity of Native (DSD)
Both DSD across USB using ASIO and DoP are native
Last edited:
@Søren, all,
found the solution for my dam problem with normundss help, thanks again!
On my other boards i solder a connection for the isolator (from J2 => J3) for fast testing the boards and on my "problem board" i didn't make these connection.
Now it workss as expected without issues, tested only I2S with my waveio! I will take a look on waveio board where to get 3.3V for the isolator.
[Posted it also yesterday in the "wrong" thread]
found the solution for my dam problem with normundss help, thanks again!
On my other boards i solder a connection for the isolator (from J2 => J3) for fast testing the boards and on my "problem board" i didn't make these connection.
Now it workss as expected without issues, tested only I2S with my waveio! I will take a look on waveio board where to get 3.3V for the isolator.
[Posted it also yesterday in the "wrong" thread]
The L000 now comes only when there is "start" of music signal, disregard the previous and current sample rate. It seems not so useful to tracking of no-signal, as when the music stops (user press stop or end of playlist), it doesn't send L000.
Probably because there isn't a detectable "no-signal", just because you stop the player doesn't mean it can stop the audio interface to the dam1021, most USB to I2S interfaces continue to supply valid I2S signals....
Søren: Is it possible to dig into the power off/on blop issue on the rev1 boards? Yes it was reduced with the 27k4 resistor but still its (in my setup) way to high and almost "scary".
Are there any other easy way out to make this issue disappear completely without adding a (for me) complex muting circuit?
Are there any other easy way out to make this issue disappear completely without adding a (for me) complex muting circuit?
Sorry, currently no other solution, that why the additional hardware from rev 2 boards....
Last edited:
Could you please publish a reference circuit for the muting of rev1 boards. The guidelines for relay based muting you gave in an earlier post are a bit vague.
That is not quite what I thing would be the right implementation.
Mute should be a seperat command and unmute should return to the previous choosen volume.
Sören, how much capacitance does the vref buffers have on R3.0? and are the regulator setup same as rev2.0 board?
Rev 3 have 400 uF per vref rail, the vref buffers now have 25 mohm output impedance but are otherwise the same.
My recommendations are still don't touch the buffers but add as much capacitance you feel like, that's why there now actually are holes to do it easily....
Firmware version 1.05 is now up on http://www.soekris.dk/download.html
There are now full DSD support, up to DoP128 and DSD256, depending on the used USB to I2S interface.
Pinout for DSD is per de facto standard:
I2S bclk -> DSD Bit Clock
I2S lrclk -> DSD Left Data
I2S dat -> DSD Right Data
The issues on version 1.03 and 1.04 should be fixed, and I have worked hard to limit (hopefully eliminate) clicks and pop when changing between PCM and DSD and between sample rates.... Reports very welcome.
There are now full DSD support, up to DoP128 and DSD256, depending on the used USB to I2S interface.
Pinout for DSD is per de facto standard:
I2S bclk -> DSD Bit Clock
I2S lrclk -> DSD Left Data
I2S dat -> DSD Right Data
The issues on version 1.03 and 1.04 should be fixed, and I have worked hard to limit (hopefully eliminate) clicks and pop when changing between PCM and DSD and between sample rates.... Reports very welcome.
That depends on what one means by "native". If "native" is defined as "not converted to PCM" then both DoP and "native DSD" are indeed "native".
But in our circles "native DSD" has come to mean "not encapsulated in PCM" or in other words, "not DoP".
Yes, both methods of transfer should produce the exact same result (sound wise) but DoP has added overheads, both in required bandwidth and processing power. That is usualy not a problem for DSD64 & DSD128, but DoP becomes impractical for DSD256 (and above) mainly due to its bandwidth requirements.