Okto Research DAC8 Pro

[Miska]

Not many that can do multichannel DSD256 though...

 

[Miska]

9 hours ago, LewinskiH01 said:

BTW, these are the ones I'm aware of. Am I missing significant contenders?

- Merging NADAC

 

Merging Hapi and Horus

[Miska]

37 minutes ago, LewinskiH01 said:

With which card would you configure a Hapi? How steep is the learning curve?

 

If you need just D/A, then DA8P obviously. For A/D AKD8DP.

 

When playing from HQPlayer it is not so much different. There is some configuration to do and you need to make connections from the driver to the DAC so that the system knows where things should go. Yet get more reliable on home networks if you use unicast stream.

 

45 minutes ago, LewinskiH01 said:

FWIW, I don't know that DSD256 is a requirement. I don't do DSD today and wonder how much horsepower a PC would need to convolve DSD256 filters in HQP.

 

If your sources are multichannel DSD256 and your output is multichannel DSD256, then it is quite heavy. If your sources are RedBook or something like that, or multichannel PCM at 96k, then it is pretty light weight. Although GPU can help on that. Now there are many CPUs with 8 or more cores, and the biggest CPU available now is 64 cores AMD Threadripper.

 

[Miska]

9 minutes ago, LewinskiH01 said:

The DB-25 connector out of the Hapi DA8P is nothing like I've used before. Probably worth exploring further. I guess no audiophile-grade cable for that spot

 

It is industry standard "TASCAM configuration", used by lot of pro-audio gear. I got DB-25 to XLR breakout cables from thomann.de for the purpose.

 

If it's "audiophile-grade" enough for recording studios, it is for me too...

 

[Miska]

23 hours ago, alec_eiffel said:

I had no problem streaming multichannel DSD128 from a Linux-based streamer though.

 

No 8 channel DSD256 though?

 

[Miska]

On 2/29/2020 at 12:51 AM, Kal Rubinson said:

I took a look and there is a single clock running four BB SRC4382 Two-Channel, Asynchronous Sample Rate Converters with Integrated Digital Audio Interface Receiver and Transmitter.

 

Jitter bake-in...

 

[Miska]

6 hours ago, alec_eiffel said:

No, "only" DSD128. Pavel nevertheless confirmed that all incoming DSD is kept as DSD, which is good. @Miska I really believe the DAC8 PRO is worth a try as an alternative to Exasound in a multichannel setup, maybe email them to be part of the ongoing tour. 

 

My exaSound can already do 8 channels of DSD256 or PCM 384/32, so I'm not in huge need of something that does less. Also Hapi can do the same...

[Miska]

55 minutes ago, Snoozer said:

-> Big pop/click at the beginning of a new track is the family rate is different from the previous track (either going from 44.1kx128 to 48kx128 OR from 48kx128 to 44.1kx128). It is a huge spike on the output that is not present in the original music content and that might well damage a twitter. I consider that a big engineering design flaw unless my unit is defective, of course. 

 

This happens when DAC doesn't mute it's outputs during mode transitions on begin/end of DSD stream.

 

DAC should mute it's output for at least 50 ms duration during beginning and end of DSD. So mute before DSD stream starts and unmute after it has started. Same for the end. If this is not done properly, you will get those pops, because it takes time for DSD conversion to establish a state.

 

1 hour ago, Snoozer said:

Do you guys happen to have tested DSD upsampling with HQplayer on Linux ? Did it work as expected ?

 

Yes, a lot, because Linux is the primary HQPlayer development platform. So it is used a lot every day.

 

[Miska]

On 4/6/2021 at 12:10 AM, Snoozer said:

"to allow my Roon player insert a silence after each track". I tried that and it kind of seemed alleviating a little bit the problem, but still .... the huge spike between tracks is there.  

 

It helps, but it doesn't fix the problem. Only proper way is to have enough analog mute time before and after the DSD mode transition. One of the reasons mute relays/transistors must be there.

 

DSD spec requires about 50 ms mute period around the transition.

 

[Miska]

On 4/8/2021 at 3:12 PM, Snoozer said:

Does it necessarily mean a hardware solution ?. It seems to me that relays and transistors is the "hard" way to solve. Do you happen to be aware if that has been solved via firmware by telling the XMOS to mute the Sabre by 50ms ?.

 

Well, I've seen many attempts trying to solve it through Sabre without mute relays/transistors and so far failing every time. Sabre doesn't support mute functionality when it's digital filters are bypassed OR when it is operating in DSD mode...

 

In addition, the settling also applies to the analog filter stage following the DAC chip.

 

On 4/8/2021 at 3:12 PM, Snoozer said:

muting via software is fairly straightforward within the XMOS microcode

 

It is and it is not, because it requires look-ahead buffer, so that you can mute at least 25 ms before any DSD data goes out to the DAC. And 25 ms before the last bit goes out to the DAC. And then of course the mute needs to actually do something... XMOS just sends out control signal, but that control signal actually needs to control some mute functionality too. This is especially important with Sabre where you cannot tell over I2C/SPI interface to switch between PCM and DSD modes like other DAC chips. Instead it automatically switches the mode based on detected pattern on input data pins - but this takes some amount of time, during which the output is just a mess.

 

If you use DoP, this becomes even more crucial, because the detection requires 32 samples which equals to 512 DSD bits. Which is not long at 181 µs, but still you have audible glitch if you don't handle it properly.

 

 

These days, problems in this area are not common anymore in new DACs, most handle it properly now.

 

[Miska]

3 hours ago, Matt 5FE1 said:

@Miska

 

- First question is if I need 2 NAAs (not a problem) - how would I connect the DAC which has one physical USB port? 

 

I kind of don't understand why two NAA's and one DAC? Can you explain a bit more?

 

Quote

- Second question is would I be better off with a separate 8x AES usb or ethernet interface into the NAA and output to DAC.?  

 

Not sure I understand this, but you cannot use same device for both input and upsampled output, because it has only single clock. So you need separate input and output devices.

 

Quote

- Thirdly, is there another way to be able to PEQs without interrupting the stream (as you can on the XD) and keep the awesome hqplayerd upsampling last thing before the dac?

 

XD? Interrupting the stream?

 

As an example, I use RME ADI-2 Pro for analog + digital inputs, it is connected to hqplayerd through USB. Then I use some other device as a DAC at DSD256 (Holo Spring, Denafrips, exaSound, Merging Hapi...)

 

[Miska]

On 9/24/2021 at 9:38 PM, Matt 5FE1 said:

Quick question - any thoughts on something like a Digigram vx880 as an alternative aes interface?  Not as pretty as the RME.

 

It says Digigram has sample rate converter on input, which is something I'd avoid.

 

On 9/22/2021 at 12:35 AM, Matt 5FE1 said:

I need to get the aes output from the Xilica into hqplayerd.  This could be done with an RME as an alternative;

 

Some simple AES input hardware would do for this. Just look for something that doesn't do rate conversions and thus can be clock-slaved to the AES.

 

On 9/22/2021 at 12:35 AM, Matt 5FE1 said:

So my attempt is to use the hqplayer filters on the xilica output to improve SQ.

 

It will only work if the Xilica doesn't already spoil the data.

 

On 9/22/2021 at 12:35 AM, Matt 5FE1 said:

I think the answer might be to configure the DAC8 as two devices one input and one output in hqplayerd.xml.  This seemed to work on windows for hqdesktop.

 

I'm still pretty confident it won't work for upsampling. Because very likely DAC8 doesn't expose two completely separate USB audio devices. Meaning that if you have it working with different rates on input and output, you are likely having sample rate conversion somewhere outside of HQPlayer, which is something you'd like to avoid.