I heard they are provided with redundant circuits and artificial intelligence to reroute the bits. This confirms it!
Living sounds: you could workaround the jitter topic using serial ports with automated scripts? E.g. using one or multiple USB to serial devices and relais boxes with a script that sends +++? Not super elegant, but it would work as long as you retrigger every hour... You can buy TTL level devices for roughly 2 euro, not sure how many you can put on one PC.
Fede, could you please explain? Why would there be need to repeatedly send the manager script? Does it time out?
A simple micro can do that without a pc, but what does it solve? From what I understand all micro related functions are disabled in that mode, even the potentiometer vc stops working.
A simple micro can do that without a pc, but what does it solve? From what I understand all micro related functions are disabled in that mode, even the potentiometer vc stops working.
My workaround would be a 4050 CMOS buffer feeding all the DAMs in parallel (with only one return path), which I would periodically trigger, especially before final mixdown.
But I still hope Soeren can come down from his mountain and help his customers. Fixing the the FIFO behaviour will improve the sound of every one's DAC.
The new FW should track better, and be more stable if a stable incoming clock is at hand, so your "sync" problem should be less with this - no?
Maybe Sören actully made the FW update for you living sounds?
But I'm not sure it is necessarily better for SQ in general...
I have forgotten what Sören said about the reson for the new FW...
//
Maybe Sören actully made the FW update for you living sounds?
But I'm not sure it is necessarily better for SQ in general...
I have forgotten what Sören said about the reson for the new FW...
//
You want avoid to drift out of the internal audio buffer...
Can't you control volume via serial in +++ mode?
I think the idea was to make smaller and rarer adjustments. The older firmware produced pretty obvious and undershoots of the target, so it made more frequent and bigger adjustments than necessary. The problem is that the new firmware does the same thing in my real world setup. No difference in drift properties. But they do sound different...
And Soeren won't answer the question how the adjustment actually works. I have a suspicion that the hardware lacks critical facilities to do the job properly. This was my question two weeks ago:
"Soeren, when exactly does 1.23 change the clocking speed? When the the delta between the incoming clock and the DAM1021's clock exceeds 1/16 Hz? Or when the FIFO-buffer is in danger of over-/underrunning? Or something else?"
If i get you right you need to exit the manager to normal operation, so the fifo buffer gets reset, right? This would be sending an "exit" and "+++". Still easy to do without a pc but what an ugly klutz...
Volume commands should work in manager mode, never tried it.
If you have read really really old post, you would know that the dam1021 tracks incoming bitclock by reading the fifo level, apply a very low cutoff 2nd order low pass filter, then use the result to adjust the oscillator.... rev 1.23 and earlier adjust with 1 hz resolution, rev 1.24 adjust with 1/16 hz resolution, minimum 100 mS between updates to oscillator, the oscillator is at 45/49 Mhz and then divided down as needed to get word clock. rev 1.24 have a variable adaptive updated rate. I am thinking about trying to reduce the update rates, but don't expect anything soon....
I run the DAM1021 all day long logged into Tera Term playing music (while working) and have not noticed a single glitch so far. This is clocked by an RME card.
Thanks. I only tried it for about an hour and assumed i was lucky. Fwiw my i2s feed is reclocked with a Crystek based reclocker.
Thanks, Soeren.
So there is no algorithm that decides on the size of an impending adjustment, correct? It is either 1 hz (rev 1.23 and earlier) or 1/16 hz (rev 1.24). There is no way for the clock to change by multiples of the adjustment resolution in a single step, right?
It's strange that the drift measured by DeltaWave in my setup doesn't change with the new revision. If the above holds true, the only conclusion can be that the new revision results in more frequent updates (to make up for the higher resolution=smaller size of each adjustment). But it is still over/undershooting the clock frequency of the incoming clock.
If I understand the lowpass filter setup correctly, an even lower cutoff would result in the equivalent of a larger averaged time window? It seems to me that using a longer time span from the incoming clock would result in a closer approximation of the target frequency.
I too run it in +++ mode for days without a single audible click or such things. But there might be slips or overruns there once in a while... Source is Toslink out from a Mac Mini.
//
//
I think that update rates as specified might be necessary to support the e.g, s/pdif specification: (Level III can be ignored, right!?)
Properties of Digital Audio Signal at IEC 60958 Interface
Frequency accuracy requirements – Consumer applications
IEC 60958-3 defines 3 levels of accuracy for the sampling clock
Level I (high accuracy mode): ± 50 × 10-6 (± 50 ppm)
Level II (normal accuracy mode): ± 1000 × 10-6 (± 1000 ppm)
Level III (variable pitch shifted clock mode): xxxx
IEC 60958-3 indicates that receivers should be able to lock to signals with Level II accuracy
•I.e., ± 1000 ppm pull-in range
•Indicates that if a receiver’s pull-in range is less, it should exceed the Level I
tolerance (± 50 ppm) and shall be specified as a Level I receiver
Source: https://ieee802.org/3/re_study/public/200505/garner_2_0505.pdf
- high accuracy mode: 50 ppm, 44100 => +/- 2 Hz
- normal accuracy mode: 1000 ppm, 44100 => +/- 44 Hz
There is no big fifo in the DAM so one have to accept that a flimsy source will degrade the audio quality (detectable or not by a human) due to excessive adjustments of the clock. But it would be nice to know that a very stable clock would mean very few adjustments e.g. less 1/minute etc... (detectable or not by a human). It's simply good and sensible engineering which I think the DAM is about. Every time the Si is adjusted it is like a jolt in the DAC process. 100mS = 10 times per second = continuously jolted - but this would probably take a broken source...
I think this long time discussion could be ended by a printable parameter that shows how many adjustments was done the last rolling minute window along with an updated algorithm that is less trigger happy (if input admits!).
//
Last edited:
I quote Sören: "minimum 100 mS" - this would be as I understand it the shortest period between two Si clock adjustments. The 1Hz and 1/16 Hz is the detection resolution ("adjust with 1 hz resolution") i.e. the least difference between incoming clock and Si clock to do a adjustment... But I might very well be wrong... But if true, it would mean that tracking is tighter, i.e. less deviation between the incoming clock and the Si clock - this would support your needs as I understand it. But not necessarily SQ as it probably means more adjustments / seconds of the Si clock - this of course depends on the incoming clock properties.
But I would say that what we would like is to allow greater deviations and be cool that it will "come back" within the size of the small fifo.
Its all quite delicate I suppose...
This 100mS (was this changed in 1.24?) could be used at start but have as an aim to become as large as possible. This would mean fast acquisition of the incoming clock in an initial stage but once tuned on to a long term stable clock, the adjustment time could be in the range of minutes. This would be good.
//
But I would say that what we would like is to allow greater deviations and be cool that it will "come back" within the size of the small fifo.
Its all quite delicate I suppose...
This 100mS (was this changed in 1.24?) could be used at start but have as an aim to become as large as possible. This would mean fast acquisition of the incoming clock in an initial stage but once tuned on to a long term stable clock, the adjustment time could be in the range of minutes. This would be good.
//
As enhanced thread printing is no longer working could someone please point me to the 1.23 clocking specs?