The Best DAC is no DAC

I suggest you need to reduce the number of variables and I would start by establishing whether everything works as expected with the playback of various rate .dsf files (downloads rather than offline converted with JRiver). If everything works that way you'll know the issue is with your upsampling and if it doesn't suspicion turns towards your USB board/driver.

Let us know how that goes.

Ray
i play .dsf file, sound very good, still little wait noise when i play the file and pause.
same noise from foobar. i suspect the XMOS, maybe i need to insert isolator.
 
I've had a small package delivered so have been busy today making up my first flip-flop board;

DSCF0953_zpsaz0elqdn.jpg


I'm short of a couple of components but have done some testing using usb power from the new NUC;

DSCF0947_zpsdjegz0io.jpg


I've linked J1 and J2 to power the DSD data indicator circuit from the 'dirty' side 5V. The circuit works as the LED lights up when I have 'SDM (DSD)' selected in HQPlayer (and goes off with 'PCM' selected).

I can also here the relay clicking when the codec header switches.

I'm waiting on the resistors for the LP filter now but its looking good.

Ray
 
But, unfortunately I have an issue. Initially the relay (Ray’s pcb), kept cutting the signal seemingly at random between 5 to 10 sec. This suggested pin 7 on the JLSounds board, was pulled high/low. However, after taking off the relay, I still got drops in the signal (not the loud codec change pops) roughly at the same random intervals. This indicates two things, the relay was trigger by something other than pin 7 going high/low and secondly something other than the relay is disrupting the signal. (maybe a fault on the PCB?)

Stijn, when I was testing the flip flop board I noticed some apparently random clicking of the relay. I was doing some large uploads to my cloud storage so the network was busy and the clicks appeared to correlate to network peaks and I could eliminate them by lowering the DSD data rate.

I use a dedicated subnet between my HQP and NAA computers on the main system.

Ray
 
Nice progress Ray.

Thanks, when I wrote about the issue before, it also occured with local files, so that (and network utilisation) excluded a network issue in my case.

Thanks Stijn.

Are you still experiencing the clicking?

The conclusion I draw (actually it's pretty obvious if you think about it because the de-energised position of the relay is mute) is that any momentary interruption to the incoming signal, for whatever cause, will cause pin 7 to go 'low', thus deactivating the relay coil.

There are some interesting, if rather more complex, developments over on the Signalyst DSC1 thread. It would be interesting to compare the Signalyst and simple LP filter solutions.

http://www.diyaudio.com/forums/digital-line-level/254935-signalyst-dsc1-20.html#post4553923

Ray
 
@nautibuoy:

You're welcome Jesper. I haven't paid close attention to the CPU loadings as I've focussed on DSD256 but I can check the CPU loadings at different sample rates for you later. I'll select a filter/shaping option applicable to all three data rates and run the same track for each data rate and let you know.

Ray

Thanks Ray ... could be interesting to learn what the differences are.

And, not least, I look forward to reading more about your Simple DAC endeavour ;-)

Jesper
 
Thanks Stijn.

Are you still experiencing the clicking?

Setting the buffer time in HQPlayer to 250ms (almost) solved it. I still have an occasional glitch, what sounds like a codec artifact, when converting in HQPlayer.

After I discovered upsampling in HQPLayer to higher rate PCM sounds nearly as good as resampling to DSD, I wonder if much of the sonic improvement is due to HQPlayer. I might have a go at getting NAA to work on the BBB with Miero's botic, playing PCM, as a next (intermediate) step. If and when I find the time.
 
Ray, I think you might like this thread. Obviously you'll just have to take some of it with a grain of salt... I don't think they know what direction electrons flow.

Streamer to kill the big boys for under $250

The NUC's appear to be even better when used as the streamer, not the server. It makes sense. And then you can upgrade their PSU, and perhaps isolate the two with fiber. Then upgrade the fiber adapters PSU... hahaha it never ends...
 
Ray, I think you might like this thread. Obviously you'll just have to take some of it with a grain of salt... I don't think they know what direction electrons flow.

Streamer to kill the big boys for under $250

The NUC's appear to be even better when used as the streamer, not the server. It makes sense. And then you can upgrade their PSU, and perhaps isolate the two with fiber. Then upgrade the fiber adapters PSU... hahaha it never ends...


That's exactly how he's using it. Just without Audiolinux and the AirPlay support.
 
That's exactly how he's using it. Just without Audiolinux and the AirPlay support.

Mike, I have to ask, are you Blizzard?

To be honest, I don't see how you could use a NUC, or similar low power silent computer, for anything other than the renderer/streamer component as it simply doesn't have the processing power to be able to run HQPlayer's upsampling algorithms, whereas processing the streamed output from HQPlayer is light work for it.

The NAA rationale is sound too; it enables you to keep the upsampling computer, which will typically have 'noisy' fans and the like, physically separate from your listening environment.

Some further observations:

I have found the need to use a separate dedicated network link (requiring a second network card in the HQP server and a length of standard CAT5/6 Ethernet crossover cable) between the HQPlayer server and the NAA as my experience is that does improve on the listening experience but in a very simple way; the nature of Ethernet networks means that the traffic from devices on the network can, and will, collide, and the level of collisions increases significantly as you start to load the network. If you're doing word processing these network events are generally insignificant but I was experiencing occasional dropouts in the audio signal that correlated to increased network activity and which have been eliminated by implementing a subnet that isolates the HQP stream from the rest of my home network (HQP server is still connected to the home network to facilitate remote control etc.). So, the dedicated subnet is simply about getting a contiguous, uninterrupted, stream of data to the NAA device, nothing more.

To me, IanCanada's isolator/reclocker and similar solutions that are becoming increasingly common integrated into products (such as the JLSounds USB board) fundamentally change the equation with respect to the influence of 'upstream' infrastructure. Done well, isolator/reclocker solutions regenerate a very high quality (clean and accurate) digital signal to pass to your chosen DAC solution and I am sceptical that noise/jitter/whatever from upstream, unless so extreme that it is fundamentally interrupting the flow of data into the isolator/reclocker, is present on the output from the reclocker. That view is based on my experience with my ES9018 DAC that uses Acko's SO3 isolator/reclocker, as I mentioned a few posts back.

In the NAA context I am also sceptical about the need for AudioLinux. By it's very nature, the NAA is doing only one fundamental task and that isn't very demanding. I have tried both Audiolinux and standard Debian Stretch core on my Atom550 NAA device (less powerful processor than the new NUC) and could hear no difference. In addition, for NAA duty, compared with Debian Stretch, AudioLinux is positively bloated with added-on software that you're never going to use; you don't even need a GUI for an NAA. And, although academic in my case as I purchased Audiolinux, Debian Stretch is free.

Just my penn'orth

Ray
 
After posting the pictures of the new flip-flop board a couple of posts back I have received enquiries from people wanting to obtain PCBs.

I have a few spare flip-flop boards (and will have some of the revised simple filter and mute boards when they arrive) but I prefer to not offer them out until I have examples tested and working.

Assuming success, just wondering if people would prefer just the PCB or perhaps a part kit with most of the parts (except for the variables, such as the filter resistors/caps)?

Ray
 
Mike, I have to ask, are you Blizzard?

To be honest, I don't see how you could use a NUC, or similar low power silent computer, for anything other than the renderer/streamer component as it simply doesn't have the processing power to be able to run HQPlayer's upsampling algorithms, whereas processing the streamed output from HQPlayer is light work for it.

The NAA rationale is sound too; it enables you to keep the upsampling computer, which will typically have 'noisy' fans and the like, physically separate from your listening environment.

Some further observations:

I have found the need to use a separate dedicated network link (requiring a second network card in the HQP server and a length of standard CAT5/6 Ethernet crossover cable) between the HQPlayer server and the NAA as my experience is that does improve on the listening experience but in a very simple way; the nature of Ethernet networks means that the traffic from devices on the network can, and will, collide, and the level of collisions increases significantly as you start to load the network. If you're doing word processing these network events are generally insignificant but I was experiencing occasional dropouts in the audio signal that correlated to increased network activity and which have been eliminated by implementing a subnet that isolates the HQP stream from the rest of my home network (HQP server is still connected to the home network to facilitate remote control etc.). So, the dedicated subnet is simply about getting a contiguous, uninterrupted, stream of data to the NAA device, nothing more.

To me, IanCanada's isolator/reclocker and similar solutions that are becoming increasingly common integrated into products (such as the JLSounds USB board) fundamentally change the equation with respect to the influence of 'upstream' infrastructure. Done well, isolator/reclocker solutions regenerate a very high quality (clean and accurate) digital signal to pass to your chosen DAC solution and I am sceptical that noise/jitter/whatever from upstream, unless so extreme that it is fundamentally interrupting the flow of data into the isolator/reclocker, is present on the output from the reclocker. That view is based on my experience with my ES9018 DAC that uses Acko's SO3 isolator/reclocker, as I mentioned a few posts back.

In the NAA context I am also sceptical about the need for AudioLinux. By it's very nature, the NAA is doing only one fundamental task and that isn't very demanding. I have tried both Audiolinux and standard Debian Stretch core on my Atom550 NAA device (less powerful processor than the new NUC) and could hear no difference. In addition, for NAA duty, compared with Debian Stretch, AudioLinux is positively bloated with added-on software that you're never going to use; you don't even need a GUI for an NAA. And, although academic in my case as I purchased Audiolinux, Debian Stretch is free.

Just my penn'orth

Ray


Yes that's me. The Audiolinux I'm using there is a custom slimmed down version. It runs in command line, and also has a AirPlay receiver as well that takes over when HQplayer is closed. I set up the image so it's plug and play with this unit. Burn to USB, turn it on, and it works. Most of the guys on that forum have no idea how to do anything with Linux, and if it wasn't that easy, they wouldn't consider it. One guy who set it up is running $250k worth of speakers and amps, and pre alone. Lots of guys like that on there who think if something doesn't cost big bucks, it can't be good. Although I'm sure HQplayer combined with this would beat a 10k Aurender streaming files from a NAS via UPNP.
 
After posting the pictures of the new flip-flop board a couple of posts back I have received enquiries from people wanting to obtain PCBs.

I have a few spare flip-flop boards (and will have some of the revised simple filter and mute boards when they arrive) but I prefer to not offer them out until I have examples tested and working.

Assuming success, just wondering if people would prefer just the PCB or perhaps a part kit with most of the parts (except for the variables, such as the filter resistors/caps)?

Ray
I'd be keen for a pcb and kit of bits and happy to pay up front so you're not having to invest your own funds to help us out
 
Thanks for the feedback, Ray. If you'll allow me another question in this direction (?): Have you noticed what the difference in CPU load is when moving e.g. from DSD64 to DSD128 to DSD256? I'm wondering if it is a linear relationship or maybe the higher samplingsrates mean a much higher load on the CPU?

Cheers,

Jesper

Hi Jesper, sorry I took a little time to get around to this.

I did a short test on this a little earlier. Setting the HQPlayer options to Poly-sinc-2s and DSD5 I ran the same piece of music at DSD64, 128 and 256 rates. Nothing else was running on the computer. The 'results' were;

Bitrate = 12288000, cpu = 33%
Bitrate = 6144000, cpu = 17%
Bitrate = 3072000, cpu = 9%

I don't claim that this is particularly scientific as all I did to obtain the results was to watch the performance monitor in Windows and estimate the average load, however, the loads were fairly constant with, by and large, just a few percentage points variation.

Ray
 
Hi Ray - thanks for your feedback ... actually the time frame is fine with me - I didn't expect you to post the results "immediately" ... personally I prefer to take the time that is reasonable/suitable to me and invite others to do so as well (unless something specific is agreed on). Just FYI ;-)

Regarding the measurements I find them quite interesting because - assuming there is some credence to Windows' performance monitor - it looks like it's linear: 9*2 is 18; 17*2 is 33; 33*2 may be 66% ...? Which, besides being interesting in and of itself, could mean that the computer you have may be capable of DSD512 ... (you used Win7, right?) ... Fascinating thought I think 🙄

Thanks again for taking the time to try this out Ray :wave2:

Jesper
 
Hi Ray - thanks for your feedback ... actually the time frame is fine with me - I didn't expect you to post the results "immediately" ... personally I prefer to take the time that is reasonable/suitable to me and invite others to do so as well (unless something specific is agreed on). Just FYI ;-)

Regarding the measurements I find them quite interesting because - assuming there is some credence to Windows' performance monitor - it looks like it's linear: 9*2 is 18; 17*2 is 33; 33*2 may be 66% ...? Which, besides being interesting in and of itself, could mean that the computer you have may be capable of DSD512 ... (you used Win7, right?) ... Fascinating thought I think 🙄

Thanks again for taking the time to try this out Ray :wave2:

Jesper

No problem Jesper.

Yes, I was thinking the same that they look pretty linear and the small anomalies could easily be down to my interpretation of the performance monitor moving graphs. Simple interpolation suggests DSD512 might be possible if I had the means of rendering the output.

My main HQPlayer PC is running Win10.

Ray
 
@ nautibuoy:

Simple interpolation suggests DSD512 might be possible if I had the means of rendering the output.

I suppose you already know that Amanero's combo384 is capable of DSD512? I have a combo384 board myself but haven't been able to run it at DSD512 due to my computer not being capable of performing at this speed. But it does setup to do so in HQPlayer, Jriver (if I remember correctly) and foobar.

Cheers,

Jesper
 
@ nautibuoy:



I suppose you already know that Amanero's combo384 is capable of DSD512? I have a combo384 board myself but haven't been able to run it at DSD512 due to my computer not being capable of performing at this speed. But it does setup to do so in HQPlayer, Jriver (if I remember correctly) and foobar.

Cheers,

Jesper

Hi
I have tested the Amanero usb/I2S board at DSD512 and it works well.

Br
Caad.