You should also make sure the Raspberry USB and network connector, and the audio USB input connector do not touch the metal case. DAM1021 should be connected to ground, so the components on the other side of isolators should not be.
By the way, j-test was created specifically to stimulate the worst case data jitter on SPDIF/AES3 interfaces when using recovered clock. It should not show anything special for I2S interfaces or reclocked DACs.
You could do similar measurements without feeding any signal into DAM. Could also compare no signal at all vs digital silence. I suspect the noise floor will be similar to what you see with j-test. The spikes are probably just electrical noise from Raspberry coupled to DAM1021 through ground.
By the way, j-test was created specifically to stimulate the worst case data jitter on SPDIF/AES3 interfaces when using recovered clock. It should not show anything special for I2S interfaces or reclocked DACs.
You could do similar measurements without feeding any signal into DAM. Could also compare no signal at all vs digital silence. I suspect the noise floor will be similar to what you see with j-test. The spikes are probably just electrical noise from Raspberry coupled to DAM1021 through ground.
Last edited:
Random ideas: (1) it could be EMI pollution from the Rpi's CPU getting busy when you do an MPD DB update (as TNT suggested above), or (2) it could be jitter introduced from the I/O load on the Rpi during the DB update (could be the local flash storage or network I/O load assuming you have a separate system acting as a media storage server).
In other words, an MPD DB update will load both the Rpi's CPU and it's I/O subsystem.
You can isolate these. Try running a pure CPU benchmark such as Prime95 on the Rpi, and see if that causes the same jitter.
Then try running a disk or network benchmark, and see if either of those cause the jitter. It's kind of hard to completely separate I/O from CPU with the Rpi, because the CPU itself is rather wimpy (relative to modern x86 CPUs from Intel or AMD). You also don't want to wear out your flash media on the Rpi, so be weary of doing disk I/O benchmarks that do a lot of writing.
I'd start with something super simple like this: "dd if=/dev/XYZ of=/dev/null" where /dev/XYZ is the device for your flash media (not sure how this looks on an Rpi, on my BeagleBoneBlack running Volumio it's /dev/mmcblk0). This is about as simple an I/O benchmark as you can do; it will simply read every byte off of your device and then throw it away.
Another simple test, assuming you have your music on a separate storage server mounted via NFS or CIFS: just use "dd" to copy some files from the remote server to dev null. For example: "for i in /path/to/remote/music/storage/*.flac ; do dd if=$i of=/dev/null ; done".
In other words, an MPD DB update will load both the Rpi's CPU and it's I/O subsystem.
You can isolate these. Try running a pure CPU benchmark such as Prime95 on the Rpi, and see if that causes the same jitter.
Then try running a disk or network benchmark, and see if either of those cause the jitter. It's kind of hard to completely separate I/O from CPU with the Rpi, because the CPU itself is rather wimpy (relative to modern x86 CPUs from Intel or AMD). You also don't want to wear out your flash media on the Rpi, so be weary of doing disk I/O benchmarks that do a lot of writing.
I'd start with something super simple like this: "dd if=/dev/XYZ of=/dev/null" where /dev/XYZ is the device for your flash media (not sure how this looks on an Rpi, on my BeagleBoneBlack running Volumio it's /dev/mmcblk0). This is about as simple an I/O benchmark as you can do; it will simply read every byte off of your device and then throw it away.
Another simple test, assuming you have your music on a separate storage server mounted via NFS or CIFS: just use "dd" to copy some files from the remote server to dev null. For example: "for i in /path/to/remote/music/storage/*.flac ; do dd if=$i of=/dev/null ; done".
Hurray!!! finally after two weeks of pulling my hair out, I got the pi-3 to DAM interface working. I can now control the volume through it. The issue turn out to be, pi-3 Bluetooth uses serial port. Hence i was getting a lot of intermittent issues and very strange behaviour where the commands were only working occasionally when the terminal window was on. The solution is to disable the bluetooth on pi-3 if you want to use the serial port to control DAM. Alternative is to use a USB to TTL cable and use USB port if you need the bluetooth on pi-3.
3rd implementation in dual dam1021 configuration. XLR output, no display (so it is auto detection of inputs); Dual salas bi-polar to replace the stock +/-5V LDOs; Salas Reflektor-D 3.3V+1.2V for onboard and ISO3.3V. Overkill copper walls and plates under the transformers.
Attachments
4th implementation, dual rev2; AMB sigma22 to P1 to prevent muting; Integrated with NMR (DLNA renderer so that I can push music data thru LAN to it then the dam thru I2S); With tube buffer after the RAW output. R2R shift regs are powered by A123 lifepo4 batteries.
(the cover still under construction)
(the cover still under construction)
Attachments
Nylon spacers to all boards. Isolated between chassis and all boards. After, only one DAM1021 metallic spacer to chassis. All power supply grounds, audio grounds outputs and audio grounds input direct to this point. DAM1021 power supply now is the Salas DCB1.
Less hum noise 100 hz, 150 hz, ... and less Amanero input J-test jitter, with Moode 2.5 data base indexing.
A further improvement with iron shield around Raspberry PI 2b.
Attachments
I have a Raspberry Pi2 feeding my DAM via I2S - this is working excellent. I am using piCorePlayer.
Getting the serial connection to work from my Pi2 to DAM using piCorePlayer, however, is giving me a major headache. If anyone has succeeded in getting that working, I would very much like to hear how?
I have tried to ‘free’ up the Pi’s serial port (ttyAMA0) to use to communicate with the DAM but not succeeded with tinycore Linux. It continues to be in use by busybox. Any suggestions – please?
Getting the serial connection to work from my Pi2 to DAM using piCorePlayer, however, is giving me a major headache. If anyone has succeeded in getting that working, I would very much like to hear how?
I have tried to ‘free’ up the Pi’s serial port (ttyAMA0) to use to communicate with the DAM but not succeeded with tinycore Linux. It continues to be in use by busybox. Any suggestions – please?
A few questions:
Thanks!
- How does the layout look (see attached pic)? Notice the I2S wiring between the dam1021 and Amanero is awfully close to the IEC inlet for AC power. The live and neutral wires are twisted. The non-twisted yellow wire is chassis ground/safety earth. I don't have any problems with drop-outs, but after I screwed everything in place I started second-guessing myself. Now I think I should rotate the dam1021 board 90 degree counter-clockwise, and move the Amanero over to the left. I'd keep the transformer in basically the same spot but have to move the DC power supply board to be to the immediate right of the dam1021. Thoughts?
- What is the voltage of the status LED header from J3? I want to know for selecting the right current-limiting resistor. (I intend to have two chassis LEDs, one simply connected to the power supply, and one connected to the dam1021 status header. I want them to be the same brightness.)
- Anybody running their dam1021 in a chassis without ventilation? This chassis I'm using doesn't have any vent holes in it. I know vent holes can't hurt, but I'm lazy.
That DIYINHK power supply gets a little warm to the touch (particularly the filter coils). Hard to get an idea how much worse it will be in a sealed enclosure. Thoughts? - Any other thoughts/comments on the build thus far?
Thanks!
Attachments
A few questions:
- How does the layout look (see attached pic)? Notice the I2S wiring between the dam1021 and Amanero is awfully close to the IEC inlet for AC power. The live and neutral wires are twisted. The non-twisted yellow wire is chassis ground/safety earth. I don't have any problems with drop-outs, but after I screwed everything in place I started second-guessing myself. Now I think I should rotate the dam1021 board 90 degree counter-clockwise, and move the Amanero over to the left. I'd keep the transformer in basically the same spot but have to move the DC power supply board to be to the immediate right of the dam1021. Thoughts?
- What is the voltage of the status LED header from J3? I want to know for selecting the right current-limiting resistor. (I intend to have two chassis LEDs, one simply connected to the power supply, and one connected to the dam1021 status header. I want them to be the same brightness.)
- Anybody running their dam1021 in a chassis without ventilation? This chassis I'm using doesn't have any vent holes in it. I know vent holes can't hurt, but I'm lazy.
- Any other thoughts/comments on the build thus far?
Thanks!
Some suggestion:
1. rotate dam 90 degree, output face up (back of chassis), AC input J1 face down (front of chassis)
2. regulator place right bottom or left bottom, transformer place right under AC IEC
3. no need ventilation, the regulator might be hotter than the dam in fact, esp if you are running shunt regulator. However, your case seems not shunt reg so it's ok for zero ventilation IMO.
I am using picoreplayer - i2s - dam1021.
Installed minicom as serial program.
Never had any issues with "busybox"
Thanks for the response. Does that mean you have not changed cmdline.txt and inittab.txt but just installed minicom?
I have also been trying with minicom with no luck - I guess I much check my minicom parameters again or kindly ask which commands you have used. I have no problems communicating with my DAM over USB/RS232 with putty from my PC.
Hi there
I'm having issue with Soekris (latest firmware) not locking to DSD signal (playing out of Raspberry 2 with latest version LMS - 7.9 and Squeezelite with dsd support) - I can see the file is being played by player but Soekris is not able to sync - can't hear anything.
Everything else is fine (HD files 96 - 192/24 are being played with no problems)...
Any guess?
THanks...
I'm having issue with Soekris (latest firmware) not locking to DSD signal (playing out of Raspberry 2 with latest version LMS - 7.9 and Squeezelite with dsd support) - I can see the file is being played by player but Soekris is not able to sync - can't hear anything.
Everything else is fine (HD files 96 - 192/24 are being played with no problems)...
Any guess?
THanks...
An externally hosted image should be here but it was not working when we last tested it.
Maybe you can try here to make changes, with firmware 1.06 you have the DoP , and no need to use the DSD2PCM from the LMS server.
I use Vortexbox and the Filter from MoreDam Filters , The Partypack 0.99, and firmware 1.05.
That sounds very good in my set.
An externally hosted image should be here but it was not working when we last tested it.
Last edited:
I was trying different settings - with DSPPlayer plugin and without - no luck. Everything else is playing fine. When Im running LMS from Synology in DSD player plugin got this information: This player supports native playback of DSD files. DSD-over-PCM should be configured on the player configuration interface.
No luck...
No luck...