@clsidxxl: Hi ... well, although not entirely a "boy" anymore 
I also find that it is unfortunate that Andrea cannot comment on this as I reckon he has thought about this. I will consider also posting my comments in thewellaudio forum, however, would like to add that my thoughts in the post above are not specifically aimed at TWT FIFO - which I BTW think is a very fine and versatile device - but at the FIFO thought/concept as such. Thus, more general comments on this subject.
Jesper
I also find that it is unfortunate that Andrea cannot comment on this as I reckon he has thought about this. I will consider also posting my comments in thewellaudio forum, however, would like to add that my thoughts in the post above are not specifically aimed at TWT FIFO - which I BTW think is a very fine and versatile device - but at the FIFO thought/concept as such. Thus, more general comments on this subject.Jesper
Hi all,
Just FYI I posted some of lasercut & my own thoughts/comments in a thread on the wellaudio forum. Link is here:
https://www.thewellaudio.com/forum/...-fifo-and-phase-noise-measurements/#post-1736
Cheers,
Jesper
Just FYI I posted some of lasercut & my own thoughts/comments in a thread on the wellaudio forum. Link is here:
https://www.thewellaudio.com/forum/...-fifo-and-phase-noise-measurements/#post-1736
Cheers,
Jesper
@gentlevoice
Saw what you wrote at the wellaudio forum. Just wanted to point out there is more going on with FFTs and transients than can be explained by averaging multiple FFTs. It can help a lot to develop some intuition by studying a graphical DFT procedure (considering that FFT is a fast way of calculating a DFT). Will attach a couple of files below. One file explains a method of graphical DFT analysis, the other file explains what windowing does to a dataset before a DFT is calculated from it.
Please consider what would happen if we had a glitch occur, say a record pop while we were digitizing a sine wave test track from a phono. Say we are taking 1024 samples that we will then analyze, and that the glitch lasts 100 samples. In the case the glitch represents about 10% of the data, so its spurs might show up pretty well in our DFT analysis. OTOH suppose we want very exact frequency resolution so we can see wow and flutter effects on the test tone we are sampling. Let's say we take 20M samples to analyze, and once again we have a 100 sample glitch. Now its a tiny part of the data, so its spurs may look a lot less significant after we perform the DFT. Its that more of an averaging effect occurs over time it takes us to collect 20M samples, say, as verses the time it would take to collect 1024 samples (assuming the same sample rate in both cases). Hopefully that makes sense.
The other effect has to do with windowing. What windows does is fade out the beginning and end of our set of samples before we apply a DFT. That means if our 100 sample record pop glitch happened near the beginning or end of our sample set, it would be discounted in the DFT calculation by how much it has been attenuated in level by the window function. Therefore its spurs might look bigger or smaller depending on when in time the glitch occurred.
Bottom line is there is always some tradeoff between resolution of time and resolution of frequency. Short time events show up better in short, quickly acquired sample sets, but frequency resolution is poor since we end up with only a small-ish number of relatively broad frequency bins. OTOH if we want very precise frequency resolution (lots of narrow bins), we need to take time to acquire a large set of sample points in order to do the calculation.
EDIT: Regarding graphical DFT, there are a couple of ways to do it. One is by solving simultaneous equations. The other way is by correlation. Both methods were used by EEs in the old days of slide rules and hand calculations. https://www.dspguide.com/ch8/6.htm
Saw what you wrote at the wellaudio forum. Just wanted to point out there is more going on with FFTs and transients than can be explained by averaging multiple FFTs. It can help a lot to develop some intuition by studying a graphical DFT procedure (considering that FFT is a fast way of calculating a DFT). Will attach a couple of files below. One file explains a method of graphical DFT analysis, the other file explains what windowing does to a dataset before a DFT is calculated from it.
Please consider what would happen if we had a glitch occur, say a record pop while we were digitizing a sine wave test track from a phono. Say we are taking 1024 samples that we will then analyze, and that the glitch lasts 100 samples. In the case the glitch represents about 10% of the data, so its spurs might show up pretty well in our DFT analysis. OTOH suppose we want very exact frequency resolution so we can see wow and flutter effects on the test tone we are sampling. Let's say we take 20M samples to analyze, and once again we have a 100 sample glitch. Now its a tiny part of the data, so its spurs may look a lot less significant after we perform the DFT. Its that more of an averaging effect occurs over time it takes us to collect 20M samples, say, as verses the time it would take to collect 1024 samples (assuming the same sample rate in both cases). Hopefully that makes sense.
The other effect has to do with windowing. What windows does is fade out the beginning and end of our set of samples before we apply a DFT. That means if our 100 sample record pop glitch happened near the beginning or end of our sample set, it would be discounted in the DFT calculation by how much it has been attenuated in level by the window function. Therefore its spurs might look bigger or smaller depending on when in time the glitch occurred.
Bottom line is there is always some tradeoff between resolution of time and resolution of frequency. Short time events show up better in short, quickly acquired sample sets, but frequency resolution is poor since we end up with only a small-ish number of relatively broad frequency bins. OTOH if we want very precise frequency resolution (lots of narrow bins), we need to take time to acquire a large set of sample points in order to do the calculation.
EDIT: Regarding graphical DFT, there are a couple of ways to do it. One is by solving simultaneous equations. The other way is by correlation. Both methods were used by EEs in the old days of slide rules and hand calculations. https://www.dspguide.com/ch8/6.htm
Last edited:
...Ok, I tried this...Nt130 vs. Alix. Unfortunately...still the same result: The Alix combo with sotm card and mpdpuppy is much nore natural and life life like than the nt130...same Nas, same Lan Cable, same USb cable. So...no, the fifo is NOT making u independent of whatever happens before the fifo. The better the source, the better the sound...i would have loved to reported differently...it is simply not the case.
Magnitude wise it is above the difference the clocks make. So, independently of theories...try it yourself...and when enough people share the same observation besides my 5ct...maybe Andrea goes for a sonic empire source player as well...i would see this currently as the biggest improvement option...a solution where the clocks and the data stream are integrated from the very beginning...well...i might even now try the sdcard player to understand sensitivities...and i really hate this thing.
A FIFO can only do certain things. Mainly, tt can remove clock jitter presented to it. It may also be able to remove ground (common mode) noise. It can't undo permanent damage already done from jitter in prior processing, from resampling, etc. Can't fix anything already altered/distorted in terms of the digital audio data. Regarding Bluetooth product sound, it may already lossy compressed and or resampled, say, maybe in some cases to 16/48. Once its done, its done. Can't be undone by a FIFO.
Thanks for all the reporting.
Negative feedback is appreciated as much as good, shows you are honest, have some ability to use your ears critically and resist certain cognitive biases to an extent.
Can explain in more detail how you connect these devices to FIFO?
Is TWSAFB-TX and TWSAFB-RX used or any isolator before FIFO?
Also, how much distance between source and audio system, assuming isolation?
I recall Andrea saying any RFI sources like Rpi4 should ideally be in a different room.
Whether it was just general good practice or he measured/observed something idk.
Isolation and seperation seems to be the primary differences between FIFO lite and Top version they are working on.
Negative feedback is appreciated as much as good, shows you are honest, have some ability to use your ears critically and resist certain cognitive biases to an extent.
Can explain in more detail how you connect these devices to FIFO?
Is TWSAFB-TX and TWSAFB-RX used or any isolator before FIFO?
Also, how much distance between source and audio system, assuming isolation?
I recall Andrea saying any RFI sources like Rpi4 should ideally be in a different room.
Whether it was just general good practice or he measured/observed something idk.
Isolation and seperation seems to be the primary differences between FIFO lite and Top version they are working on.
Last edited:
Well, the Bluesound is used with the new USB-Output Mode...the same USB-Cable, the same LAN Cable is used. Its always on and next to my Alix, so: If it would be a RFI source, it should pollute the Alkx as well all the time. No, It output the same, unchanged resolution as the Alix, no resampling.
But I complely agree with the principle: If data somehow is changed...on a a much more microlevel be it now jitter or not...This destroys the aura of "Life-like"...thats the best way to describe it. And Abdrea DAC makes the difference even bigger /more clearly audible than the soekris did...as it is so transparent.
So, my hope would be we can at some point of time a source which is integrated with the FiFo, which uses the clocks of the fifo and its i2s interface directly (above Alix-quality), ideally open for Linux (and not a Mini PC designed for general purpose be it Raspberries or NUCs etc.
The potential in SQ is certainly there.
But I complely agree with the principle: If data somehow is changed...on a a much more microlevel be it now jitter or not...This destroys the aura of "Life-like"...thats the best way to describe it. And Abdrea DAC makes the difference even bigger /more clearly audible than the soekris did...as it is so transparent.
So, my hope would be we can at some point of time a source which is integrated with the FiFo, which uses the clocks of the fifo and its i2s interface directly (above Alix-quality), ideally open for Linux (and not a Mini PC designed for general purpose be it Raspberries or NUCs etc.
The potential in SQ is certainly there.
Last edited:
Thank you Blitz,yes report appreciate,
I'm starting to look for a source worthy of the name,After 15 days of research, it seems that nothing beats an SD card reader,
As soon as available I would replace my Odroid/Volumio by a Mercury streamer,Very close to the sdtrans but more friendly.
I'm starting to look for a source worthy of the name,After 15 days of research, it seems that nothing beats an SD card reader,
As soon as available I would replace my Odroid/Volumio by a Mercury streamer,Very close to the sdtrans but more friendly.
I dont want to go off topic here...but I believe the initial philosophy why SDCard reader sound so good is...low power consumption...low EMF....low overhead...minimum hardware processing power/slow CPU or none etc...just enough to get the data out....lots of overhead is simply not there.
I have tried a lot of machines bigger PC or Laptops or Macs or Midi or smaller Nucs, windows, Macos, Linux...Volumio, Dietpi, Mpdpuppy etcetc...And finally I think the slower the better...the old Alix1D board has just enough to get Puppy up and running,,, much slower than a raspberry...I tried RP3/4 with Allo Usbsignature Board (or however they call it), with Ian Fifo and battery supply....all nice, cant match the old hardware....so you see, i really tried hard to get rid of it (and to get to a streaming capable software)....
I am pretty sure if a capable designer take from the design philosophy a Sdcard reader as a basis and than adds up stuff only where its needed...so an ultraslow machine, just good enough to receive PCM Data from a NAS and give it out in I2S...maybe even without a big OS like Linux...that would be it..that could beat my Alix/Sotm...not sure if the Mercury streamer will do this...looks overpowered to be honest.
I have tried a lot of machines bigger PC or Laptops or Macs or Midi or smaller Nucs, windows, Macos, Linux...Volumio, Dietpi, Mpdpuppy etcetc...And finally I think the slower the better...the old Alix1D board has just enough to get Puppy up and running,,, much slower than a raspberry...I tried RP3/4 with Allo Usbsignature Board (or however they call it), with Ian Fifo and battery supply....all nice, cant match the old hardware....so you see, i really tried hard to get rid of it (and to get to a streaming capable software)....
I am pretty sure if a capable designer take from the design philosophy a Sdcard reader as a basis and than adds up stuff only where its needed...so an ultraslow machine, just good enough to receive PCM Data from a NAS and give it out in I2S...maybe even without a big OS like Linux...that would be it..that could beat my Alix/Sotm...not sure if the Mercury streamer will do this...looks overpowered to be honest.
I agree with Blitz on the SD benefits after trying everything I could throw at USB solutions for years. SD still has limitations as there is a clear audible difference listening to the same tracks played from MLC SD Cards compared to the more expensive but superior SLC Cards.
My ideal front end would be a board with a large array of SLC Nand chips controlled by a modified and stripped down SD Protocol for audio playback only...here's hoping someone does it someday.
Back on topic SLC SD music playback through Andrea's FIFO and DAC sound wonderful here and the benefits outweigh having to load music on SD cards, I can fit about 40 redbook albums in FLAC on 16Gb SLC cards.
I recently added 2 x 500F super capacitors on each of the 3.3v vref supplies to the DAC Lite and it made an improvement to sound presentation. Lows and mids have more body and presence. A very worthwhile addition if you are comfortable working with supercaps.
My ideal front end would be a board with a large array of SLC Nand chips controlled by a modified and stripped down SD Protocol for audio playback only...here's hoping someone does it someday.
Back on topic SLC SD music playback through Andrea's FIFO and DAC sound wonderful here and the benefits outweigh having to load music on SD cards, I can fit about 40 redbook albums in FLAC on 16Gb SLC cards.
I recently added 2 x 500F super capacitors on each of the 3.3v vref supplies to the DAC Lite and it made an improvement to sound presentation. Lows and mids have more body and presence. A very worthwhile addition if you are comfortable working with supercaps.
I took a similar path. It was clear the best sound comes when the device providing the bit perfect stream to the DAC or FIFO has the least processing ability and the software has the minimum footprint. I also used an Alex 1D with MPDPUPPY and its was very good. Earlier, like many here I followed the CICS/CMP path of cutting WinXP to its bare core. Just enough to boot and supply bits to run the DAC. Every cut had clear sound improvement. Now, even with FIFO, there is a clear difference in sound based on the player on the Rpi. I believe it all comes down to reducing the number of interrupts on the processor resulting in less noise. I wish some smart Linux guy would create a minimalist Linux/MPD distro. Forget all the UI, streaming and DSP. Just accept enough to run ethernet and produce bits to FIFO. Then put it on the least functional Rpi. Just ethernet input.
I don't buy the theory of some kind of error in the bit stream. At the end of the day bit perfect data gets to the FIFO buffer, and FIFO is the thing that generates the bit stream to the DAC that makes the music. We are listening to a FIFO/DAC. Everything before it is logically isolated. Does not make a difference to the data stream if the bits were on a hard drive, streamed from the internet or on a memory stick. The data is the data. So, it has to be the noise that impacts the sound. I suspect Andrea is on the right track to isolate all this stuff.
These setups are fragile from a sound quality perspective. I can clearly see an impact on sound based on the clock cable and its connectors, the ethernet cable, usb cables and the ufl cables. Again, makes no sense but it's clearly audible.
To get the best sound, you need minimal processors that are well shielded and isolated. All the digital cables need strong shields, proper connectors and proximity matters. Vibration matters. At some point I have to think that a good case would be more beneficial than leaving all this stuff spread around on a table. People scoff at the expensive gear being in cases carved out of billet copper, but it might be that final icing on the cake combined with isolation feet.
Using I2SoverUSB here in WASAPI Exclusive Mode with the latest Thesycon drivers. It is galvanically isolated to begin with. USB board is powered from its own regulator and isolated R-core transformer winding. A long USB cable (20' ?) connects it to an old, slow laptop that uses WiFi networking. Laptop power supply is connected though a power conditioner with a big common mode choke which keeps AC line noise from getting into the laptop. DAC_Lite is inside an old emptied out steel file server case to protect it from environmental EMI/RFI. Every power supply rail for the dac has its own dedicated regulator running from its own dedicated transformer winding. Power rails are only grounded at the DAC_Lite loads. Seems to work fine.
I initially bought a Panasonic SLC card but very expensive. Found some Integral Endurance 16Gb cards but rare and hard to find at times. Found some INDMEM 2Gb recently but again hit and miss finding these too. I have a good collection now so no need to keep searching
Memory devices tend to draw current from their power supply in intermittent and noisy way. A resulting problem with modulation of a computer power supply is well known to cause clock jitter, and or noise on the ground rail. That's why the computer (or RPi) ground should be sufficiently isolated from DAC_Lite I2S input ground. One stage of galvanic isolation, such as found in I2SoverUSB, should help quite a bit. If I were using RPi, it would use it over USB to DAC_Lite, and NOT using the RPi GPIO bus which is very noisy.
That is my experience as well...but on the soekris...USB sounded better than I2S direct when connecting even through Ians Fifo etc (which I believe is isolated). I use with the fifo/dac from Andrea currently the i2soverusb...
Sligolad, thx for the hint, just bought a SLC card and will get my rusty sdtrans384 going and see what will happen compared to the Alix-Setup. The fifo/DAC of Andrea makes anything much more clearer and more audible...like a magnifying glass...
In the meantime I found that Sotm actually has designed two streaming devices (sotm 200 and 200ultra), which really is not a NUC in a new enclsoure, but designed by them from ground / own PCB etc...I asked the german distributor if I can have one to compare...my sotm card in the Alix was an important upgrade....so, lets see...
Sligolad, thx for the hint, just bought a SLC card and will get my rusty sdtrans384 going and see what will happen compared to the Alix-Setup. The fifo/DAC of Andrea makes anything much more clearer and more audible...like a magnifying glass...
In the meantime I found that Sotm actually has designed two streaming devices (sotm 200 and 200ultra), which really is not a NUC in a new enclsoure, but designed by them from ground / own PCB etc...I asked the german distributor if I can have one to compare...my sotm card in the Alix was an important upgrade....so, lets see...
This all sounds to me that you have issues with your USB-to-I2S device. With my USBI2S bridge I can playback and record 32-bit wav files to 32-bit perfection in I2S loopback regardless of host (windows/linux) or usb cable (provided that the cable is HS-capable). That also includes any devices prior to host (NAS or ethernet cables). The I2S stream is isolated from host but what comes after I2S is another issue altogether. There clocking, shielding, cables etc. can have real impact.