CuteStudio

Misquoting and chiding? I cannot be responsible for how you interpret my comments, although I will try to avoid the triggers as I learn them of course. You were the one who said my comment was 'steeped in BS': I asked politely for you to clarify, can you please clarify that statement? I have to state MY views here. I cannot state yours or anyone else's or we descend into Groupthink. The entire improving USB debate is to me an exercise in 'perfecting mediocrity' and is a problem that has already been solved. You chose to interpret that as me calling you foolish, that was not intended, the intended purpose was to say 'hey guys, if you want a perfect digital link to your DAC look at I2S because it already does it and has for ages". Again, I cannot be responsible for your interpretations of my words, only of the words themselves. My observation that people spent their Christmas on here bitterly debating cables also appears to be true if you look back at the posts. It's odd that the content that's supposed to be emotive (MUSIC) evokes far less emotion that cables which for some reason always get everyone fired up. It's bizarre, and also the reason the man on the street laughs as 'Hifi people'. I've read entire reviews about how a cable 'sounds' that only mention in passing the music, the speakers, the amp or the DAC etc. To me that is laughable, but I realise I need to change as a person to gain reverence for cables, and that this heretical attitude makes me a bad person to be scorned in forums such as this. For the man on the street however this cable worship has killed the HiFi industry. It's done wonders for the cable industry though LOL, volumes are down but money is up. Much easier to sell a $200 cable than a decent $200 amplifier and far far less work. Now back to I2S: A) If one runs the Pi I2S with the internal Master there is of course serious jitter and an ASRC and or reclocker will help. B) If one runs the Pi with an external clock (Slave) then the timing is as accurate as the external clock. Are you saying that in scenario B you still need an ASRC? If so - why? BTW Apologies in advance for using 'master' and 'slave', these words have been deemed offensive in today's PC minefield and companies like DJango are redefining them as 'primary'/'replica' instead, which means master/slave.

4est: 'Steeped in BS' is very emotive, could you instead explain what made you unhappy? Of course the I2S is used internally - the Volumio link I gave says exactly that! that's why I linked to it. Perhaps as you clearly didn't read the link we are not on the same page about this. You claim that the Pi's i2s link is 'shitty', despite it's ability to be clocked externally and it's short traces to daughterboard DACs. As it fulfils all the I2S implementation criteria you mention what is it that you consider 'shitty'? Again here a less emotional response may be beneficial. As of Sandyk you said 'You are perpetuating a problem that you claim exists.', which can be taken to imply the difference he hears is not real, an inconsistent statement in a thread many consider to be about people hearing differences that are not real. I didn't mention his listening to cabling. Happy New Year!

It is ironic that you criticise SandyK for hearing differences in a bit-perfect system in a thread devoted to cable sound in a bit perfect system - it strikes me as inconsistent: Sandy's lack of understanding that all digital data is recreated based on threshold detection at every stage of the process is no different from the thought that any cable can change the sound of USB except via simple and known analog processes such as earth loop issues and RFI, or that USB is any type of interface to be using for audio in the first place. I see no difference. USB is as appropriate as Class B amplifiers, unbalanced interconnects and speaker side crossovers: pointlessly inferior. To the quoted reply: You ask: how do you get i2S from a computer? Given 32 years and the fact it's one of mankind's simplest inventions I'm surprised you have to ask. If there is no standard PC interface for it that is a reflection on computer audio, nothing else. However the Raspberry Pi is a computer and it has this interface. For £30 odd you get a full computer complete with peripherals, memory, HDMI, ethernet etc and I2S so that kinda proves that it's not a difficult task to support I2S. It also runs a real OS. Additionally the Pi supports external clock for the I2S so that could come from the DAC itself or a master clock just like in a recording studio. I.e. you can already buy a fully functional low power computer with proper I2S and a decent DAC for around the cost of a fluffy USB cable. I'm sure the Lush 1,2,3 etc. is fantastic and the Gen 5,6,7 etc are super great but the problem you are trying to solve was already solved 32 years ago and can be bought today for peanuts. Full accurate clocked hi-res audio, today: peanuts. If your DAC manufacturer didn't see fit to add/externalise their I2S interface I suggest you ask them why they failed to support the only decent interface around that will be on their PCB somewhere anyway. Surely that's supposed to be their job? So I don't really understand your post - what are you trying to say?

Good to see that over Christmas serious people were busy listening to their lossless, bit perfect, digital cables. Then arguing about it on the internet and discussing ignore lists and banning. Fascinating. I on the other hand was listening to music, discovered a couple of great artists and a new album by one of my favourites :D However when the conversation strayed to redesigning the USB cables we entered the far reaches of the Twilight Zone where the Langoliers roam and Dr. Strange sometimes visits, and even I was sucked in by the vacuum. Upgrading USB? Completely pointless. There is already a decent audio interface since 1986 called I2S that does all this and is in use in many devices. E.g: https://volumio.org/raspberry-pi-i2s-dac-sounds-so-good/ (I was going to put a Wikipedia link in but that multi hundred million $ company part financed by taxpayer funds is in it's seasonal 'beggig for money' mode). The fact all HiFi makers haven't picked this up yet (they've had 32 YEARS) and used it tells us more about the HiFi industry than people should be comfortable with. I2S guys: perfect timing, already being used by the smarter engineering based sections of audio. As a bonus it also slots right into a Raspberry Pi a win-win. (As an aside, quite why people use anything else is also a mystery. Mine sits there day after day, I don't even bother to switch it off because it uses so little power: No USB required). Now back to the serious business of listening to cables...

@fas42LOL

After looking at some measurements showing that susceptible DACs worked better with short cables I saw a suggestion to eliminate the cable entirely. As this also tidied up the HiFi area I now use one of these: https://www.ebay.co.uk/itm/USB-Adapter-female-male-to-male-plug-type-A-B-micro-mini-coupler-gender-changer/282418030187 It sounds very sweet, clear and detailed indeed (exactly the same as the previous cable in fact), and the cable doesn't influence the sound because there is no cable. QED, now I can use that $300 digital cable budget to buy some more CDs with

A perfect illustration of what happens to analog data (temperature, pressure) when digital gets corrupted. The bizarre and unreasonable analog readings of pressure and temperature are the same as the snaps, crackles and noise that you'll get from a DAC if the digital goes wrong. Digital information is never old and has no history. At each stage it is subject to a serious filtering of an analog level (voltages in the CPU, USB cable etc) to a 0 or 1. This happens on every register move in the CPU, every memory store, every memory read, every I/O operation. This means that a great deal of interference is required to swap a 0 into a 1 or a 1 into a 0, and because of the nature of the binary numbers some bits are far more important that others, so interference will generally affect analog numbers (like audio levels) to random extents. So don't worry about the digital side - if it fails, you'll hear it and it will be obvious. Also all USB cables, implementations and laptops are different but as a general rule it's good practice to route wires away from sources of EM emissions as per the 'Inverse Square Law' - something twice as far away receives four times less radiation. Preventing RFI getting to the analog side of the DAC is a good idea though, my cheap USB cable has a ferrite built in and I also clipped one around the microUSB input just because it was lying about. Naim's philosophy for that device is stated in the PDF - they use the optical SPDIF to eliminate the electrical contact (as I do in fact) but then clean up the clock properly with a FIFO so it's as jitter free as it can be (I use an Ultramatch for that). I2S and Asynch USB are different ways to achieve jitter free operation but don't usually include optical isolation (although opto-isolators are pretty cheap to add to a DAC board). BTW transformers will give galvanic (DC) isolation and reasonable common mode rejection but remember IF stages of radio receivers are also full of transformers - they are pretty good at passing RF too. Digital audio is simply the clocking of the correct current at the correct time, current being determined by both the digital value and the DAC chip's PSU, time being determined by some clock - ideally the one on the DAC. Getting the right numbers into a DAC is why a £32 Pi is just as good as a £1000 PC, although in my experience it's far far better due to cost, size, reliability, speed to configure and setup, convenient for scripting, power and vastly superior OS. It's also why cheap optical and USB cables are just as good as expensive ones: just as a cheap calculator allows you to type in the same numbers as a gold plated nixie tube custom job . Most HiFi people would benefit from using their cable budget on music TBH.

See page 4 of their PDF, the RAM buffer is the FIFO memory, the 'iCoupler Isolation' is the bit that decides how to speed up or slow down the master clock. Don't look at it from a 'mechanism' viewpoint, everything is much simpler from a 'data viewpoint'. The SPDIF data is flooding in, about 900MB of it for a decent sized album at 44.1/24 and my software can play stuff for a month continuously - and so I suspect can Naim's.. That data has to go somewhere, and they only have a finite sized RAM buffer (and the user so much patience for latency), so they have to speed up and slow down the master clock so they avoid a) Flooding/overflow and b) Running out of stuff to play. The FIFO/Naim method is the only sane way to get perfect timing from a SPDIF playback, it's a good design as I'm sure they have designed the regulator (iCoupler Isolation) wisely. I wouldn't not buy one...

What Naim have done is simply add a FIFO to their DAC so they are not twisting and turning with the SPDIF's every whim. I'm still uncertain how the world's top audio firms managed to come up with AES and SPDIF as clock recovery is never a very good idea, far more sensible would have been an XLR with one wire as clock and one as data - like an external i2s system. I guess they couldn't do that as HiFi buffs are allergic to XLR connectors though. As stated Asynch DAC is really the only method for a DAC master clock, the other methods send the stream in real time and have varying degrees of success with jitter, Naim's FIFO idea would seem the obvious - but when I suggested the same people laughed and said it would add wow and flutter. The Pi has I2s which can easily be configured in slave mode to drive a DAC properly. I'm not sure why people are supporting Windows over the far better documented Raspbian + Pi which also uses free open software and is frankly far far easier to configure and update. It must also be far cheaper - how much is the cheapest suitable Win10 machine? Also Pi updates are a few kB or MB, my last Win10 update was 1.4GB and locked up the house broadband for hours, in my experience Windows is totally unsuitable for the task of serving audio unless IT is a personal hobby of yours.

Unless the topic is 'Audio PCs - Waste of time?' LOL Frankly solving the problem for £32 with a PI is a very good answer. I've built PCs of various ages and powers and run and maintained various OS's and the time (and money) saved buying a Pi instead is HUGE. My whole Pi (Pi + 16GB memory card + USB charger + case) is less than my quiet PC's PSU, and the icing on the cake is not having to maintain Windows either - so it's a huge win-win. If I want to update the OS (Raspbian) it takes me a solid 3 minutes - try that with Windows..

The results are beyond difficult, they are in fact irrelevant because he's testing power to the DAC there. My Pi is powered by a micro USB wall-wart charger, possibly 2.5A, I haven't checked. My DAC is inside a Behringer Ultracurve and has it's own SMPS power supply inside it. Like any decent DAC I guess.. Unless you are powering the DAC the Pi PSU really just needs to power a small ARM based SOC chip.

Well it won't change the digital data, but while all laptops have to be CE marked for RFI emissions remember the DAC is half analog - so any unwanted RF may still affect things. That's another reason why I don't power my DAC from the USB power. USB itself is a balanced system so common mode interference should be rejected fairly well by any competent implementation but RF can always find a way through things. That's not been my experience, I just plugged it in, loaded my software script and away it went. My audio chain is perhaps untypical however, USB goes to a cheap Phiree USB/SPDIF converter at 44.1/24, then that is upsampled to 88.2/24 and re-clocked at the other end of a cheap optical cable by a Behringer Ultramatch, then fed into a Ultracurve to use the nice DAC in there which has a mod to bypass the opamps after the DAC. From there is goes into a SET amp of about 10W which has no global feedback loop, which makes the system far less susceptible to RF anyway. So the path is: 16bit digital CD WAV/FLAC rip (garage) -> declipping to 24bit (garage server) -> WiFi -> Pi -> Phiree -> optical -> ultramatch -> 88.2/24 -> ultracurve (modded) -> SET amp (actually a superSEP) -> speakers -> largish room -> ears. That gives a lovely open, clear natural sound with liquid treble and a good solid bass and very realistic vocals. I'm sure there are improvements that can be made but frankly nothing bugs me about the sound so I'm quite content with it. The Pi just sits there, uUSB charger in, USB out - best £32 I ever spent on HiFi . The only upgrade in the future is an ethernet cable to load up the track to play faster for when I change my mind which fools the cue cache.

Yes. Could you be more specific - what does 'landing on' mean?

Pi PSUs Hi chaps, thanks for all the suggestions about PSUs for the Pi, it is appreciated. I'll probably use a small switcher off of a linear 12V supply if I do add a special PSU for it, the small LV (Low Voltage) switchers are very quiet IME compared to mains switchers and many come with voltage meters built right in too, so it's a win-win. Plus they stay cool. USB audio digital corruption notes As for digital corruption in USB audio links, the reason for the unpredictability of noises caused when this happens (as perfectly explained by Miska above) is because it's digital: not analog: To damage (alter) a digital number with noise you need to change some of the bits. But with just 16bit music all bits are not equal, some are 65536 times as important as others, but the noise can't 'choose' which ones will be altered. So statistically with a noise problem that great you'll get a few insignificant ones altered - sure, but you'll also get a few really important ones changed too. It's possible of course that the fast deep errors will have different sounds due to filtering etc, but you'll hear it and it will sound bad and obviously faulty. As suggested above - keep this a digital computer problem and use the type of technology that Google, Amazon, Microsoft, FB etc. rely on - correctly graded computer leads: because they work the best and for good reason: there's a lot of money at stake if they don't. Why identical files create identical waveforms Essentially for the 'identical files can sound different' argument however USB audio noise is irrelevant because it applies equally to file A and file B, and if these files have identical digital data in them the CPU will clock them into the USB channel just the same. If your CPU/Fifo etc can't detect is as a 1 or 0 it's not there, because that's all they work on, it's dull, unimaginative and boring but that's computer tech for you, and probably why many find IT boring. This is not to say that identical waveforms with be heard the same when repeated of by multiple people, in the analog + person domain there are simply too many variables, including your neighbours arriving home and switching all their gear on. Digital file integrity - imperfect sound forever If there is any 'effect' from method of ripping that is hidden from the digital data in the file then each time that digital information is moved that 'extra data' is ignored for another time because each computer, router, switch, OS, HDD, SSD etc is not sending the file - it's reading it in as 0 and 1 to the CPU that is then loading completely new and different 0 and 1s into it's registers to send that data to the next place. Essentially 'digital' means 'filter anything not a 0 or 1 out completely every time the data is read', allied with the various protocols that ensure that 'The copy at the far end is an exact bit perfect copy of the data at the origin'. An example of digital data integrity This is why your 1.2GB Windows 10 updates arrive on your PC and actually works, if there was even 1 bit error per billion bits nothing in computing would work properly at all, data integrity is essential and key to all modern computing devices and transfers. The only dodgy data source that is open to errors is the CD (but no one has really found ripping errors in that either), although if you have the worst case scenario of ripping a CD in a high volume sound field you may get mis-tracking and poor sound. I.e. like using a CD player in your listening room. But no one here would do that.

Oh :(. I thought that was the easy part. In any binary system there is a point when a bit of hardware has to decide if something is a 0 or a 1. This is irrelevant of timing, rise and fall times or anything else. When the clock falls the decision is MADE. That decision then forms a new voltage level that gets recorded to a register or fifo etc. That decision and information is 'binary', i.e. 0 or 1. There is no grey area or fuzzy logic, once the decision is made even a wobbly 1 is a firm 1 and a wobbly 0 is a firm 0. The register values the decision is stored in can only also hold a binary value, there is nothing else in the system available to store the information, we are mathematically limited to 0 and 1. Yes, I am aware of hardware like that, the decision is still the same, 0 or 1. If the data is misread from a disk then the hardware does a series of retries to get the data, and will rewrite dodgy stuff or mark the sector and copy the data to a fresh sector. If the data simply cannot be read correctly then you get a disk error which is signalled to the OS and you don't get your file: Read Error. Therefore we know the actual shape of the HDD waveform is not at issue because there is that clear decision point of a 0 or 1 that is made, and if it's wrong we'll not get our data. This is quite different from a CD read error that will just give us a fudge instead, with a computer disk the data integrity is critical because all the programs will error if it wasn't 100%, so it's maintained with an iron rule. This is where we need to determine - from an information viewpoint - where the noise is hiding in one of the files when it's binary identical to the file that is claimed to sound better. Somehow that data has to exist - right? It exists in a state that the computer cannot detect but you say the DAC can, so how does data that is undetectable to the computer get loaded into the block based USB data packets.... ... if the computer itself can't read them? So we have 4 problems: 1) Where does the noise live when the data is stored? 2) How does it travel when each computer along it's journey can't detect it? 3) How does it travel into the DAC if the audio player can't detect it? 4) If the noise is not explicitly send out - how does it know where it's going? I don't believe. Anything. Belief is a stronger mechanism that mere facts and data therefore I stay away from it. All i can say is that I have no idea of any details of any test setup where people claim to hear it. All I do know is the facts and the 3 logical and physical problems as listed above, which must be solved in order for the difference to be real. I'm not saying it's rubbish, my opinion is irrelevant anyway; but I'm saying that logic and facts are denying the effect. Can you see my problem? If the CPU has no awareness of this data how can it clock it into the registered to be sent anywhere? So if it doesn't clock it anywhere, how does it reach the destination. To download a file (for instance over wifi at home to play) each packet is specifically addressed and send by the CPU. How does the noise even know where to go? Say I have 10 computers on the network and am streaming to one - why doesn't the noise go to a different computer?