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.
Does the 1121 still have the unwanted silence between tracks where unwanted silence is most annoying?
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,
All of this time I have figured this is just how it is.
Glad to know that is not the case.
I will try re-loading firmware and see if that does something.
Thanks for the answers.
Glad to know that is not the case.
I will try re-loading firmware and see if that does something.
Thanks for the answers.
I have zero gap problem with either 1021 or 1121.
On one or two of my ripped discs I do have the problem but this is from bad setting at ripping.
//
On one or two of my ripped discs I do have the problem but this is from bad setting at ripping.
//
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.
I use the Amanero with the firmware it came with. I listen to classical music recorded in one piece, "artificially" separated in tracks. I definitely hear no gaps.
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.
Is it possible to retrieve the current actual output level setting when in mode "after exit commend". Or in any way?
//
//
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.