Question about stability of data stream in adaptive mode

[jarek]

Dear Peter,

I have a question. When playing in adaptive mode (no upsampling, 4x, unattended), my external DAC connected by dual AES loses synchronization and need to resynchronize when next track is starting. Do you have an idea why it is like that, and if something can be done to keep the data stream stable  ?

Strangely, when I switch to the next track by hotkey, the external dac does not lose its synchronization to the sound card ...

[PeterSt]

Hi Jarek,

A first quick response (maybe too quick ?) ... with Unattended this can't happen. Sheer impossible. Unless ...

For fun, try the same with a Split File size of 60 or so. If then it happens within 30 seconds I'll withdraw the above.

So, just a test first, before I make my statement real firm. But not to forget : Unattended only.

Peter


PS: Right now I am unsure whether you are using a version (which just can be 0.9z-1) which just doesn't result 4x (without unpsampling) into 176400. So, if this was a complaint about 0.9z-1, well, you will still have that problem. This makes things very unreliable.
I'm almost sure you don't have the solution to that. So, you will be outputting 44100. Still, your problem will be the same I think. But it may be more honest for the problem itself not to set the slider to 4x. Just 1x. If then the problem remains, the above applies.

[jarek]

Peter,

I tried both versions 9zb and 9z1 on x1, x2 and x4, unattended and attended, on different buffers/latencies, different volumes, different Q1, and different temporary file size (60 and 100).

On some CDs - usually those consisting of separately recorded tracks - you can observe that resolution in bits shown on dCS DAC display drops from 24 bit to 0 at a very start of each new track just for a second. Then sometimes DAC needs to resynchronize - this however is not always the case. It needs to sychronize 100/100 on lower Q1, when you move up Q1 for on or two, it is more often but still happens quite often and this is annying (20/100 cases or so), because music is interrupted in this case.

Still DAC always shows 0 bits for a moment just at the beginning of each new track for some CDs...

I think you might be interested in this - see 8-9th second of the movie attached. You will see how dCS DAC behaves (in utattended) between tracks.

Another problem with dCS DAC is that, when I set volume
- on XXHighEnd volume 0 -> dCS DAC shows resolution on 16 bits (XXHIghEnd shows 32 bit)
- on XXHighEnd volume -1.5 -> dCS DAC shows resolution on 17 bits (XXHIghEnd shows 32 bit)
- on XXHighEnd volume -3.0 -> dCS DAC shows resolution on 21 bits (XXHIghEnd shows 32 bit)
- on XXHighEnd volume -4.5 -> dCS DAC shows resolution 24 bits (XXHIghEnd shows 32 bit)
- on XXHighEnd volume -6.0 -> dCS DAC shows resolution 17 bits (XXHIghEnd shows 32 bit)
and this is allways - mo matter what CD you play.

What do you think about it ?

[PeterSt]

Hey Jarek - I understand now.

I think there is a rather logical explanation for the resyncs;
The dCS will look ahead as far as possible in the buffer in order to see it has to shut itself off (so to say). Now, the smaller the buffer the less it can see, but it *does* see the silence in the data. So, would it see new data coming up (with the same sample rate and all) it wouldn't do a thing, and let all the clocks running at the speed from before. Something like that.
Notice this is no fiction, because I my self (with the Phasue NOS1) do similar, although a bit the other way around : as long as no explicit change is seen, all keeps on running. This is a. to avoid the time it takes each time to lock and b. to keep the things hot.
Ad a : Almost a necessity because of the so many combinations of sample rates and bit depths. It just would take too much time otherwise (and which may be exactly what bothers you, although I don't think you told that).

About your beautiful list of received bit depths ... yea, isn't that beautiful ! It shows exactly what is happening, and prooves that it is good. So, at -1.5dB only one additional bit is needed to still play in full resolution, hence nothing is lost. And so on. Only -4.5dB prooves nothing )because 25 bits could be needed) but trust me, it is exactly right.
Why -6dB needs 1 additional bit again only ? well, because -6dB is an exact division by 2, hence 1 bit less, and *thus* 1 bit is taken from the headroom which is in the 17-24 bit range once 16 bit material is played onto a 24 bit DAC.

In the end it is all as I promise : the best digital volume you can find, because you loose exactly nothing (but -48dB max).
I hope you like it.

Regards,
Peter


PS: I couldn't play your .MOV file because I don't have the codecs to play it (I think QuickTime or so ... and if there's anything I avoid it is just that).

[jarek]

Dear Peter,

do you think that -6dB should be more "right" and accurate than -4.5dB (at least in theory) ?
When setting voulme to -6dB XXHighEnd does not have much to do to calculate data, whilst setting to -4.5dB calculation might be much more complicated and in fact might be more chances to lose some data ? Am I right ?

[PeterSt]

Hi Jarek,

No, it really doesn't matter. Of course you are right (and understood ) that -6dB would allow for a more easy calculation, but that only counts when I would anticipate on that only (and -12, etc.). But I don't ... And in the end you won't notice it because other things take (much) more overhead. Also notice that this all happens during the preprocessing ... not during real time playback.

And no, there is not more chance for loosing data with -4.5 (etc.), because this is all "pre-determined". Also, it is not exactly -4.5, it is ~-4.5 so no data is lost. If data would be lost by means of rounding you would see it by the number of bits used (and -4.5 is a coincidental bad example because there it needs it all). You could also say it the other way around (with some trust in me) : When more steps would be possible without loosing data, I would apply them. But there aren't ...

Regards,
Peter