Audio PCs: Waste of Time?

[opus101]

2 minutes ago, chauphuong said:

SQ is not all about isolation.

 

Once bit-perfection of the stream is a given, what else is there left, other than isolation? I'd appreciate a heads-up on this.

[Ralf11]

there is a guy on here who swears bit-perfection of the stream is not enough... and that differences in two bit-perfect files can be heard

[ElviaCaprice]

Isolation/power and clocking.   They do intermix.

[chauphuong]

1 hour ago, opus101 said:

 

Once bit-perfection of the stream is a given, what else is there left, other than isolation? I'd appreciate a heads-up on this.

Jitter, caused by many factors among which bad power supplies. And as I understand, using galvanic isolators with async usb add jitter.

[opus101]

16 minutes ago, chauphuong said:

Jitter, caused by many factors among which bad power supplies. And as I understand, using galvanic isolators with async usb add jitter.

 

Oh I was assuming async transmission (USB or ethernet) so how could jitter be caused, other than through lack of isolation?

[nbpf]

8 hours ago, Lebouwsky said:

You can install Windows on an usb stick. If you give usb highest prio in bios and you stick your usb in the pc, it will boot from it. Remove it and when you start up again it wil boot from hd. You can use this usb in any other computer.

 

http://uk.pcmag.com/operating-systems-and-platforms/88253/feature/how-to-run-windows-10-from-a-usb-drive

True but can you setup Windows to boot headless, switch off HDMI output, wireless interface and BT and do all system setup from your laptop via ssh? This is in my view the strenght of the Pi, you do not need to attach any keyboard or screen to the Pi. Just insert the micro SD card and do the rest from your laptop. 

[nbpf]

5 hours ago, opus101 said:

 

Once bit-perfection of the stream is a given, what else is there left, other than isolation? I'd appreciate a heads-up on this.

My understanding is that nothing else is left provided that your DAC overrides any previous clocking. Otherwise isolation and reclocking, I would say. 

[nbpf]

4 hours ago, chauphuong said:

Jitter, caused by many factors among which bad power supplies. And as I understand, using galvanic isolators with async usb add jitter.

I understand that jitter is a property of a stream that carries data associated with a unique (implicit or explicit) time tag. I am not sure that this is the case for USB streams. I would have rather expected that one can only speak of jitter measures after a stream of data has been (re-)clocked. I might be missing something, of course.

[Lebouwsky]

1 hour ago, nbpf said:

True but can you setup Windows to boot headless, switch off HDMI output, wireless interface and BT and do all system setup from your laptop via ssh? This is in my view the strenght of the Pi, you do not need to attach any keyboard or screen to the Pi. Just insert the micro SD card and do the rest from your laptop. 

Sure, you can boot Windows headless when you add your password to your account this way:

https://www.digitalcitizen.life/log-automatically-windows-7-without-typing-your-password

 

You can add any program you want to the automatic start up folder this way:

https://www.tekrevue.com/tip/windows-10-startup-folder/

 

you can take over the control of the pc with your smart phone with a lot of apps.

 

Personally I like to keep the tv on since I use HQplayer. I use my phone as a touchpad with this app:

http://www.remotemouse.net/

 

The freedom of Windows 10 to customize it the way I want it and use software I like is a no brainer to me. It just takes a little Google effort. 

 

I use dual boots on my pc. One boot for music with optimised and minimaal OS, the other for watching cable tv/Kodi/Netflix/YouTube for my family and me. With the Schiit Eitr my dac is able to read the data of all these programs. 

 

[Miska]

1 hour ago, nbpf said:

My understanding is that nothing else is left provided that your DAC overrides any previous clocking. Otherwise isolation and reclocking, I would say. 

 

Until the data reaches DAC, there's no timing information associated with the data, other than the sample rate value. So for example 44.1 kHz sampling rate, each sample is 1/44100'th of second apart. That's it.

 

Where the clocking comes into DAC is a separate thing. For asynchronous USB, DAC has the master clock. With S/PDIF and AES/EBU, sending side has the master clock.

 

[Miska]

25 minutes ago, Lebouwsky said:

Sure, you can boot Windows headless when you add your password to your account this way:

https://www.digitalcitizen.life/log-automatically-windows-7-without-typing-your-password

 

It still launches all the unnecessary graphical interface stuff and even requires you have have a display adapter.

 

[Lebouwsky]

1 minute ago, Miska said:

 

It still launches all the unnecessary graphical interface stuff and even requires you have have a display adapter.

 

May I ask what’s the disadvantage of that? 

[nbpf]

 

2 minutes ago, Miska said:

 

Until the data reaches DAC, there's no timing information associated with the data, other than the sample rate value. So for example 44.1 kHz sampling rate, each sample is 1/44100'th of second apart. That's it.

 

Where the clocking comes into DAC is a separate thing. For asynchronous USB, DAC has the master clock. With S/PDIF and AES/EBU, sending side has the master clock.

 

Thanks, this matches very well with my (admittedly rather fuzzy so far) understanding of the matter.  

 

One point is still unclear to me, however: you say that with S/PDIF the sending side has the master clock.

 

But https://www.naimaudio.com/sites/default/files/products/downloads/files/naim_dac_august_2009.pdf suggests that this is not the case for the Naim DAC.

 

This case is relevant for me since I am in fact using a Naim DAC. It could explain some rather puzzling observations that I have recently reported on this forum: 

 

[CuteStudio]

33 minutes ago, nbpf said:

One point is still unclear to me, however: you say that with S/PDIF the sending side has the master clock.

 

But https://www.naimaudio.com/sites/default/files/products/downloads/files/naim_dac_august_2009.pdf suggests that this is not the case for the Naim DAC.

 

 

 

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.

[sandyk]

21 minutes ago, CuteStudio said:

my last Win10 update was 1.4GB and locked up the house broadband for hours,

 

Hours for 1.4GB  ???

[chauphuong]

7 hours ago, Lebouwsky said:

Sure, you can boot Windows headless when you add your password to your account this way:

https://www.digitalcitizen.life/log-automatically-windows-7-without-typing-your-password

 

You can add any program you want to the automatic start up folder this way:

https://www.tekrevue.com/tip/windows-10-startup-folder/

 

you can take over the control of the pc with your smart phone with a lot of apps.

 

Personally I like to keep the tv on since I use HQplayer. I use my phone as a touchpad with this app:

http://www.remotemouse.net/

 

The freedom of Windows 10 to customize it the way I want it and use software I like is a no brainer to me. It just takes a little Google effort. 

 

I use dual boots on my pc. One boot for music with optimised and minimaal OS, the other for watching cable tv/Kodi/Netflix/YouTube for my family and me. With the Schiit Eitr my dac is able to read the data of all these programs. 

 

For a headless PC (Windows 10) I do like this:

Press Windows+R, regedit, then go to:

Hkey local machine\software\microsoft\windownt\currentversion\winlogon shell=explorer

 

Then change =explorer to =C:\Foobar2000\Foobar2000.exe (path to exe file of the player software, in this case Foobar2000). 

 

So when the PC is booted, only Foobar2000 starts. As Explorer is stopped, many services, processes and handles that go with it also stop including the die-hard  Cortana. Then I use Foobarcon Pro installed onto an Android Phone for remote control.

[nbpf]

10 hours ago, CuteStudio said:

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 am not sure, https://www.naimaudio.com/sites/default/files/products/downloads/files/naim_dac_august_2009.pdf clearly states that the Naim DAC selects one of ten possible fixed frequencies that are controlled by a master clock on board, see page 3. This suggests to me that the timing information associated with the incoming S/PDIF stream gets overridden. In this situation, a USB to SPDIF interface feeding a Naim DAC would merely act as an isolator, the final clocking would take place inside the DAC. Whether this is for the good or for the bad is of course another matter.    

[CuteStudio]

18 minutes ago, nbpf said:

I am not sure, https://www.naimaudio.com/sites/default/files/products/downloads/files/naim_dac_august_2009.pdf clearly states that the Naim DAC selects one of ten possible fixed frequencies that are controlled by a master clock on board, see page 3. This suggests to me that the timing information associated with the incoming S/PDIF stream gets overridden. In this situation, a USB to SPDIF interface feeding a Naim DAC would merely act as an isolator, the final clocking would take place inside the DAC. Whether this is for the good or for the bad is of course another matter.    

 

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

[Miska]

13 hours ago, nbpf said:

One point is still unclear to me, however: you say that with S/PDIF the sending side has the master clock.

 

But https://www.naimaudio.com/sites/default/files/products/downloads/files/naim_dac_august_2009.pdf suggests that this is not the case for the Naim DAC.

 

This case is relevant for me since I am in fact using a Naim DAC. It could explain some rather puzzling observations that I have recently reported on this forum: 

 

Yes, data can always be reclocked in various ways. HQPlayer Embedded can do it too for S/PDIF or AES/EBU inputs, keeping two clocks separate. That's why you can input for example 44.1 kHz PCM and output 768 kHz PCM on the other side.

 

But anyway, data on the S/PDIF or AES/EBU wire is driven by source's clock. And traditionally DAC would recreate it from the bitstream using a PLL. Although other approaches exist too. For example in HQPlayer Embedded case S/PDIF or AES/EBU doesn't end up at DAC, but instead at computer doing further processing and potentially sending the data out over asynchronous USB audio link at completely different sampling rate. Thus the clock over S/PDIF or AES/EBU link doesn't have relevance from DAC point of view.

 

Over asynchronous USB Audio Class, clocking is driven by the recipient side, which is usually the DAC.

 

So what is relevant in this context is what kind of input data flow the DAC sees and how it deals with it. Before that the clocking in itself is irrelevant to to same extent it is for contents for source audio file (FLAC, WAV, AIFF, whatever).

 

[nbpf]

6 hours ago, Miska said:

 

Yes, data can always be reclocked in various ways. HQPlayer Embedded can do it too for S/PDIF or AES/EBU inputs, keeping two clocks separate. That's why you can input for example 44.1 kHz PCM and output 768 kHz PCM on the other side.

 

But anyway, data on the S/PDIF or AES/EBU wire is driven by source's clock. And traditionally DAC would recreate it from the bitstream using a PLL. Although other approaches exist too. For example in HQPlayer Embedded case S/PDIF or AES/EBU doesn't end up at DAC, but instead at computer doing further processing and potentially sending the data out over asynchronous USB audio link at completely different sampling rate. Thus the clock over S/PDIF or AES/EBU link doesn't have relevance from DAC point of view.

 

Over asynchronous USB Audio Class, clocking is driven by the recipient side, which is usually the DAC.

 

So what is relevant in this context is what kind of input data flow the DAC sees and how it deals with it. Before that the clocking in itself is irrelevant to to same extent it is for contents for source audio file (FLAC, WAV, AIFF, whatever).

 

Thus, I understand that in the specific case of a Naim DAC fed by a USB to S/PDIF interface (M2Tech hiFace Evo, Mutec MC-3+ USB, Schiit Eitr) the (re-)clocking done at the USB to S/PDIF interface gets overridden by one of the 10 DAC's internal clocks. This suggests that trying to improve the sound quality by improving the quality of the clocks of the USB to S/PDIF interface makes probably little sense.

[One and a half]

On 1/10/2018 at 9:02 PM, CuteStudio said:

 

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. 

OK, on a slower than USB balanced system, Profibus signals were monitored to tell me the condition of a cooling system, where pressures, temperatures, flow were necessary for the protection of the upstream power system.

One day there were fine, the next day, the temperature readings went to  450C on one transmitter, the other read -140C on the discharge and suction lines of a pump, pressures, -2800kPA....what gives. My laptop power supply was sitting on the Profibus cable. Removing the power supply fixed the problem and the numbers returned to normal. Profibus is a balanced transmission system of data blocks, very much like USB data, has shielded cables.

This example happened for real, so for my audio system, there's measures taken to keep the crap out of the system, conducted or emitted, digital or analog to avoid signals and power interfering with each other.

RF is so high, nothing to do with things, induction is far worse and readily more 'available'.

[CuteStudio]

1 hour ago, One and a half said:

OK, on a slower than USB balanced system, Profibus signals were monitored to tell me the condition of a cooling system, where pressures, temperatures, flow were necessary for the protection of the upstream power system.

One day there were fine, the next day, the temperature readings went to  450C on one transmitter, the other read -140C on the discharge and suction lines of a pump, pressures, -2800kPA....what gives.

 

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.

 

3 hours ago, nbpf said:

Thus, I understand that in the specific case of a Naim DAC fed by a USB to S/PDIF interface (M2Tech hiFace Evo, Mutec MC-3+ USB, Schiit Eitr) the (re-)clocking done at the USB to S/PDIF interface gets overridden by one of the 10 DAC's internal clocks. This suggests that trying to improve the sound quality by improving the quality of the clocks of the USB to S/PDIF interface makes probably little sense.

 

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.