Practicing Delayed Gratification

[Jud]

Was looking forward to -4, then saw the note about PA not working for "needs 24" DACs, of which I believe mine (Audioquest Dragonfly) is one.

Oh well - back to anticipation.

When you say this will be resolved in a next version, Peter, you mean -5 rather than z-8, right (I hope)?

[PeterSt]

Well ... I honestly hope I will be able to solve it al all ...

All 'n all it took me 60 hours only to have natively played 24 bit files work for Phase Alignment. So, not upsampled. The point here is : this implies no "32 bit calculations" while all is setup like that. So, with 60 hours of looking at data and trying and inverting and what not, I could get something going which maybe officially can't. But, theoretically it could in advance, because (most of) our DACs are not 32 bits and it *thus* works with 24 bits anyway. But now the "Needs 24" situation. This is different, because here, officially, nothing is calculated in the 32 bit domain, while Phase Alignment *still* does that. Thus, also for natively 24 bit files (by now).

I had to give up on the "Needs 24" because at this moment I just don't see how to do things;
With this kind of 24 bit stuff, the guy who invented 24 bit transfer (because that's what it is) should be hanged. And FYI, when a. WASPI came about (you know I was ahead with this over a year of others) and b. the (USB !) DAC's transferring with 24 bits (to save on bandwidth which is totally unnecessary - ehm, see my 32/768 transfer over USB2) created problems for really years for everybody. And yes, back then it was "GR" who out of all (but totally obvious) could help me out. He wasn't right on all he said, but in the mean time did help me out because he gave the insight. Right now ? now I can only say that with a 256 times less calculation room I need a totally consistent fixed number based on the roughness of the data itself, while the rounding which happens after all always in-DAC goes by an electrical fashion which just works out (hey, I too use a 24 bit DAC and it is perfectly okay). In brief : something which is solved in-DAC (think about i2s which is 32 bits and converts to 24 bit) now must be done by myself. And I can't do it, because with the 24 bit transfer I already *have* done this myself, but now needs that 32 bits again FIRST. So, change around 50,000 lines of code which evolved over many years and just works okay ? And knowing that this native 24 bit files comprise of maybe 10 lines of code only and *that* took me 60 hours ??
I rather wait until I got more smart first ...

Peter

[Shoe]

 24 needs dac: I am not sure I understand! If I have a 24 bit dac, PA will not work with the current software?   Sam

[PeterSt]

Sam,

This counts when your DAC will only produce sound when "DAC Needs" in XXHighEnd Settings is set to 24 ...

Regards,
Peter

[Jud]

Well ... I honestly hope I will be able to solve it al all ...

I think it was the engineers at General Electric who used to have a saying: "The difficult we do immediately; the impossible takes a little longer."   

I had to give up on the "Needs 24" because at this moment I just don't see how to do things;
With this kind of 24 bit stuff, the guy who invented 24 bit transfer (because that's what it is) should be hanged. And FYI, when a. WASPI came about (you know I was ahead with this over a year of others) and b. the (USB !) DAC's transferring with 24 bits (to save on bandwidth which is totally unnecessary - ehm, see my 32/768 transfer over USB2) created problems for really years for everybody. And yes, back then it was "GR" who out of all (but totally obvious) could help me out. He wasn't right on all he said, but in the mean time did help me out because he gave the insight. Right now ? now I can only say that with a 256 times less calculation room I need a totally consistent fixed number based on the roughness of the data itself, while the rounding which happens after all always in-DAC goes by an electrical fashion which just works out (hey, I too use a 24 bit DAC and it is perfectly okay). In brief : something which is solved in-DAC (think about i2s which is 32 bits and converts to 24 bit) now must be done by myself. And I can't do it, because with the 24 bit transfer I already *have* done this myself, but now needs that 32 bits again FIRST. So, change around 50,000 lines of code which evolved over many years and just works okay ? And knowing that this native 24 bit files comprise of maybe 10 lines of code only and *that* took me 60 hours ??
I rather wait until I got more smart first ...

Peter

The Dragonfly is USB1 (apparently GR/AQ didn't want to make it necessary to download drivers for Windows), so perhaps the bandwidth limitation is a bit more justified in this particular instance.  Doesn't make things any easier for you, though.