Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter - Page 181 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 2nd January 2013, 10:28 AM   #1801
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
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...

Last edited by qusp; 2nd January 2013 at 10:38 AM.
  Reply With Quote
Old 2nd January 2013, 10:58 AM   #1802
Julf is offline Julf  Europe
diyAudio Member
 
Join Date: Oct 2011
Location: Amsterdam, The Netherlands
Quote:
Originally Posted by qusp View Post
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.
  Reply With Quote
Old 2nd January 2013, 01:11 PM   #1803
percy is offline percy  United States
diyAudio Member
 
Join Date: Apr 2004
Location: MN
Quote:
Originally Posted by qusp View Post
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.

Quote:
Originally Posted by qusp View Post
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.

Quote:
Originally Posted by qusp View Post
from the datasheet
synchronize a clock generated from a PLL and high quality oscillator to incoming S/PDIF data stream
exactly my point.
  Reply With Quote
Old 2nd January 2013, 03:09 PM   #1804
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
Quote:
Originally Posted by percy View Post
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.


Quote:
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.

Quote:
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


Quote:
- 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.

Quote:
But dont bother now, not interested any more.
ohhh such a shame... we need more deserving fifo owners




Quote:
exactly my point.
no it wasnt, it doesnt recover the clock, it uses a PLL to match to its own clock.
  Reply With Quote
Old 2nd January 2013, 03:22 PM   #1805
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
Quote:
Originally Posted by Julf View Post
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.
  Reply With Quote
Old 2nd January 2013, 03:26 PM   #1806
Julf is offline Julf  Europe
diyAudio Member
 
Join Date: Oct 2011
Location: Amsterdam, The Netherlands
Quote:
Originally Posted by qusp View Post
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"?
  Reply With Quote
Old 2nd January 2013, 03:30 PM   #1807
Julf is offline Julf  Europe
diyAudio Member
 
Join Date: Oct 2011
Location: Amsterdam, The Netherlands
Quote:
Originally Posted by qusp View Post
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.

Quote:
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.
  Reply With Quote
Old 2nd January 2013, 03:37 PM   #1808
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
Quote:
Originally Posted by Julf View Post
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.

Quote:
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?'
  Reply With Quote
Old 2nd January 2013, 03:45 PM   #1809
Julf is offline Julf  Europe
diyAudio Member
 
Join Date: Oct 2011
Location: Amsterdam, The Netherlands
Quote:
Originally Posted by qusp View Post
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.
  Reply With Quote
Old 2nd January 2013, 04:18 PM   #1810
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
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

Last edited by qusp; 2nd January 2013 at 04:23 PM.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
XMOS-based Asynchronous USB to I2S interface Lorien Digital Source 2113 26th July 2014 06:52 PM
exaU2I - Multi-Channel Asynchronous USB to I2S Interface exa065 exaDevices 1357 3rd March 2014 08:51 PM
DAC chip selection + I2S jitter questions drwho9437 Digital Line Level 2 26th July 2010 12:50 PM
Simple FIFO to I2S CPLD, for MCU players / reclocking KOON3876 Digital Line Level 21 19th September 2008 04:00 PM
asynchronous reclocking and low jitter clocks ash_dac Digital Source 3 8th February 2005 09:22 AM


New To Site? Need Help?

All times are GMT. The time now is 06:23 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2