I feel very uncomfortable with that dam1121-going-to-V00-without-typing-anything issue not understood. Adding extra securety is fine, but without understanding what went wrong (e.g. knowing if there is a bug in the firmware or not) this is more cureing symtoms and not the cause.
I had a similar project as TNT and am now hesitating.
P.S. Please add that failsafe feature also for the dam1021 firmware.
I remember trying to change the volume there and doing some typos (I do not remember what exactly) and ending up with unwanted V00.
TNT,
I am not (yet) using the 1121.
Did you not have this happen with your 1021?
With my 1021 preceded by both a computer and the SDTrans I always have the gap so I figured it was the DAC and not the source.
I am using the latest firmware.
I only listen to REDBOOK so there is no format switching required yet there is a gap. Really obnoxious on those early orchestral CDs where they have myriad idiotic "tracks" within movements, etc.
I thought this was the case for everyone.
Take care,
I am not (yet) using the 1121.
Did you not have this happen with your 1021?
With my 1021 preceded by both a computer and the SDTrans I always have the gap so I figured it was the DAC and not the source.
I am using the latest firmware.
I only listen to REDBOOK so there is no format switching required yet there is a gap. Really obnoxious on those early orchestral CDs where they have myriad idiotic "tracks" within movements, etc.
I thought this was the case for everyone.
Take care,
It is possible that the I2S source you use is stopping bitclock output when data stops (which is at the end of every track), and restarting it for the new track. This causes the DAM to relock. This gap was really bad with early DAM firmware (like 2 seconds), now it is much improved, but still there.
For example, the DIYINHK USB interface does not stop bitclock output, but the stock Amanero does. I had to reflash Amanero with a different firmware which keeps bit clock always on.
If you have a scope, take a look at your I2S signals, the gap is quite easy to see in BCLK line.
Thanks to zfe and spikestabber for your comments.
If it is the SDTrans I would think I would have read about it somewhere.
I have played around with the board extensively and there is the possibility I have disabled something? Everything works just fine with the DAC - never gives any trouble other than this which I assumed, because of the early problem, was simply that that had not been fully sorted and now I know definitively that is not the case and that is the first thing I needed to know. And what do I know? I have no idea why this is happening! So much for the always desired easy answer.
THANKS, again for the reports.
I will take normundss advice and see if i can see where it goes wrong.
If it is the SDTrans I would think I would have read about it somewhere.
I have played around with the board extensively and there is the possibility I have disabled something? Everything works just fine with the DAC - never gives any trouble other than this which I assumed, because of the early problem, was simply that that had not been fully sorted and now I know definitively that is not the case and that is the first thing I needed to know. And what do I know? I have no idea why this is happening! So much for the always desired easy answer.
THANKS, again for the reports.
I will take normundss advice and see if i can see where it goes wrong.
Set a value on boot up. And store the value in your code. That way you 'know' the current value. Use the value however you want - display etc. When you change level by issuing the volume up/down command in your code either update your stored value or read the DAM's feedback - which is issued after every command.