Update problems
Hi
I have a problem updating the dam. After the update the dam does not lock to spdif anymore (which is my only input) It clicks while trying to lock to I1 but it does not lock.
I use ZTerm and up to now everything went smoothly, but this update does not work, after the update I still see 0.9 in the umanger (attachment)
Even loading 0.9 again does not restore the locking problem. I looked at the spdif input with a scope and everything looks as before the update....
Does anybody know what went wrong and how to get the dam running again...
Thanks Tobias
Hi
I have a problem updating the dam. After the update the dam does not lock to spdif anymore (which is my only input) It clicks while trying to lock to I1 but it does not lock.
I use ZTerm and up to now everything went smoothly, but this update does not work, after the update I still see 0.9 in the umanger (attachment)
Even loading 0.9 again does not restore the locking problem. I looked at the spdif input with a scope and everything looks as before the update....
Does anybody know what went wrong and how to get the dam running again...
Thanks Tobias
Attachments
Clicks appear every time there is digital silence. Even during playback of handful of edm tracks (''Infected Mushroom - Never mind'' is a good example).
Additionally every time using seek, pause stop or track change manually.
USB interface is JLsounds USB-I2S.
Player is Foobar2000 pure stock form, no plugins etc. But any other source from computer has the same issues.
Click is short, and not very powerful. It feels little less loud than with previous firmware.
Greatest improvement is that tracks start from the beginning, not 2-3 seconds in. Also usually no clicks appear when player is switching to next track after previous track ends in playlist by itself.
Some differences are in sound quality as well, this is probably the new filter that comes with the package? Anyways overall the Dam sound feels a bit more effortless, and more open sounding now.
Last edited:
ok, I got the dam running again by simply uploading a new filter, but I still get the fpga update not working... but anyway, that is not an emergency anymore, so I will look at it a little more...
I use the LED output for debugging, forgot to change back, will have updated firmware out later today.
Clicks / Amanero:
Clicks when fast forward or other audio player functions has nothing to do with the dam1021, clock is not supposed to stop unless needed to, the player need to output valid data/clock at all times. The dam1021 have to resync when input clock changes or stop.
The Amanero USB interface seems to have problems when changing clocks, ensure you have latest Amanero firmware loaded.
But I do have some ideas to improve on the dam1021 by re arranging the fpga muting logic, maybe the clicks can be eliminated.
Clicks when fast forward or other audio player functions has nothing to do with the dam1021, clock is not supposed to stop unless needed to, the player need to output valid data/clock at all times. The dam1021 have to resync when input clock changes or stop.
The Amanero USB interface seems to have problems when changing clocks, ensure you have latest Amanero firmware loaded.
But I do have some ideas to improve on the dam1021 by re arranging the fpga muting logic, maybe the clicks can be eliminated.
Seems like it didn't get your 'y' when asking "sure", should say:
uManager Firmware Update, are you sure ? Updated, resetting.
And then the reset. In your screen dump it don't reset, just return to the prompt.
Thanks for this. Works like a charm direct from the rpi UART (3.3v cmos serial).
No more usb-serial adapter.
Last edited:
Thanks, earlier I realized the pin just stays on no matter what, that explains it.
Please be sure to keep the previous behaviour of this pin, inverted to the onboard LED. I shunt the dam outputs via relay when this pin is blinking/powered.
Basically you're right. Bit clock or l/r signal should not be interrupted if not necessary. But there are lots of different i2s implementations with their own peculiarities. What if dam1021 software is written in optimistic approach? E.g. when bit clock generation is resumed take last used settings and change on-fly only when data suggest otherwise.
From end user perspective using gapless playback would solve most annoying cases. See http://www.diyaudio.com/forums/digi...x-servers-soekris-dam1021-12.html#post4411211 for more details.
btw. Could you shed more light on shared filters?
I can confirm that the serial communication with my Arduino through the RS232 port no longer locks up. I will try the isolated port tomorrow..
Also zero crossing detection works very well, no more artifacts when changing the volume (especially at very high volumes).
The much improved PLL clock sync speed is a real treat. It is near instantaneous.
I made a little video comparing the sync speed of the older fw (0.90) with the new one (0.99):
https://www.youtube.com/watch?v=WvnWulPTmDI
Also zero crossing detection works very well, no more artifacts when changing the volume (especially at very high volumes).
The much improved PLL clock sync speed is a real treat. It is near instantaneous.
I made a little video comparing the sync speed of the older fw (0.90) with the new one (0.99):
https://www.youtube.com/watch?v=WvnWulPTmDI
I agree that the dam1021 should not assume anything. Right now it assume bit clock and word block follow each other, which apparently is not always the case....
I will work to improve but will need some changes in the fpga firmware. Should be possible to make it significant more robust.
Data and work saving,.... If t.ex. the 88K and 96K filters are alike, you can have two filter descriptors but just one set of coefficients for both.
The idea is that in most cases you would want separate 44K and 48K filters but the higher sample rates you're fine with same filters, just like implemented in the stock filters, see 1021filt.txt for details.
Thank you so much, all is working. Now onto filter testing.
Does anyone know any free opensource circuit maker software that I could chart this mute circuit out with? I would love to share.
There are really two issues related to the clicking problem.
1) The conditions which make dam1021 to relock:
1a) Sample rate change - obviously this is unavoidable.
1b) Loss of I2S bit clock, with word clock present. This happens with standard Amanero firmware when skipping tracks or changing position within the same track.
1c) Loss of word clock, with bit clock present. This happens with mpd player software on Raspberry Pi.
1d) Loss of both bit clock and word clock. This could happen when the player software is stopped or USB cable is disconnected.
To handle conditions 1b and 1c more robustly, dam1021 should remain locked to the sample rate of the running clock line, whether it is bitclock or word clock.
Condition 1d could be helped by using the previous settings, as forta suggested.
2) The noise dam1021 makes while it locks.
It emits a high frequency, high amplitude pulse that really hurts ears and potentially also equipment. This is quite a serious problem and has not improved with the new firmware.
On a positive note, switching between two I2S sources running at the same sample rate does not cause dam1021 to loose lock.
1) The conditions which make dam1021 to relock:
1a) Sample rate change - obviously this is unavoidable.
1b) Loss of I2S bit clock, with word clock present. This happens with standard Amanero firmware when skipping tracks or changing position within the same track.
1c) Loss of word clock, with bit clock present. This happens with mpd player software on Raspberry Pi.
1d) Loss of both bit clock and word clock. This could happen when the player software is stopped or USB cable is disconnected.
To handle conditions 1b and 1c more robustly, dam1021 should remain locked to the sample rate of the running clock line, whether it is bitclock or word clock.
Condition 1d could be helped by using the previous settings, as forta suggested.
2) The noise dam1021 makes while it locks.
It emits a high frequency, high amplitude pulse that really hurts ears and potentially also equipment. This is quite a serious problem and has not improved with the new firmware.
On a positive note, switching between two I2S sources running at the same sample rate does not cause dam1021 to loose lock.
It is not opensource, but Eagle CAD has a free edition, and now there is also Circuitmaker. Drawing it on a napkin would also work
Mine sounds more like a wider band transient, the lower frequency component can be both heard and felt.
The problem for me is partly alleviated by using VSTHost which provides a constant signal, but for most folks it won't be viable.
I get a quite noticeable low frequency plop when powering the DAM on or off (DAM modded with additionally 2700uF Vref bypass, which is most likely the reason ... but some dedicated muting signal at the controls would help for an stable implementation of a muting circuit).
Playing via Amanero:
A small strength noise (of "ttsiik"-type) when pausing the playback.
A medium strength moise of same type, when restarting playback from pause. Both could also be caused, that playback is not stopped/started at a zero crossing (by the player).
When when restarting playback from pause frequently left and right channel start playback at different time.
The same type of "ttsiik" noise is present at sample rate change, most audible if the played piece of music immediately starts with content (what is e.g. frequently the case with classical recordings if you do not start at the very beginning, as the content is "gapless").
Also with sample rate change still the begin of the music is "lost in the ttsiik" if the music immediately starts with content.
All these effects are more obviously present with high sample rate recordings (with 44.1/48 it is now not very annoying, with 192kHz not much better than with the old firmware).
Could not the incoming signal could be (optionally) buffered and be played with delay (but completely) only after the sample rate etc is determined and stable conditions are reached?
When playing via optical input, directly from the MacBooks internal optical out, most of the issues are not there or much less obvious, but there I am limited to maximally 96 kHz and can not use the most incriminating files.
I see there is now a DC blocking IIR filter, how do I get rid of it again if I do not want it?
If music is playing already sound does not stop if you enter umanager (+++). The is contrary what is stated here somewhere. Please keep it like that!! it is e.g. very useful to look up which filters are used (filters) without interrupting playback.
---------
Mac/Decibel Player/Amanero/DAM modded with additionally 2700uF Vref bypass
Playing via Amanero:
A small strength noise (of "ttsiik"-type) when pausing the playback.
A medium strength moise of same type, when restarting playback from pause. Both could also be caused, that playback is not stopped/started at a zero crossing (by the player).
When when restarting playback from pause frequently left and right channel start playback at different time.
The same type of "ttsiik" noise is present at sample rate change, most audible if the played piece of music immediately starts with content (what is e.g. frequently the case with classical recordings if you do not start at the very beginning, as the content is "gapless").
Also with sample rate change still the begin of the music is "lost in the ttsiik" if the music immediately starts with content.
All these effects are more obviously present with high sample rate recordings (with 44.1/48 it is now not very annoying, with 192kHz not much better than with the old firmware).
Could not the incoming signal could be (optionally) buffered and be played with delay (but completely) only after the sample rate etc is determined and stable conditions are reached?
When playing via optical input, directly from the MacBooks internal optical out, most of the issues are not there or much less obvious, but there I am limited to maximally 96 kHz and can not use the most incriminating files.
I see there is now a DC blocking IIR filter, how do I get rid of it again if I do not want it?
If music is playing already sound does not stop if you enter umanager (+++). The is contrary what is stated here somewhere. Please keep it like that!! it is e.g. very useful to look up which filters are used (filters) without interrupting playback.
---------
Mac/Decibel Player/Amanero/DAM modded with additionally 2700uF Vref bypass
The dam1021 use bitclk for detecting sample rates and clocking FIFOs. In the FPGA there is a "fast path" muting based on FIFO getting full/empty, which will happen very quickly if bitclk change or stop. Wordclock is only used for steering data to left and right channel, and are not suitable for sample rate detection as the frequency is too low.
Any USB to I2S interface should:
* If bitclk active, provide word clock and output zeroes on data line if no data otherwise.
* If bitclk inactive, still keep data line at zero.
The dam1021 works just fine with any XMOS based interface. Amanero apparently output rubbish at times, which I can't really do much about if I can't detect it....
I will look at the muting circuit, maybe getting more aggressive there, and maybe delay the open up for audio after lock.
But people with Amanero USB interface should get Amanero to fix their firmware or switch to a XMOS based interface.
Any USB to I2S interface should:
* If bitclk active, provide word clock and output zeroes on data line if no data otherwise.
* If bitclk inactive, still keep data line at zero.
The dam1021 works just fine with any XMOS based interface. Amanero apparently output rubbish at times, which I can't really do much about if I can't detect it....
I will look at the muting circuit, maybe getting more aggressive there, and maybe delay the open up for audio after lock.
But people with Amanero USB interface should get Amanero to fix their firmware or switch to a XMOS based interface.
By high frequency I meant hundreds of kHz, reaching into MHz range. But yes, there is also a low frequency component to that pulse and more.
For these measurements, I2S signal was switched between Raspberry Pi 2 and DIYINHK USB interface by a 74HC257 mux. The switch was controlled from a RPi GPIO via software.
DAM1021 was configured with "Mixed" filters.
First of all, this is the pulse dam1021 emits while locking. The amplitude seems to vary randomly between 0.9 and 1.3 Vpp on unbuffered outputs. The shape is always more or less similar. Such a thing should never appear on analog outputs, regardless of how broken the digital sources might be.
The timing on this pulse appears to be quite random. Here are several attemps captured at 44.1 kHz sample rate from DIYINHK USB interface, with no audio present. The other I2S source was off for these measurements. dam1021 input selector was set to I0 (I2S). Yellow and white overlays show the analog output for the same channel captured during several locking attempts. Cyan is the word clock and magenta is the control signal switching the I2S source. Bit clock is not captured here, but it is always switched together with word clock during these measurements.
Some observations on locking speed. The locking time in each scenario varies seemingly randomly by a few hundred ms.
When all I2S lines are started from off state, it takes quite a long time for DAM to lock, approximately 1.5 seconds:
dam1021 locks much faster when switching between different sample rates. Here is the switching behaviour between 44.1kHz and 96kHz. For the approximately ten measurements that I took, locking time varied between 250-650 ms.
When switching from 44.1 to 96 kHz sample rate, there is a blip of 96 kHz audio right after the rate change. Don't know if it is distorted, but no doubt it contributes to the perceived plop. It always happens when switching in this direction, but not the other way around.
Switching from 96 to 44.1 kHz looks pretty good, apart from that ever-present pulse in the middle.
Switching between different I2S sources running at the same sample rate is instant and does not cause dam1021 to relock. No pictures for this use case, it just works
For these measurements, I2S signal was switched between Raspberry Pi 2 and DIYINHK USB interface by a 74HC257 mux. The switch was controlled from a RPi GPIO via software.
DAM1021 was configured with "Mixed" filters.
First of all, this is the pulse dam1021 emits while locking. The amplitude seems to vary randomly between 0.9 and 1.3 Vpp on unbuffered outputs. The shape is always more or less similar. Such a thing should never appear on analog outputs, regardless of how broken the digital sources might be.
The timing on this pulse appears to be quite random. Here are several attemps captured at 44.1 kHz sample rate from DIYINHK USB interface, with no audio present. The other I2S source was off for these measurements. dam1021 input selector was set to I0 (I2S). Yellow and white overlays show the analog output for the same channel captured during several locking attempts. Cyan is the word clock and magenta is the control signal switching the I2S source. Bit clock is not captured here, but it is always switched together with word clock during these measurements.
Some observations on locking speed. The locking time in each scenario varies seemingly randomly by a few hundred ms.
When all I2S lines are started from off state, it takes quite a long time for DAM to lock, approximately 1.5 seconds:
dam1021 locks much faster when switching between different sample rates. Here is the switching behaviour between 44.1kHz and 96kHz. For the approximately ten measurements that I took, locking time varied between 250-650 ms.
When switching from 44.1 to 96 kHz sample rate, there is a blip of 96 kHz audio right after the rate change. Don't know if it is distorted, but no doubt it contributes to the perceived plop. It always happens when switching in this direction, but not the other way around.
Switching from 96 to 44.1 kHz looks pretty good, apart from that ever-present pulse in the middle.
Switching between different I2S sources running at the same sample rate is instant and does not cause dam1021 to relock. No pictures for this use case, it just works
Attachments
Last edited: