A cheap RS232 to TTL serial converter with isolation barrier. MAX3223 + ISO7221M used, because that's what I had at my disposal. But any similar combo will do. Can be powered from 5V or 3.3V dam1021 rails.
Yeah, it's ugly, soldering wires to header pins can be tiresome, but it works!
Yeah, it's ugly, soldering wires to header pins can be tiresome, but it works!
Attachments
My bad!do u get signal lock loss when u change track and as a result a few seconds of the music is lost?
Yes, with the accompanying KABOOM every time when DAM acquires the lock. It even happens when skipping to a different location within the same track. It is very annoying.
I have not checked what actually happens on the I2S lines in this case, but probably it is the same problem as seen with Amanero USB interface. DAM looses lock if the bit clock signal stops even for a few microseconds.
The real fix for it IMHO should be in DAM firmware (as no other DAC that I have behaves this way). As a workaround, it may be possible to fudge the RPi I2S drivers to never stop the bit clock signal even when there is no audio playing. A similar hack helps with Amanero.
Hi there,
I would like to give you a note that the dam1021 can be nicely integrated with mopidy right now [1]. You can control volume level and mute/unmute signals from whatever client supports this (and that means a large pool of mpd-compatible clients). Default configuration has been prepared for RPi. But in practise any Linux/MacOSX would benefit from this extension.
A nice feature is that you can redefine volume level range as seen by mopidy, so that you could achieve a finer control over levels you feel comfortably with the most. This might be useful if you use mobile mpd clients.
[1] https://github.com/fortaa/mopidy-dam1021
I would like to give you a note that the dam1021 can be nicely integrated with mopidy right now [1]. You can control volume level and mute/unmute signals from whatever client supports this (and that means a large pool of mpd-compatible clients). Default configuration has been prepared for RPi. But in practise any Linux/MacOSX would benefit from this extension.
A nice feature is that you can redefine volume level range as seen by mopidy, so that you could achieve a finer control over levels you feel comfortably with the most. This might be useful if you use mobile mpd clients.
[1] https://github.com/fortaa/mopidy-dam1021
I had no problems with the RPI B and the Soekris in combination with piCorePlayer, and now I am playing with the Soekris and Vortexbox and the Amanero, all I²S combinations.
Problems I had with the distance from the cables, they must be as short as possible.
Personal I don’t like Volumio and some other combinations, they are in many options not the stable solutions/combinations.
For the RPI (Arm7 boards) the most and reliable is piCorePlayer.
I used also the combination with a Cubieboard, and tried many others, and for the x86 (intel) the most stable is for me the Vortexbox.
Now I have also a combination with the Odroid U3 and the Ubuntu software, they all are working stable with the Amanero.
With the Vortexbox/Amanero and the Soekris Dam it is the most musical and dynamic solution.
Problems I had with the distance from the cables, they must be as short as possible.
Personal I don’t like Volumio and some other combinations, they are in many options not the stable solutions/combinations.
For the RPI (Arm7 boards) the most and reliable is piCorePlayer.
I used also the combination with a Cubieboard, and tried many others, and for the x86 (intel) the most stable is for me the Vortexbox.
Now I have also a combination with the Odroid U3 and the Ubuntu software, they all are working stable with the Amanero.
With the Vortexbox/Amanero and the Soekris Dam it is the most musical and dynamic solution.
The interesting thing is that picoreplayer does not have this problem. On my picoreplayer does not lose lock. But some how my picoreplayer at times will just play the first track and stop. I cant figure out what's wrong
It could be a problem with the length of the wires, the I2S line DAC from RPI off a friend who was trying, had the same problems.
After a new and shorter wire length the problem was over.
The problem was with a Raspberry and a combination with a ESS9023 DAC.
Now it’s sounding clear and stable.
After a new and shorter wire length the problem was over.
The problem was with a Raspberry and a combination with a ESS9023 DAC.
Now it’s sounding clear and stable.
I did a small investigation about DAM loosing lock with Volumio RPi source when changing tracks or skipping to a different location within the same track.
This is with unmodified DAM hardware, using firmware v0.9 and EQHQ_v2 filters.
It turn out to be the word clock signal (LRCLK/FSCLK) that stops for about 20 ms. This is different from Amanero, where bitclock is interrupted. The result, however, is the same. It causes DAM to loose lock for 2.8 seconds with all the accompanying ugliness of DAM relocking. There is that high frequency 4Vpp destroyer pulse in the middle of locking period, and the ramping up of sound after the pause also happens with a very ugly blurp.
As reported by several people here, it does not happen with piCorePlayer because it does not stop any of the clock signals when skipping tracks.
piCorePlayer uses sndrpihifiberry I2S driver for the generic setting, while Volumio uses sndrpirpidac driver. Configuring Volumio to use sndrpihifiberry driver does not change the relocking behaviour, so the problem does not seem to be with I2S drivers. Perhaps it is caused by some mpd behavior in Volumio.
In summary, piCorePlayer works well if you have Logitech Media Server in the environment. Volumio, on the other hand, is pretty useless in combination with DAM.
This is with unmodified DAM hardware, using firmware v0.9 and EQHQ_v2 filters.
It turn out to be the word clock signal (LRCLK/FSCLK) that stops for about 20 ms. This is different from Amanero, where bitclock is interrupted. The result, however, is the same. It causes DAM to loose lock for 2.8 seconds with all the accompanying ugliness of DAM relocking. There is that high frequency 4Vpp destroyer pulse in the middle of locking period, and the ramping up of sound after the pause also happens with a very ugly blurp.
As reported by several people here, it does not happen with piCorePlayer because it does not stop any of the clock signals when skipping tracks.
piCorePlayer uses sndrpihifiberry I2S driver for the generic setting, while Volumio uses sndrpirpidac driver. Configuring Volumio to use sndrpihifiberry driver does not change the relocking behaviour, so the problem does not seem to be with I2S drivers. Perhaps it is caused by some mpd behavior in Volumio.
In summary, piCorePlayer works well if you have Logitech Media Server in the environment. Volumio, on the other hand, is pretty useless in combination with DAM.
Attachments
two questions:
1. have you noticed any difference in sq with bbb external clock on when compared to pure dam1021 reclocking/buffering?
2. why are xlr ground pins connected to dac ground instead of chassis ground?
1 BBB can not output 44k1 without external clock. currently I use external clock for 44k1 and on board 48k so that has to wait when I test with exteranl clock for 48k vs on board clock 48k.
2 I tried to float DAM ground from earth groud.
Sound System Interconnection
An externally hosted image should be here but it was not working when we last tested it.
An externally hosted image should be here but it was not working when we last tested it.
In my case, signal ground is not connected to earth ground.
Last edited:
I'm trying to get it work.
I've connected DAM master clk out to BBB master clk in, and clksel respectfully.
So fat I've got 48/96k locking (constant light on on DAM). But the music is some how distorted.
And 44.1k is not locking at all.
I had to play around a little to tell.