[rayl]

I was watching the nvidia CES presentation and saw their VOLTA and I was wondering has chord predicted when do they think they can get the required technology to reach their ideal 1 million TAP limit?

Maybe I am misreading the comment but if it is can you do 1 MM tap filter on an nVidia chip... no doubt. For pure DSP work, a current gen nVidia will eclipse what you can do on a Xilinx. But an FPGA can do more than DSP. It can even implement your usb interface, etc.... anything pretty much, with the limitation of chip level voltages.

And GPUs only come on PCI cards. Probably not changing for the high end discrete DAC market— the whole market would be a rounding error for nVidia.

 

[Jawed]

Oh really, I turn it off using the Power button on the remote - everything connected turns off.
Yes I have bypassed P10 as well with same hiss in the channel.
Yea I think there may be an issue as well. So sad.

The first Hugo 2 I bought last year had constant hiss on the right channel. It was replaced. Your report appears to be the first of a DAVE failing the same way.

Regarding the P10, using the P10 remote will only turn power off to each of the P10 sockets by using internal relays in the P10. The P10 itself is still powered up and can be damaged by a power spike on the incoming mains. You can tell the P10 is still powered up because there is still a slight hum from the P10 internal transformer. The only way to fully power down the P10 is to use the switch at the back and even that might not prevent damage due to lightning and you would need to pull the P10 mains plug from the wall to be fully safe.

The idea that a power conditioner is vulnerable to surges on the mains and other ills caused by storms is a very strong recommendation never to use such junk. If that's really true for the P10, then well...

I was watching the nvidia CES presentation and saw their VOLTA and I was wondering has chord predicted when do they think they can get the required technology to reach their ideal 1 million TAP limit?

Rob is already doing 1 million taps at about 10W consumption. A GPU will never do that. It consumes 10W just being switched on.

For pure DSP work, a current gen nVidia will eclipse what you can do on a Xilinx.

No, not even close. But NVidia's marketing is amazing at making ordinary people believe this nonsense.

Now playing: Fionn Regan - Cormorant Bird

 

[audionewbi]

Nvidia new dsp chips can run at 30 watts compared to the last year Model 300 watt

 

[Triode User]

The idea that a power conditioner is vulnerable to surges on the mains and other ills caused by storms is a very strong recommendation never to use such junk. If that's really true for the P10, then well...

ALL electrical equipment is vulnerable to damage caused by lightning strikes and it is foolish to pretend otherwise. The P10 is no more vulnerable than anything else. Chord Dave, Blu2 and even the Hugo2 when connected to the charger are all equally vulnerable to lightning strike. I presume you would therefore also classify them as 'junk'. I would always unplug all electronic equipment if there was the risk of lightning strike.

 

[Jawed]

PS Audio doesn't claim surge protection. Isotek does. I suppose that's the difference between the two.

 

[Triode User]

PS Audio doesn't claim surge protection. Isotek does. I suppose that's the difference between the two.

There are many differences but that is a debate for elsewhere outside the Dave thread.

 

[rayl]

... portions deleted ...

No, not even close. But NVidia's marketing is amazing at making ordinary people believe this nonsense.

Now playing: Fionn Regan - Cormorant Bird

Jawed, where do you think the bottleneck is?

You got me curious to find out exactly how expensive 1MM taps is. It certainly isn't the bottleneck.

I don't have a CUDA dev kit to run tests on, but testing with a standard CPU that's 5 yrs old (my PC is an i7-4770K @ 3.5GHz), I can get:

138 xRT on 1 million taps at 1Fs (48kHz) and 24 bit PCM resolution.
62 xRT at 2Fs
28 xRT at 4Fs

I used an off-the-shelf free package (http://convolver.sourceforge.net/) that seems to crash at 6Fs. Output below.

The sublinear performance is due to memory access overhead bec I'm simulating 2Fs with 4 tracks (whereas in reality, it's just 2 tracks with higher sampling rate so memory will not need to thrash). I did hte extra tests to insure that the trend is stable.

This is on a basic 4 core CPU. To make numbers round, let's call it 128 xRT at 1Fs, which would require 64 cores to get 2048Fs at 1xRT.
I can imagine that a CUDA core is typically at half the clock speed, so say we double it to require 128 cores....

Or we can build in a lot of margin and say it requires.... 1024 cores... I'm being very generous today.

A consumer grade gaming GeForce GTX 1080 has 2560 cores. I still have 1500+ cores to spare for the oversampling processing, noise-shaper, etc.

I can imagine that loading data at 2048Fs might be the bottleneck, but you're never really loading at greater than 8Fs and you're oversampling on the board to get to 2048Fs.


Backup data below. Both the 30sec wav and the FIR represented as a wav were randomly generated to be of the right length.

----
C:\Program Files (x86)\Convolver\Convolver>convolverCMD.exe 0 1 0 c:\temp\convolver\1fs.wav c:\temp\convolver\1fs30secs.wav c:\temp\convolver\out.wav
Using overlap-save convolution
Input file format: Stereo WAV (Microsoft) 48kHz 1440000 frames
Filter format: 2 Paths (Stereo to Stereo direct) 48kHz 2000000 taps Lag: 1000000 taps 21s Estimated gain: 35dB Peak gain: 94dB
Optimum attenuation: -45dB calculated in 3.77s
Using attenuation of 0dB (ie, scaling factor of 1)
Convolved and wrote 4000000 frames to c:\temp\convolver\out.wav in 0.665s (ie, at 1.3e+002 times real time)


C:\Program Files (x86)\Convolver\Convolver>convolverCMD.exe 0 1 0 c:\temp\convolver\2fs.wav c:\temp\convolver\2fs30secs.wav c:\temp\convolver\out.wav
Using overlap-save convolution
Input file format: 4-channel WAV (Microsoft) 48kHz 1440000 frames
Filter format: 4 Paths (4 channels to 4-channel direct) 48kHz 2000000 taps Lag: 1000000 taps 21s Estimated gain: 35dB Peak gain: 94dB
Optimum attenuation: -46dB calculated in 7.38s
Using attenuation of 0dB (ie, scaling factor of 1)
Convolved and wrote 4000000 frames to c:\temp\convolver\out.wav in 1.35s (ie, at 62 times real time)


C:\Program Files (x86)\Convolver\Convolver>convolverCMD.exe 0 1 0 c:\temp\convolver\4fs.wav c:\temp\convolver\4fs30secs.wav c:\temp\convolver\out.wav
Using overlap-save convolution
Input file format: 8-channel WAV (Microsoft) 48kHz 1440000 frames
Filter format: 8 Paths (8 channels to 8-channel direct) 48kHz 2000000 taps Lag: 1000000 taps 21s Estimated gain: 35dB Peak gain: 94dB
Optimum attenuation: -46dB calculated in 14.9s
Using attenuation of 0dB (ie, scaling factor of 1)
Convolved and wrote 4000000 frames to c:\temp\convolver\out.wav in 2.94s (ie, at 28 times real time)

C:\Program Files (x86)\Convolver\Convolver>convolverCMD.exe 0 1 0 c:\temp\convolver\8fs.wav c:\temp\convolver\8fs30secs.wav c:\temp\convolver\out.wav
Using overlap-save convolution
Input file format: 16-channel WAV (Microsoft) 48kHz 1440000 frames
Filter format: 16 Paths (16 channels to 16-channel direct) 48kHz 2000000 taps Lag: 1000000 taps 21s Estimated gain: 35dB Peak gain: 94dB
Standard exception: bad allocation

 

[flyte3333]

your assertion that a battery powered source does not solve RFI is just plain wrong. Battery powered sources, that have no ground connected, coupled via Dave's galvanically isolated USB, has effectively perfect isolation from the source ground to Dave's internal ground. It's isolation is actually more effective than optical via a mains powered source, as the ground coupling loop is via the source to general ground - and that capacitance is measured in fempto Farads or fF, and this coupling capacitance is insignificant compared to the low impedance path of a mains powered optical connection. Just because a source uses optical does not guarantee perfect isolation, as the mains provides a RF connection path into Dave - but a battery powered source via USB does provide effectively perfect isolation.

Hi Rob, regarding this old quote of yours - would you still recommend a USB cable with ferites, even if the USB source is battery based (like a mobile phone) running entirely off batteries?

Or is the USB cable with ferrites recommendation, more for mains power connected USB sources?

Cheers!

 

[analogmusic]

erm - what's the best way to feed data to Dave?
I heard an auralic streamer with some posh Chord Ethernet cables, and the Ethernet cable made a difference which is quite annoying to me.
But my preferred way is the way Rob does I.e. laptop through USB into DAVE (running on battery)
However the laptop is connected through Wi-Fi to my home network and NAS.
am I missing a trick?

There are expensive streamers like DCS network bridge, Naim NDX, Aurender, Auralic, Melco, Innuous, Microrendu, but not sure why I need any of this when a simple laptop through battery is good? or is it not?

 

[Triode User]

erm - what's the best way to feed data to Dave?
I heard an auralic streamer with some posh Chord Ethernet cables, and the Ethernet cable made a difference which is quite annoying to me.
But my preferred way is the way Rob does I.e. laptop through USB into DAVE (running on battery)
However the laptop is connected through Wi-Fi to my home network and NAS.
am I missing a trick?

There are expensive streamers like DCS network bridge, Naim NDX, Aurender, Auralic, Melco, Innuous, Microrendu, but not sure why I need any of this when a simple laptop through battery is good? or is it not?

I'm not sure where you used the posh ethernet cables. Was that between the Auralic and the router?

I dont have a battery laptop so can only compare a mains powered iMac streaming Tidal (using WiFi). I have also used an Auralic Aries streamer (hard wired to my router). In both cases I used USB cable and also tried adding ferrites.

Then I had a home demo of an Innuos Zenith SE using it hard wired to the router with cheap (£5) ethernet cables. I wanted it to not sound any better. I wanted that very badly. It didn't happen and I have a Zenith SE on order.

 

[Pappadave]

I'm not sure where you used the posh ethernet cables. Was that between the Auralic and the router?

I dont have a battery laptop so can only compare a mains powered iMac streaming Tidal (using WiFi). I have also used an Auralic Aries streamer (hard wired to my router). In both cases I used USB cable and also tried adding ferrites.

Then I had a home demo of an Innuos Zenith SE using it hard wired to the router with cheap (£5) ethernet cables. I wanted it to not sound any better. I wanted that very badly. It didn't happen and I have a Zenith SE on order.

TU, but you feed Blu2 from Zenith via USB, right?

 

[Crgreen]

I feed my Dave from a laptop (mains) via a PS Audio LANRover and Iso Regen, both powered by their own Ultracap LPS-1 battery power supplies. I found that feeding the USB signal to the Dave through a battery power supply made a significant difference.

 

[Triode User]

TU, but you feed Blu2 from Zenith via USB, right?

I have two systems. I keep the Blu2 in the main system and bring the Dave through to the second system when I listen to that system. As the question concerned feeding the Dave I kept my answer based on my experiences in this Dave system without Blu2.

But yes, in the main system I feed Blu2 via USB and when the Zenith arrives I will feed it to Blu2 via USB.

 

[Rob Watts]

Hi Rob, regarding this old quote of yours - would you still recommend a USB cable with ferites, even if the USB source is battery based (like a mobile phone) running entirely off batteries?

Or is the USB cable with ferrites recommendation, more for mains power connected USB sources?

Cheers!

My listening tests revealed no change with ferrites on USB cables at all. But differing sources may give different results. I know some posters have reported improvements. Also, battery mode operation should mean no ground loops, so no current flow into the ground planes, then no RF noise pick-up in the DAC and so no problem... This has been validated by listening tests.

 

[flyte3333]

My listening tests revealed no change with ferrites on USB cables at all. But differing sources may give different results. I know some posters have reported improvements. Also, battery mode operation should mean no ground loops, so no current flow into the ground planes, then no RF noise pick-up in the DAC and so no problem... This has been validated by listening tests.

Fantastic.

Can RF emitted by a mobile (battery powered) source be picked up by the USB audio cabe? Or is this also no problem for the DAC?

Or is it a good idea to use a ferrite core USB cable, in this example?