The Best DAC is no DAC

I tried the I2SoverUSB converter with direct out DSD connections with first order filter, which apparently is how the European guys are doing it.
But I couldn't get it to work with JRiver encoding to dsd. Does it only work with foobar? Any ideas?
I've been using Pono Music World player lately, which is a re-badged version of JRiver. It beats Foobar hands down through my EMU sound card, but I can't get it to work with my USBtoI2S board. Foobar is still working, but I still haven't been able to work out the bugs described in my first post.

What is f3 on your LPF?
 
Has anybody tried Bug Head Emperor's player in DSD?
At least on PCM tracks it sounds better than Foobar, IMHO.

Bug head

Cheers,
M.
Max, thanks for pointing me to Bug Head Emperor. I've downloaded v4.78. Played it through my EMU sound card last night and it sounds great. Better than Foobar, and better even than Pono Music World (aka JRiver) which has been my preferred player for the last few months. but I can't get it to work with my DIYinHK USBtoI2S board. Configuring BHE to output DoP, (and playing dsf/dff files) it plays at double speed. There are so many config options, most of which I don't understand, and I can't figure out if this is a bug or a config issue.
 
I think this is what the late Allen Wright was using with his SACD player upgrades. I owned one for several years and the sound quality was excellent.

http://www.vacuumstate.com/fileupload/SACD_2005.pdf

Also, there is no need to focus on USB devices. Something like a Beaglebone Black running miero's Botic Linux distribution will accept streamed native DSD and output DSD on the BBB header and if coupled with something like Acko's SO3 and BBB interface board or TPA Chronus/Hermes combo you can have the data isolated from the BBB and reclocked through a FIFO to reduce jitter.

I'm currently streaming dsf and dff files in this way, over a UPnP infrastructure (Media Library - Asset V5 beta 8; control point - BubbleUPnP). I'm using an Acko SO3 reclocker and BBB/DSD interface card, to deliver reclocked data to a Buffalo IIIse DAC.

Ray
Hi Ray, thanks for your input on this thread. I understand your first 2 sentences. And this is indeed where i got the first inspiration for the no-DAC approach (I attributed it to Allan's business partner Joe Rasmussen in my first post).

But after that - I have no idea what you are talking about. Sorry, I don't mean that in a rude way. I do not understand computers much. I can turn one on, and use email and forums and foobar, but this is all beyond me. But we are all trying to get to the same place. Seems like there is an alternative approach, and I would like to explore this more.

I looked at the other thread that you are heavily involved in. This diagram I found there is interesting. Question - why can't we take DSD from the BeagleBone directly to LPF? What exactly does the reclocker do - actually why is it important?
 

Attachments

  • DSD only Audio.png
    DSD only Audio.png
    229 KB · Views: 1,826
Max, thanks for pointing me to Bug Head Emperor. I've downloaded v4.78. Played it through my EMU sound card last night and it sounds great. Better than Foobar, and better even than Pono Music World (aka JRiver) which has been my preferred player for the last few months. but I can't get it to work with my DIYinHK USBtoI2S board. Configuring BHE to output DoP, (and playing dsf/dff files) it plays at double speed. There are so many config options, most of which I don't understand, and I can't figure out if this is a bug or a config issue.

Maybe it is time to email the inventor...I don't read Japanese either...


right now I am taking the DSD output off the USB board (single ended) to a pair of Lundahl LL1527XL trannies

Maybe using a lower bandwith transformer will produce better tonal balance...

Have fun.

M.
 
.. why can't we take DSD from the BeagleBone directly to LPF? What exactly does the reclocker do - actually why is it important?

This is going off topic a bit, but using de DSD from the BBB would work.

However a reclocker does several nice things, it provides much better clocking to the BBB (see arrow in the diagram going to the left), this works when using Miero's "Botic" driver (http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver.html). & the reclocker then reclocks (with the same clock) and provides ground plane isolation.

All this will be quite the learning curve, but well worth the time and effort, if you enjoy this sort of thing. :)
 
Then recently I read that Delta Sigma DACs (including the CS4398 which is on the EMU sound card) convert PCM to single bit during conversion.

Actually this is not true. Like most decent quality "modern" dac chips, the CS4398 uses multibit sigma delta modulation. Usually it's around 4-6 bits and several MHz, depending on the chip.

Something like 20 years ago, the 1-bit noise shaped DACs appeared, took over the audio world, and buried the old multibit dinosaurs (PCM63, TDA1541 etc). This happened based solely on price. It is much cheaper to make a 1-bit DAC (it is basically a little CMOS DSP) than a PCM63 or the like (analog process, bicmos, needs very precise matching, thin film resistors, etc). Of course, most of those 1-bits were horrible sounding, but that's not the point. They measured "not too bad" and were cheap. This was a very sad time for hifi.

A bit later, around year 2000 or something, the chip manufacturers developed the current concept of multibit delta sigma, and how to manufacture it cheaply. Not as cheap as 1-bits, but acceptably cheap (ie, not PCM1704). Since those new DACs are better than 1-bits on everything, like measured performance, but especially sound quality, we can finally forget that painful time and move on.

So... you can still find plenty of 1-bits, in lots of application, where it has to be very cheap (like cellphones or other low quality audio) or cheap and linear but slow (industrial), that kind of stuff. And SACD.



Anyway. One of the biggest problems of 1-bits is that it is difficult to make an analog output stage for it, because of the high slew rate and huge amount of HF noise. Opamps fail at this, sometimes spectacularly, depending on the implementation.

This is why everyone upsamples their DSD, filters it in DSP and outputs it using multibit modulator. All DSD-compatible DACs do this, because if you design a chip, that's the only reasonable thing to do.

The other way to do it is to use an analog output stage that doesn't care about HF noise or slew rate, like a transformer. I had tried that on a CD63SE back in the day. It still sucked, but less than the original.

Of course since your DAC is basically a logic gate, and its output is the product of its power supply and the digital value, it means you have to use a balanced output... for example you can use a 74HC flop with normal and inverting output. It should have a very clean power supply... and some filtering on the output... and then your transformer.
 
Of course since your DAC is basically a logic gate, and its output is the product of its power supply and the digital value, it means you have to use a balanced output... for example you can use a 74HC flop with normal and inverting output. It should have a very clean power supply... and some filtering on the output... and then your transformer.
What about using a USB receiver with balanced DSD output

HiFime UH1-Digital 384Khz USB to I2S/DSD/COAX interface (no DAC)

Using HDMI as output port is a bit weird, but I'm sure we can work around that. So a LPF on the balanced output and then the Lundahl transformer - that should work as you recommend?
 
But after that - I have no idea what you are talking about. Sorry, I don't mean that in a rude way. I do not understand computers much. I can turn one on, and use email and forums and foobar, but this is all beyond me. But we are all trying to get to the same place. Seems like there is an alternative approach, and I would like to explore this more.

I looked at the other thread that you are heavily involved in. This diagram I found there is interesting. Question - why can't we take DSD from the BeagleBone directly to LPF? What exactly does the reclocker do - actually why is it important?

No worries, we all have different slants on things but often we're actually heading in the same direction. Just shout if you need something explaining.

I think Stijn001 has answered your questions as well as I could;

This is going off topic a bit, but using de DSD from the BBB would work.

However a reclocker does several nice things, it provides much better clocking to the BBB (see arrow in the diagram going to the left), this works when using Miero's "Botic" driver (http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver.html). & the reclocker then reclocks (with the same clock) and provides ground plane isolation.

All this will be quite the learning curve, but well worth the time and effort, if you enjoy this sort of thing. :)

but I would add a little more information (not completely related to this thread but still important);


  • Not only does the reclocker improve the clocking of the BBB but it also gets around its shortcoming of only having a single clock that works with 48KHz data family sampling rates. A stock BBB will have to resample 44.1KHz data rates to 48KHz and that may be audible. By disabling the BBB's onboard clock and using the two reclocker clocks native data sample rates are preserved.

and a little more emphasis;


  • The key benefit of the reclocker module is less jitter and I believe that is fundamentally important to DSD. In fact, the reclocker isn't just about devices like the Beaglebone, it will bring similar sound quality improvements to many of the USB devices that have been mentioned in this thread (you may note that Acko originally developed his reclocker board for use with the Amanero USB board).
Anyway, watching developments on the thread topic area with interest.

Ray
 


Good points, these isolator/reclocking board, can cleanup the DSD feed, which looks to be even more critical with these "none dac" designs. As the DSD bitstream effectively directly "drives" (for lack of a better word) the analogue signal, it needs to be as clean as possible in terms of artifacts etc.

I'm sure someone will get around doing some comparisons between the different sources at some point.
 
...cleanup the DSD feed, which looks to be even more critical with these "none dac" designs. As the DSD bitstream effectively directly "drives" (for lack of a better word) the analogue signal, it needs to be as clean as possible in terms of artifacts etc.

stijn001, I noticed your post over on the Signalyst thread about the HQPlayer software. I've been having a look at JRiver and it seems to offer similar capabilities to upsample on the fly, apply filters etc. As I have it installed on my laptop I thought I might explore some of the capability with the BBB/Botic.

Ray
 
Thanks Ray. It's been a while since I looked at Jriver. I was also intrested in a DSP function in conjunction with REW, which HQplayer offers (although this is possible with JRiver too, but more manual). The guys over at Signalyst seem to be to be pretty hardware minded as well, so my hope is they'll port HQplayer for a BBB/RPI image at some point, so we can have an embedded realtime software conversion/DSP source.

Sorry to go a bit of topic here.

The problem I have with streaming from a JRiver client, is Wifi performance to the BBB/Botic, like this: NAS ->WiFi ->Laptop/Jriver->Wifi->BBB/Botic. I.e. the audio stream going over WiFi twice..

I get a more stable feed like this : NAS ->1G ethernet->BBB/Botic (<-> control plane only via WiFi with Laptop/Tablet)

Or are you planning to do it differently?
 
Thanks Ray. It's been a while since I looked at Jriver. I was also intrested in a DSP function in conjunction with REW, which HQplayer offers (although this is possible with JRiver too, but more manual). The guys over at Signalyst seem to be to be pretty hardware minded as well, so my hope is they'll port HQplayer for a BBB/RPI image at some point, so we can have an embedded realtime software conversion/DSP source.

Sorry to go a bit of topic here.

The problem I have with streaming from a JRiver client, is Wifi performance to the BBB/Botic, like this: NAS ->WiFi ->Laptop/Jriver->Wifi->BBB/Botic. I.e. the audio stream going over WiFi twice..

I get a more stable feed like this : NAS ->1G ethernet->BBB/Botic (<-> control plane only via WiFi with Laptop/Tablet)

Or are you planning to do it differently?

I've only lifted the lid on JRiver so far and have seen what appears to be some features similar to those offered by HQPlayer; I need to open the box and explore further to get a better appreciation of it's capabilities/functionality.

As things settle down with my renderer etc. the only place for wireless will be for the control point, everything else will be wired connections.

Ray
 
Of course since your DAC is basically a logic gate, and its output is the product of its power supply and the digital value, it means you have to use a balanced output... for example you can use a 74HC flop with normal and inverting output. It should have a very clean power supply... and some filtering on the output... and then your transformer.
Hi, using a balanced output is obviously sensible. Is this device the sort of thisng you mean?

74HC74 datasheet(1/22 Pages) PHILIPS | Dual D-type flip-flop with set and reset; positive-edge trigger

It has a 'true flip flop output' and a complementary output. Its got 2 channels, so should work fine for stereo. Each channel has its own clock input;in our case I assume that the clock is shared.

Heck, I'm an analog guy and that's why I wanted to build a SACD player with no DAC. What the heck is a flip flop anyway?
 
Or are you planning to do it differently?

I'm beginning to think that the best way to go about this might not involve BBB/botic or the like and perhaps a USB solution is better.

I've been reading various sources on this simple DSD 'DAC' topic and one of the consistent themes is that the 'faster' the DSD the better (for lower noise), ideally aiming for DSD256 or DSD512. I believe BBB will run out of steam beyond DSD128.

Perhaps this is the way to go - a dedicated Linux distribution with HQPlayer or JRiver embedded but apparently controllable from a UPnP control point. There's some interesting info here, though I don't think the guy will win any awards for website design!

AudioLinux - The audiophile realtime plug & play operative system

That maps to an chain something like;

NAS (UPnP media Server) >> AudioLinux/HQPlayer (Upsample to DSD256/512) >> USB >> Reclocker >> DSD 'DAC'
V
V
Other UPnP Renderers

There are a number of interesting and relevant threads over on Computer Audiophile

Ray