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...
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...
Last edited:
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.
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.
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.
exactly my point.
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.
sorry but yes, this exact conversation has been had more than a few times.
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
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.
ohhh such a shame... we need more deserving fifo owners
no it wasnt, it doesnt recover the clock, it uses a PLL to match to its own clock.
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.
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.
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?'
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.
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
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
Last edited:
Not sure that helps in any way - you are still back to the issue of only being able to discard/fill in material in the quiet pauses.
Unfortunately it won't suddenly become a problem. Some users (with greater clock frequency mismatch) will occasionally run into it (when playing long, uninterrupted pieces of music), others won't - so it will be hard to replicate/verify the complaints.
More memory will make it more likely that you will stop listening to the music and go to bed before the buffer under/overflows, thus solving the problem
Hi! if we take the example from Julf a 0.1% difference between source /reclock clocks
Worst case for 44.1Khz:
44100 (sample F)x 32bit (Spdif encaps 16bits) x2 (channel)=2822400 bits/s
half fifo (4M/2) = bits
2048000/2822400 = .73 seconds buffer
.1% error would be 2822 under/over samples /s
the fifo would underrun in 2048000/2822 = 725s = 12 minutes
So since no regulation mecanisme is implemented in the fifo this would leave us with 62 minutes of 'jiterisched' music after 12 minutes ;-)
But +-.5% mean error on frequency precision is normaly seem on clock using a resonnator.
Even a 1000Ppm clock module is +-0.001% ;-) and even then +-0.001% is not a error of +.001% but a error between -0.001% to .001%
Correct me if I'm wrong but I thing we have at least one order of magnative of safety margin event at 384khz.
Worst case for 44.1Khz:
44100 (sample F)x 32bit (Spdif encaps 16bits) x2 (channel)=2822400 bits/s
half fifo (4M/2) = bits
2048000/2822400 = .73 seconds buffer
.1% error would be 2822 under/over samples /s
the fifo would underrun in 2048000/2822 = 725s = 12 minutes
So since no regulation mecanisme is implemented in the fifo this would leave us with 62 minutes of 'jiterisched' music after 12 minutes ;-)
But +-.5% mean error on frequency precision is normaly seem on clock using a resonnator.
Even a 1000Ppm clock module is +-0.001% ;-) and even then +-0.001% is not a error of +.001% but a error between -0.001% to .001%
Correct me if I'm wrong but I thing we have at least one order of magnative of safety margin event at 384khz.
Last edited:
...just send back the MCLK to the source..
FIFO buffer will isolate anyway from the source jitter, even with the worst source
no memory underflow/overflow since the source will work with the same master clock.
No PLL needed, 1MB memory is safety enough.
and don't tell me you cannot tweak the source, we are diyers
FIFO buffer will isolate anyway from the source jitter, even with the worst source
no memory underflow/overflow since the source will work with the same master clock.
No PLL needed, 1MB memory is safety enough.
and don't tell me you cannot tweak the source, we are diyers
yeah this fifo memory is far too linear!
well yes it will 'suddenly' become a problem, because presumably at some point, someone, anyone! will suddenly report actually.... having a problem. until then there is effectively no problems
only potential problems. very much like Schrödinger 
given ryanj has been using a cheap chinese SD player with fifo and not made a report, i've used it with no less than 5 different sources and even during long jam sessions in Logic audio and internet radio over a period of more than a year...no problem and I gather the worst thing that can happen is it will either have a segment of silence, or will replay a segment.
most people by the time theyve got to the point of buying the fifo, already have a reasonable source
More memory will make it more likely that you will stop listening to the music and go to bed before the buffer under/overflows, thus solving the problem
yup =)
due to fifo memory buffer it is asyncronous with the source, it has to be, but I suppose it could simply be marching in time, but still offset in time. me, I wont bother doing anything about it or expending any effort or money on the problem that hasnt shown itself
fridrik 1000ppm is 1/1000th or 0.1% but honestly who is using anything like a 1000ppm clock with fifo? most will be using 50ppm so 0.005%
Last edited:
@Julf
First page fourth post says:
"- Half-full over flow time: 1486 seconds (at 44.1KHz input I2S stream with 500ppm frequency tolerance);"
The most crappy clocks for audio frequencies I could find have +-120ppm tolerance. If your source happens to have one of those and its really on its ppm limit then the FIFO will over/under run in 6181 second (~103 minutes) of continuous play... be serious, even Beethoven's 9th symphony is shorter played in one continuous stream.
If you think a PLL with a VCXO would be a better solution you are wrong since most VCXOs have less pull range: e.g. TentLab's VCXOs have +-100ppm, so those will not even work.
First page fourth post says:
"- Half-full over flow time: 1486 seconds (at 44.1KHz input I2S stream with 500ppm frequency tolerance);"
The most crappy clocks for audio frequencies I could find have +-120ppm tolerance. If your source happens to have one of those and its really on its ppm limit then the FIFO will over/under run in 6181 second (~103 minutes) of continuous play... be serious, even Beethoven's 9th symphony is shorter played in one continuous stream.
If you think a PLL with a VCXO would be a better solution you are wrong since most VCXOs have less pull range: e.g. TentLab's VCXOs have +-100ppm, so those will not even work.
Last edited:
I think it should be a reasonable fallback to have the reclocker stop once it detects under or overflow, refill it to half again and continue, providing silence for those few seconds. Preferably providing a LED status indicator as to what happened. I would personally find it a good tradeoff. Adding a VCXO with a PLL trying to pull the frequency average to be the same as the source is the ultimate solution but it has its own issues (how good will the PLL filter be? It needs to have a sub-Hz cutoff and the cutoff needs to be steep enough otherwise we're back at square one with jitter).
What does the FIFO do right now when it hits buffer over or under run?
What does the FIFO do right now when it hits buffer over or under run?
Sorry your correct 0.1% , the exemple was simply to demonstrate the worst case : 500ppm (worst crystal of the 1990) x 2.
100ppm should be the most probable worst case scenario . If I take my computation this would mean :
about 120 minutes = 44.1 mhz
about 14 minutes = 384 mhz
The ways the get under or over buffer are then
1- play long classical musique piece at very high sample rate
2- play a long play list with the gapeless mode ON in your player setting.
to conclude:
For most of us the under of over buffer condiftion is no concern in theory and in practice ;-)
Last edited:
Agree.
The worst audio clock I have ever met was from a CDROM, but it still better than 100ppm. Clocks from most of the digital audio sources we are running right now will be better than 30ppm, which including the CD players and many USB sound cards. If they are talking about 50ppm, that means it's over a wide temperature range, says 0-55 degree C. At room temperature, situations will be much better.
So, I'm just wondering what kind of worse digital source we are gonna feed to a FIFO?
There are more than 100 members running the FIFO now, so, maybe they can tell if they have experienced empty/overflow? if so, at what condition, and what was happened. While I did R&D, I can only simulate these cases by a programmable clock generator with running at much higher or much lower frequency.
VCXO can be a kind of solutions if don't care about jitter. VCXO usually comes with bigger jitter than a XO (except very expensive high end VCXO). For example, Si570 is a XO with phase noise -112dBc/Hz at 100Hz, however, Si571 is a VCXO, the phase noise is degraded to -87dBc/Hz at 100Hz. The reason is obvious: the noise on the control voltage will be converted into jitter.
Just a personal point
Ian