Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter

[qusp]

the point is though, there are many hundreds of these out in the wild and though this has been discussed a number of times, not a single person has reported it being a problem in reality, so its just handwaving; it has not been a problem in ANY reported case, not just most cases.

clocks in devices simply arent that bad or different these days in the long term and the short term is meaningless. its only a possibility with a direct i2s input anyway, because the spdif input board has its own clocking system.

yes we've even covered the possibility of gaining feedback over USB in a USB-i2s convertor as a way to solve this theoretical problem, but since there have been no actual reports of this issue, there really isnt a great deal of motivation to 'fix' it.

besides the FPGA and MCU on the fifo will know if the time is coming over a fairly long time scale because the buffer is fairly large and it would be able to empty itself between samples if the command was created in the firmware

IF there was a real problem Ian may be motivated to solve it.

we've been here before, chewed it all over before and its still just a theory. another 6 months later and another round of hundreds of sales, running higher speeds each time, that should be more likely to show the issue up, yet here we are...

[Julf]

Originally Posted by qusp

we've been here before, chewed it all over before and its still just a theory. another 6 months later and another round of hundreds of sales, running higher speeds each time, that should be more likely to show the issue up, yet here we are...

Well, yes, it is a theory in the same sense as the laws of physics are a theory - it is not something that might or might not exist, it is just something that might or might not cause any practical issues.

My interest in it is that it is why a lot of people insist that a DAC system *must* use a sample rate converter. I don't agree with them - like you I feel it can be made to be a non-issue in practice, but that doesn't mean it isn't a real problem on a more formal level - unless there is something in the setup I have overlooked.

If you have a glass of water, with a very precisely measured and drilled hole that produces a very stable leak, if someone is constantly pouring in water into the glass at a rate that is slightly higher than your leak rate, the glass will fill up and overflow at some point, unless you can tell the person pouring the water to stop for a second.

[percy]

Originally Posted by qusp

fifo memory is large by normal scale and it empties to half full between tracks to avoid under/over-run

doesnt seem to be an XO? are you sure you are looking at the same design? the output board comes in 3 flavors, the single clock board that comes standard and contains the clock buffer/s and 2 sets of 3 flip-flops, the dual clock board which has the same but with 2 clocks and the si570 multispeed DSPLL clock generator which will provide clock multiples for anything from 44.1->384kHz.

all of them take the output of the fifo memory buffer/fpga and reclock it (with or without galvanic isolation inbetween) and output MCLK plus bck, lrck, sdata all clocked from the same clock and this is then optionally fed synchronously to the dac chip.

the flip-flops are clocked by the output clock

so basically there is NO feedback mechanism to throttle the output clock. well thats where my confusion was. There is no explicit reclocking going on. Just luck and lots of memory at work. Yeah technically a vcxo is used but there is no "VC" going on for clock synchronization purpose.

Originally Posted by qusp

its impossible to believe you read or even searched the thread for this information and didnt find it; this project/product and its development has been well documented and discussed here, much better than most other projects. there is not, nor will there ever be source code or full schematics posted, nor should it be expected, sorry but that question itself tends to put me a bit offside.

Slow down now qusp. No sorry but its not "well documented" - information litered over 1800 posts is not the definition of well documented. And the request for full disclosure is not unreasonable either - atleast on a open/diy/non-commercial effort like this. Its like saying I built fantastic amp/preamp/dac with a very novel idea that has never been tried before but you only get the prebuilt boards in a group buy and forget about the schematic or expecting objective information to prove its worth in weight.
But dont bother now, not interested any more.

Originally Posted by qusp

from the datasheet
synchronize a clock generated from a PLL and high quality oscillator to incoming S/PDIF data stream

exactly my point.

[qusp]

Originally Posted by percy

so basically there is NO feedback mechanism to throttle the output clock. well thats where my confusion was. There is no explicit reclocking going on. Just luck and lots of memory at work. Yeah technically a vcxo is used but there is no "VC" going on for clock synchronization purpose.

no there isnt, this would add jitter and would also mean a direct connection to the dac clock from a µC or some such, after it has been deliberately isolated, all to solve a problem that doesnt impact on any real world use case.

Slow down now qusp. No sorry but its not "well documented" - information litered over 1800 posts is not the definition of well documented.

sorry but yes, this exact conversation has been had more than a few times.

And the request for full disclosure is not unreasonable either

yes... it is. this was developed almost entirely by Ian in his time, on his equipment and effectively given away at the price hes got on it, its perfectly reasonable for him to retain his IP to use how he wishes, he owes us nothing. you buy it or you dont, I dont think he'll lose any sleep.

the only dacs with this sort of tech are in the high 4, early 5 figure range

- atleast on a open/diy/non-commercial effort like this. Its like saying I built fantastic amp/preamp/dac with a very novel idea that has never been tried before but you only get the prebuilt boards in a group buy and forget about the schematic or expecting objective information to prove its worth in weight.

its really not such a novel idea, Naim and a few other very high end dacs have been using the same technology/concept for a few years, but its the first time its been offered DIY and in such a way that allows good integration into different systems with micro BNC etc. its a very simple concept, it just hasnt been executed quite like this before and you are not owed an explanation, you buy it, or you dont. there is a thread in the vendors section and Ian may reserve the right to use it in a fully commercial endeavour.

But dont bother now, not interested any more.

ohhh such a shame... we need more deserving fifo owners

exactly my point.

no it wasnt, it doesnt recover the clock, it uses a PLL to match to its own clock.

[qusp]

Originally Posted by Julf

Well, yes, it is a theory in the same sense as the laws of physics are a theory - it is not something that might or might not exist, it is just something that might or might not cause any practical issues.

My interest in it is that it is why a lot of people insist that a DAC system *must* use a sample rate converter. I don't agree with them - like you I feel it can be made to be a non-issue in practice, but that doesn't mean it isn't a real problem on a more formal level - unless there is something in the setup I have overlooked.

If you have a glass of water, with a very precisely measured and drilled hole that produces a very stable leak, if someone is constantly pouring in water into the glass at a rate that is slightly higher than your leak rate, the glass will fill up and overflow at some point, unless you can tell the person pouring the water to stop for a second.

ok yes agreed, it is a real phenomenon that is really happening to various degrees, its just yet to have any impact among the army of fifo owners, or at least if it has it hasnt been reported.

in its current form, if you used a crappy i2s source to listen to an epic entirely gapless (truly gapless single file) marathon 352.4kHz concert (even though something that can play 352.4 is unlikely to have such a bad clock) you may fill/empty the buffer.

it is possible, at which point Ian may think of a solution, the memory and processor is fast enough that it need not have any feedback other than knowing how full its own fifo is.

[Julf]

Originally Posted by qusp

all to solve a problem that doesnt impact on any real world use case

How about agreeing to "doesn't impact *most* real world use cases"?

[Julf]

Originally Posted by qusp

in its current form, if you used a crappy i2s source to listen to an epic entirely gapless (truly gapless single file) marathon 352.4kHz concert (even though something that can play 352.4 is unlikely to have such a bad clock) you may fill/empty the buffer.

Let's assume a 0.1% difference in clock frequency between the FIFO system and the source. I would assume the longest uninterrupted gapless piece of music would be something like one CD's worth of music, or 74 minutes. In those 74 minutes, you would be 4.5 s out of sync - so hopefully having 4.5 s of quiet to throw away, or having an extra 4.5 s break before the next song, depending if you are too fast or too slow. 4.5 s also requires a 800Kbyte buffer for 16/44.1, or 2.5 Mbytes for 24/96. I have no idea how big the buffer is on Ian's board, but the 4.5 s gap is the bigger problem anyway.

it is possible, at which point Ian may think of a solution, the memory and processor is fast enough that it need not have any feedback other than knowing how full its own fifo is.

I don't quite get what impact the processor and memory speed has on this.

[qusp]

Originally Posted by Julf

Let's assume a 0.1% difference in clock frequency between the FIFO system and the source. I would assume the longest uninterrupted gapless piece of music would be something like one CD's worth of music, or 74 minutes. In those 74 minutes, you would be 4.5 s out of sync - so hopefully having 4.5 s of quiet to throw away, or having an extra 4.5 s break before the next song, depending if you are too fast or too slow. 4.5 s also requires a 800Kbyte buffer for 16/44.1, or 2.5 Mbytes for 24/96. I have no idea how big the buffer is on Ian's board, but the 4.5 s gap is the bigger problem anyway.



I don't quite get what impact the processor and memory speed has on this.

the memory is in the MB range afaik, I cant remember exactly how big. search for this same conversation 6 months ago and you'll find it =)

the speed of the processor and memory has an impact in that it is fast enough to flush what it needs to in between clock ticks without needing a gap to do it in, because at the micro level from the point of view of the processor the music is already full of gaps. it needs to flush to half full, empty is no good, so it needs to know exactly how full/empty it is and flush exactly enough so that its half full on the next clock tick.

How about agreeing to "doesn't impact *most* real world use cases"?

haha, well when someone reports a real world use case where it actually DOES happen, i'm not really happy with most. how about 'all known real world use cases?'

[Julf]

Originally Posted by qusp

the speed of the processor and memory has an impact in that it is fast enough to flush what it needs to in between clock ticks without needing a gap to do it in, because at the micro level from the point of view of the processor the music is already full of gaps. it needs to flush to half full, empty is no good, so it needs to know exactly how full/empty it is and flush exactly enough so that its half full on the next clock tick.

Uh, I still don't get it. If the source clock is running slower than the FIFO, the FIFO can't just inject an empty time slot - just like it can't throw away data if the buffer is getting full. You can only flush/empty fill when you have a pause (totally silent) section in the music, no matter how fast your CPU or your memory.

[qusp]

ahh yes, sorry you are absolutely right. OK so perhaps the better way would be to have 2 fifos and shuffle between them as needed. assuming it ever becomes a problem. I think when we initially discussed that it was more to do exactly that, an emergency effort to insert silence instead of overrun/underrun.

I gather on the next version ie multichannel/DSD version, Ian is boosting the memory, so perhaps it will just become even more of a non-issue