Well, it can be observed to some extent with a scope or an RF spectrum analyzer. For a scope you can tie the probe ground clip to the probe tip and use the ground lead like a little loop antenna. Wave it around the USB board chips and wave it around the dac chip. As you get closer to the chips you pick up more radiated stray coupling.
To hear the effect on SQ you can wire the USB board so that you can move it around a little, say, closer to the dac chip (or the FIFO buffer chips), or turn it away, etc. What it sounds like is sort of a type of jitter. Jitter can have a lot of different effects on sound depending on the exact jitter waveform (the particular clock phase variation as a function of time). Some types of jitter measurement equipment can FM or PM demodulate the clock phase over time and its possible to then listen to the jitter waveform. IIUC a Timepod doesn't work that way, but some other equipment can do it.
I tried to connect the sdtrans384 to the fifo...wave mode...no music...(yes, it shows it is playing the files with resolution etc)...are there different i2s dialects ? sdtrans speaks I2S*2 LRCK (fs), MCLK (22.5792 or 24.576 MHz), DCLK (64 fs), SDAT +3.3V CMOS level output...? I remember there was something about right-justified data or left-justified data (in theory)...but sofar have no experience with that, never came across that bridge before...if i got it right, sdtrans384 output Left justified...with the "LSB extension algorithm"...what ever this means...can Andreas Fifo understand that dialect ?
Last edited:
well, I regard the fifo/dac of Andrea as a unit...i wont now tear it apart...the signal has to go through the fifo to enjoy the clocks as well etc....not even sure how to operate the dac without the fifo/clocks....
BTW...got the sotm streamer from the german distributo r to try:
Very impressive. Much better than Bluesound or anything on Raspberry (incl. Allo or Ians hacks...sorry to say.). It comes as close as it can to my Alix 1D/Sotm usb card with different areas of gravity:
Anyway, thats why i wanted to get the sdtrans now working to destroy the Alix setup and show what the real golden standard is...SLC cards are im the house as well now...
...and for me its clear: there is a missing piece of eqipment... a streamer at the quality level of the fifo/dac of Andrea...as all the differences are very audible despite his fifo efforts...anyone trying to discuss this has no practical experience. Just try it yourself.
Very impressive. Much better than Bluesound or anything on Raspberry (incl. Allo or Ians hacks...sorry to say.). It comes as close as it can to my Alix 1D/Sotm usb card with different areas of gravity:
- First, No way to use it without a good PSU. The Sotm 500 PSU brought both units to the adult game, before i would not even bother.
- I like the smaller SmS-200 better than the ultra version.
- the smaller version is more natural but still adds more resolution than my Alix 1D setup from an analytical POV...so if you like hifish way of listening, you will prefer it to my Alix 1D/Mpdpuppy.
- the ultra sounds even more analytical, but more like a Pc-Board (which it is). Thinner. more analytical. More technical. Not my cup of tea. Those reviewers who wrote it a clear improvement to the normal sms-200...well what can i say...its a business.
- For me the winner still is the Alix 1 D with Sotm card. Transients are still vibrating through the room. wood instruments like a cello sound like wood...it is not the same resolution in the trebles like the sotm streamers, but much better in the mids and bass..much more lifelike to my taste...
Anyway, thats why i wanted to get the sdtrans now working to destroy the Alix setup and show what the real golden standard is...SLC cards are im the house as well now...
...and for me its clear: there is a missing piece of eqipment... a streamer at the quality level of the fifo/dac of Andrea...as all the differences are very audible despite his fifo efforts...anyone trying to discuss this has no practical experience. Just try it yourself.
Last edited:
Well, the initial fifo for the raspbery with pulsar clocks and his batterysupply mk1 ontop of a Rpi4 and later ontop of allo usbbridge signature which was an improvement over Rp4...with different mini linux distros, some LMS, some MPD based...in the end dietpi with MPD as Archphile was not stable at the time...
I own different versions of his MCfifo (not for Raspberry) as well...used them years ago with the Buffalo DACs...so I like his stuff clearly, but I have my doubts that Raspbery is the audiophile basis we are looking for...the Sotm 200 Player is designed from scratch just for the purpose of Good UsB Audio, which it delivers...I will use the time now to compare Hqplayer and the Sotm as NAA which it brings with it...lets see what happens there...never tried that before.
I own different versions of his MCfifo (not for Raspberry) as well...used them years ago with the Buffalo DACs...so I like his stuff clearly, but I have my doubts that Raspbery is the audiophile basis we are looking for...the Sotm 200 Player is designed from scratch just for the purpose of Good UsB Audio, which it delivers...I will use the time now to compare Hqplayer and the Sotm as NAA which it brings with it...lets see what happens there...never tried that before.
Is anyone using HQplayer btw in combination with this FIfo/DAC (I guess with DOP of i2soverusb) ?
Regarding streamers, is there a pic of the streamer as it is connected to the FIFO? Are they in a box, open air, what? Is there a power supply interconnection diagram? How is the grounding setup? I'm still trying to figure out why some people are reporting all these things end up producing different sound. One possible culprit is likely stray coupling of EMI/RFI between the streamer and the FIFO. I have seen a similar problem with RPi, Ian's stacks, etc. Its pretty easy to miss a problem if not used to investigating that type of thing.
Incidentally @Blitz I had the SOTM 200 for a while a few years ago. It's worth tweaking if you don't mind opening it up. I replaced the psu inside with a Paul Hynes regulator and then swapped the onboard clock for an external clock (it probably was a neutron star at that point) and then I upgraded the power supply to the USB chip. It sounded excellent but was then bested by removing USB from the signal path and using I2S.
I agree that the streamer element is the least explored. Acko is working on one that I know of but don't know of any others in the pipeline.
I agree that the streamer element is the least explored. Acko is working on one that I know of but don't know of any others in the pipeline.
What do you mean exactly? Doesn't a USB board output I2S? What USB device were you using? How was it powered? Where was it located in proximity to the dac? All those little details (and more) can matter. Not wise to ignore little details (and or bigger ones) when going for the best possible SQ.
Last edited:
Apologies - not entirely clear. What I meant to say was that I previously had USB input to my DAC but when I stripped it out and went directly from I2S output from a pi to I2S input on a fifo board, this sounded significantly better than all previous iterations of my system when I had a USB interface at the primary input to my DAC.
Believe me when I say that there was no ignoring the little details when it came to optimising the USB input or what fed it. For the USB board, I started by using a waveio (https://luckit.biz) which was excellent 10 years ago (I'm guessing...but could easily be). This was connected using u.fl connections directly to one of Ian's early FIFO boards before heading for the DAC chips. Short u.fl. cables. Everything powered by Paul Hynes regs. The waveio got replaced with a variety of alternatives but the final USB card I had was the sonore https://www.audiocircle.com/index.php?topic=127689.0 - easily the best usb / i2s card I owned. Anyway....as I say, it got removed. I've avoided USB for about 4 years but I like the idea of the jlsounds card being able to take a master clock connection so I bought one to experiment with. I am going to use the multiple inputs of Andrea's FIFO card to play the USB to I2S off against the Pi I2S (The Pi I2S output uses Ian's fifo pi etc so that it's already been re-clocked) ...need to dust off that SOTM streamer ... or put a down payment on the new mercury that I saw last night...looks pretty good.
Happy to elaborate with some pics if it'll help to visualise!
Probably we can figure out what's wrong with your USB and fix it. There are various ways to get started doing that. What I would do if I were there in person would probably be to take a look at how you have everything laid out and interconnected. Might take some measurements too. At some point would probably perform one or more experiments to 'tease out' whatever it is that going on when you try to use USB. One of the things I would certainly do is find out how everything is grounded.
For example you clock oscillator grounds are probably directly connected to your power amplifier ground. A path should exist through the FIFO and dac boards via the LRCK u.fl coax ground that eventually makes it to the power amp signal input ground. Question might be is that the only ground path between the clocks and the power amp? Is there some path through power supply safety grounds, for example?
What about grounds when a USB board is added? Anything change then? Since the FIFO as multiple I2S inputs, what if a USB board is connected to one of the I2S inputs, but that input is not the one you are using. Does the mere act of connecting the USB board to an unused FIFO I2S input change the sound? What if the USB cable is unplugged? What if the USB board power is disconnected?
This sort of thing is just basic troubleshooting, even if we believe everything was hooked up perfectly. If there is a problem with the sound, we still have check for hidden or unexpected problems.
Another thing I would probably do is look at the EMI/RFI noise emissions in the area where the dac is. In particular around the FIFO board chips and any USB board chips. Instrumentation for that could be a scope, a wideband shortwave radio receiver, an RF spectrum analyzer, etc.
Also would try to identify all SMPS in the system. A computer almost always uses a SMPS, but it may not be the only thing that does. They can be common sources of electrical noise that could adversely affect a sound system.
Another thing to check for is stray coupling of RFI/EMI as determined by experimentation, say, by increasing stray coupling until its clear what that does to the sound. Then reduce it to a minimum. It can be surprising the lengths one may need to go to in order to seriously minimize radiated coupling.
Another problem could be capacitive coupling between grounds, even if no DC ground path exists. There are experiments that can be done to check for that.
Anyway, a good way to get started figuring out what's most likely going on with USB would probably be if we could see pics of the equipment layout, and an interconnection diagram of known grounds (both signal and AC power grounds). A DVM can be used to verify no other DC ground paths exist between equipment, as a double check.
For example you clock oscillator grounds are probably directly connected to your power amplifier ground. A path should exist through the FIFO and dac boards via the LRCK u.fl coax ground that eventually makes it to the power amp signal input ground. Question might be is that the only ground path between the clocks and the power amp? Is there some path through power supply safety grounds, for example?
What about grounds when a USB board is added? Anything change then? Since the FIFO as multiple I2S inputs, what if a USB board is connected to one of the I2S inputs, but that input is not the one you are using. Does the mere act of connecting the USB board to an unused FIFO I2S input change the sound? What if the USB cable is unplugged? What if the USB board power is disconnected?
This sort of thing is just basic troubleshooting, even if we believe everything was hooked up perfectly. If there is a problem with the sound, we still have check for hidden or unexpected problems.
Another thing I would probably do is look at the EMI/RFI noise emissions in the area where the dac is. In particular around the FIFO board chips and any USB board chips. Instrumentation for that could be a scope, a wideband shortwave radio receiver, an RF spectrum analyzer, etc.
Also would try to identify all SMPS in the system. A computer almost always uses a SMPS, but it may not be the only thing that does. They can be common sources of electrical noise that could adversely affect a sound system.
Another thing to check for is stray coupling of RFI/EMI as determined by experimentation, say, by increasing stray coupling until its clear what that does to the sound. Then reduce it to a minimum. It can be surprising the lengths one may need to go to in order to seriously minimize radiated coupling.
Another problem could be capacitive coupling between grounds, even if no DC ground path exists. There are experiments that can be done to check for that.
Anyway, a good way to get started figuring out what's most likely going on with USB would probably be if we could see pics of the equipment layout, and an interconnection diagram of known grounds (both signal and AC power grounds). A DVM can be used to verify no other DC ground paths exist between equipment, as a double check.
Last edited:
Mark,
I think the EMI-Path is for sure the right direction to explain differences...maybe as well the cleaness of the voltage transmitted from the USB-Output to the Xmos-Chip to power it a second topic...EMI meant in a broader way: How is the board of the streamer designed...there has been in the old days agreement to underclock and undervoltage the CPU and try to switch off as many devices on the board as possible to lower power consumption....with the target to lower EMI etc...
Com, I think we are on the same page here...and if I remember right, wlowes was very active in those MPdpup /waveio days as well as was Dynobot...I just leanred that the magic nrpacks parameter has been taken of our playground to tune the USB-interface...what a pitty.
I thought as well: I2S directly...instead using USB for I2S, but my experiments with the soekris dam1941 with direct (unisolated) i2S was disappointing me. BUt, with Andreas's DAC, I might try it again...if you still got the sonore and want to sell, let me know...I am curious.
I am not sure if we should not open a new thread to discuss our sources findings, but this FIFO/DAC makes the difference so incredibly clear I feel I like at least to share with you my latest findings:
- Got the Sdtrans384 working (on battery/powerbank). Yes, SD-Cards do sound differently. NOt sure if this comes from the fat vs fat32 formatting or the SLC vs. MLC etc. SLC sounds a bit stiffer, more transparent while the Samsung MLC sounds warmer. It is in the magnitude of a mullard vs a Telefunken tube, so audible.
- TRied the Sotm 200 and ultra with external PSU: liked the smaller better, the ultra sounds again more transparent, but like a windows PC style (read: technical sounding) while the smaller is a bit more beefier...but it still has a certain grain/haze...all done with MPD...the sdtrans384 was clearly better
- I could not resist and wanted another reference to compare to. So I got my old Odroid C2 out and put Dietpi on it with MPD only (and lighttpd). That was a BINGO !!! I was very suprised. The Odroid in stock condition seems to beat any RP-derirvate (RP3/4/Allo Usbbrige sign/ IAn FIFO with battery supply) I have here in the house...I will compare it again backwards...but I was very impressed.
The nice thing on DIetpi/Odroid(on a powerbank, so battery) is that you:
I was really surprised as I did not expect anything more than RP-Performance or less. But there seem to be audible difference between those little boards, how they got designed, how their USB/LAN-Integration works etc. I am by far not at the level of DYNOBOT (miss him)...I am not a Linux-Interrupt-Optimizer-TYpe of Guy.
But what I will do now is...play with it.
I ordered a bunch of SoCs from Odroid like the bigger brother C4, M1, Xu4 etc as all of them got different CPU/Chips on board...plus some NEoPi (funny little headless board with onyl a LAN and an USB-Connector as few components as possible with a CortexA53), BEaglebone and others.
I will for comparison reason try to get Debian/Dietpi/MPD to run on them with the same principles (like slow CPU, battery supply etc.). And than see how much difference is between them (I learned that even if all of them run on the same Dietpi/Debian that the underlying ARMbian with the whole software basis like drivers etc is individual per board...so there will be differences for sure from both, hardware AND software even if you are always on Debian.).
They have with the C2 a tough benchmark.
I will as well challenge the NAS as feeding the player...the M1 has as well Sata onboard, other usb 3.0 and Usb 2.0, so different dedicated USB-chips. Lets as well see ho this makes a difference to play direct vs. network...(the idea came from exchanging SD-cards in sdtrans384...I mean...give me a break...the same player...and the type of SD-card makes a difference ?!?! WTF...I would never agree to that until I heard it now myself).
I think the EMI-Path is for sure the right direction to explain differences...maybe as well the cleaness of the voltage transmitted from the USB-Output to the Xmos-Chip to power it a second topic...EMI meant in a broader way: How is the board of the streamer designed...there has been in the old days agreement to underclock and undervoltage the CPU and try to switch off as many devices on the board as possible to lower power consumption....with the target to lower EMI etc...
Com, I think we are on the same page here...and if I remember right, wlowes was very active in those MPdpup /waveio days as well as was Dynobot...I just leanred that the magic nrpacks parameter has been taken of our playground to tune the USB-interface...what a pitty.
I thought as well: I2S directly...instead using USB for I2S, but my experiments with the soekris dam1941 with direct (unisolated) i2S was disappointing me. BUt, with Andreas's DAC, I might try it again...if you still got the sonore and want to sell, let me know...I am curious.
I am not sure if we should not open a new thread to discuss our sources findings, but this FIFO/DAC makes the difference so incredibly clear I feel I like at least to share with you my latest findings:
- Got the Sdtrans384 working (on battery/powerbank). Yes, SD-Cards do sound differently. NOt sure if this comes from the fat vs fat32 formatting or the SLC vs. MLC etc. SLC sounds a bit stiffer, more transparent while the Samsung MLC sounds warmer. It is in the magnitude of a mullard vs a Telefunken tube, so audible.
- TRied the Sotm 200 and ultra with external PSU: liked the smaller better, the ultra sounds again more transparent, but like a windows PC style (read: technical sounding) while the smaller is a bit more beefier...but it still has a certain grain/haze...all done with MPD...the sdtrans384 was clearly better
- I could not resist and wanted another reference to compare to. So I got my old Odroid C2 out and put Dietpi on it with MPD only (and lighttpd). That was a BINGO !!! I was very suprised. The Odroid in stock condition seems to beat any RP-derirvate (RP3/4/Allo Usbbrige sign/ IAn FIFO with battery supply) I have here in the house...I will compare it again backwards...but I was very impressed.
The nice thing on DIetpi/Odroid(on a powerbank, so battery) is that you:
- can bring clock of the Odroid down to 250mhz...and it works (a RP needs at least 600mhz I believe)..CPU-Load is between 4-6%.
- select your governor model...and yes..they as well do sound differently with "manually - no governor" raises the bar surpringly again a lot...I got a level of naturalness, transparency which I just never expected with this minimum on effort
- YOu can play with dedicated cores and priority per service (e.g.MPD or Network gets its own core or RT-prio)...not sure which settings I like best there...
- I has as well I2S output
- It beats the Sdtrans384
I was really surprised as I did not expect anything more than RP-Performance or less. But there seem to be audible difference between those little boards, how they got designed, how their USB/LAN-Integration works etc. I am by far not at the level of DYNOBOT (miss him)...I am not a Linux-Interrupt-Optimizer-TYpe of Guy.
But what I will do now is...play with it.
I ordered a bunch of SoCs from Odroid like the bigger brother C4, M1, Xu4 etc as all of them got different CPU/Chips on board...plus some NEoPi (funny little headless board with onyl a LAN and an USB-Connector as few components as possible with a CortexA53), BEaglebone and others.
I will for comparison reason try to get Debian/Dietpi/MPD to run on them with the same principles (like slow CPU, battery supply etc.). And than see how much difference is between them (I learned that even if all of them run on the same Dietpi/Debian that the underlying ARMbian with the whole software basis like drivers etc is individual per board...so there will be differences for sure from both, hardware AND software even if you are always on Debian.).
They have with the C2 a tough benchmark.
I will as well challenge the NAS as feeding the player...the M1 has as well Sata onboard, other usb 3.0 and Usb 2.0, so different dedicated USB-chips. Lets as well see ho this makes a difference to play direct vs. network...(the idea came from exchanging SD-cards in sdtrans384...I mean...give me a break...the same player...and the type of SD-card makes a difference ?!?! WTF...I would never agree to that until I heard it now myself).
Last edited:
It is known and has been measured that where data is stored on a computer can affect the sound of playback. Say, if the data is stored on a rotating disc, or its on an SSD card. The mechanism that affected sound playback was modulation of the computer power supply as it powered the data storage device. The modulation of the computer voltage also affected the +5v USB power. That voltage modulation coupled into the dac and changed the sound (IIRC measurements were done with a USB powered dac).
USB powered dac or not, surely the problem is some combination of power supply noise, ground noise, and or radiated coupling of emissions from the data storage device and or from the computer. What it means to me is that if any data storage device 'sounds' different than any other device, you have a noise problem that you need to fix. The sound is always going to be garbled/distorted/noise-modulated to some extent until its fixed. I don't think it should be taken as a cool effect because it means you will never hear what's really on a recording as it should sound, never know how good a proper system can sound.
USB powered dac or not, surely the problem is some combination of power supply noise, ground noise, and or radiated coupling of emissions from the data storage device and or from the computer. What it means to me is that if any data storage device 'sounds' different than any other device, you have a noise problem that you need to fix. The sound is always going to be garbled/distorted/noise-modulated to some extent until its fixed. I don't think it should be taken as a cool effect because it means you will never hear what's really on a recording as it should sound, never know how good a proper system can sound.