HQPlayer's Network Audio Adapter

[Miska]

Hi Jussi, I would like to ssh/sftp onto it to manage it. Which is a very common way and the way I manage all my linux/Unix systems, OS independently. Most embedded board image files come with default credentials, for users to change themselves.

 

Since it is very minimal bare bones embedded system, there is not much to manage. You can modify the image to enable logins to access it using serial console. I rather make things such that you need to have knowledge to enable logins, rather than requiring knowledge how to secure a device. It is safer that way. You anyway need to have that same knowledge for managing the device as you need for enabling logins...

[bibo01]

CuBox has serial console on the microUSB connector. If you have Linux, drivers for that are included in the Linux kernel and it's ready to go, you can use minicom or screen as a terminal. Serial port settings are 115200,N,8,1 and no hardware handshake (CTS/RTS) and no carrier detect (DCD).

 

If you are on Windows, you can get FTDI's USB serial drivers here:

Virtual COM Port Drivers

And you can use PuTTY as terminal:

PuTTY Download Page

 

 

BeagleBone Black also has serial console, but you need a 3.3V TTL -level serial cable for it, same cable also works with MinnowBoard MAX and Intel Galileo for example:

Beagleboard:BeagleBone Black Serial - eLinux.org

 

Thanks.

I will pass it on.

[YashN]

Is anyone successfully using a Beaglebone as NAA for DSD256?

 

Would the following work?

 

Mac OS X doing DoP256 -> Beaglebone NAA?

 

Thanks.

[Miska]

Is anyone successfully using a Beaglebone as NAA for DSD256?

 

Would the following work?

 

Mac OS X doing DoP256 -> Beaglebone NAA?

 

If you have iFi iDSD Nano, you don't need to use DoP...

 

NAA lets you work around the OS X DSD limitations (as long as you don't use OS X as NAA).

[YashN]

If you have iFi iDSD Nano, you don't need to use DoP...

 

NAA lets you work around the OS X DSD limitations (as long as you don't use OS X as NAA).

 

Yes Miska, I know that because it was already playing native DSD256 streaming from Foobar2000 and a very old Windows XP computer that I optimised (my gf's old PC), but until I get myself a new PC, I am using my iMac as server which is more convenient for me currently.

 

Fortunately, the cool guys at iFi also recently made DSD256 available on Mac OS X directly.

 

So, the question is, if I get a Beaglebone soonish, can I do

 

Mac DoP256 -> Beaglebone (Linux) NAA?

[Miska]

Mac DoP256 -> Beaglebone (Linux) NAA?

 

But why would you use DoP in that case? It is not necessary...

 

When you are sending audio to NAA, the local CoreAudio is not used or involved in any way... Just set "SDM Pack" to none and play.

[YashN]

But why would you use DoP in that case? It is not necessary...

 

When you are sending audio to NAA, the local CoreAudio is not used or involved in any way... Just set "SDM Pack" to none and play.

 

Ah see, I wasn't aware of this subtlety although I think I read something similar in these pastures

 

Fun stuff, thanks!

 

So technically, I should be able to do Mac (SDM Pack DSD256) -> Beaglebone NAA, right?

[jabbr]

Ah see, I wasn't aware of this subtlety although I think I read something similar in these pastures

 

Fun stuff, thanks!

 

So technically, I should be able to do Mac (SDM Pack DSD256) -> Beaglebone NAA, right?

 

Not sure what you mean by "Mac (SDM Pack DSD256)" so I'll elaborate if I may:

 

Think of HQPlayer -> NAA as an OS neutral network protocol that directly streams DSD ... as well as PCM ... over TCP/IP.

 

Since Mac OSX doesn't understand direct DSD, over USB, in order to communicate over USB, DSD needs to be packed into PCM -- hence DoP. When communicating over TCP/IP you don't need a special kernel driver, rather just write to a socket. So DSD should always be direct to NAA.

 

So bottom line : turn off "SDM pack", use Linux or Windows for NAA and let the NAA send the DSD to the DAC directly.

[YashN]

Not sure what you mean by "Mac (SDM Pack DSD256)"

 

Should be Mac (No SDM Pack) as per Miska's reply above.

 

Since Mac OSX doesn't understand direct DSD, over USB, in order to communicate over USB, DSD needs to be packed into PCM -- hence DoP.

 

This much is known and this is what I was using on Mac OS X with the new iFi firmware/drivers up to DSD256 but through DoP.

 

When communicating over TCP/IP you don't need a special kernel driver, rather just write to a socket. So DSD should always be direct to NAA.

 

So bottom line : turn off "SDM pack", use Linux or Windows for NAA and let the NAA send the DSD to the DAC directly.

 

That's where we're heading!

[Miska]

So technically, I should be able to do Mac (SDM Pack DSD256) -> Beaglebone NAA, right?

 

Yes, it should work just fine. I've tested BBB together with iDSD Nano. It's my "quick'n'dirty test unit on my office desk I use to smoke test lot of stuff.

[YashN]

Yes, it should work just fine. I've tested BBB together with iDSD Nano. It's my "quick'n'dirty test unit on my office desk I use to smoke test lot of stuff.

 

 

Thanks Miska,

 

Yep cool little DAC that we've been having a lot of fun with here as well.

[jkelly]

Hate when this happens...

Using the cubox-i as the NAA, I noticed a change from 3.11 to 3.21.

On my system, 3.21 has less weight and I have noticed a slight edge to vocals at times.

 

Anyone notice this?

 

Jeff

[satbaba]

Hate when this happens...

Using the cubox-i as the NAA, I noticed a change from 3.11 to 3.21.

On my system, 3.21 has less weight and I have noticed a slight edge to vocals at times.

 

Anyone notice this?

 

Jeff

 

No, I did not hear any difference

[niner93]

I'm new to computer audio, especially HQPlayer. So here's my dumb question: My setup is full active 3-way stereo, CD player is my main source. I want to add DRC and crossover to the chain. I will have 6 channel (I2S input) DAC driving 6 channel power amps. 2 fanless PC are available to me: 1) Xeon E5 2630-V3 on Gigabyte X99M w/16GB & GTX950, and 2) I7-6700K on Gigabyte Z170 w/16GB & GTX970

 

Using HQPlayer, I don't know if either of these machines can handle DSD upsampling and 6 channel convolution at the same time. Now I'm thinking, can I split the task to 2 PC?

 

[PC1: HQPlayer upsampling & DRC] -> network -> [PC2: NAA & 6 channel crossover EQ] -> I2S -> DAC

 

Will this work? AcourateConvolver can handle crossover and EQ, but I'm not sure if it supports DSD.

[Miska]

I'm new to computer audio, especially HQPlayer. So here's my dumb question: My setup is full active 3-way stereo, CD player is my main source. I want to add DRC and crossover to the chain. I will have 6 channel (I2S input) DAC driving 6 channel power amps. 2 fanless PC are available to me: 1) Xeon E5 2630-V3 on Gigabyte X99M w/16GB & GTX950, and 2) I7-6700K on Gigabyte Z170 w/16GB & GTX970

 

Using HQPlayer, I don't know if either of these machines can handle DSD upsampling and 6 channel convolution at the same time.

 

You could try, but depending on upsampling and convolution filters it will probably work, thanks to GPU offload. In this kind of case, the GPU offload should help quite a lot.

 

Now I'm thinking, can I split the task to 2 PC?

 

[PC1: HQPlayer upsampling & DRC] -> network -> [PC2: NAA & 6 channel crossover EQ] -> I2S -> DAC

 

Will this work? AcourateConvolver can handle crossover and EQ, but I'm not sure if it supports DSD.

 

Acourate Convolver AFAIK doesn't handle DSD (never used it though), but for PCM output it could actually work that way. And it would be waste of resources to first upsample and then perform the crossover EQ. HQPlayer performs convolution first at source rate.

 

So in my opinion, better to split the work between CPU and GPU within the same machine, rather than trying to split the work between two computers.

[niner93]

You could try, but depending on upsampling and convolution filters it will probably work, thanks to GPU offload. In this kind of case, the GPU offload should help quite a lot.

 

 

 

Acourate Convolver AFAIK doesn't handle DSD (never used it though), but for PCM output it could actually work that way. And it would be waste of resources to first upsample and then perform the crossover EQ. HQPlayer performs convolution first at source rate.

 

So in my opinion, better to split the work between CPU and GPU within the same machine, rather than trying to split the work between two computers.

 

 

Thanks for the info. So out of these 2 PCs, which one has the best chance to be able to handle the load?

[Miska]

Thanks for the info. So out of these 2 PCs, which one has the best chance to be able to handle the load?

 

I'm not sure, both have their plus and minus sides, so it would best to just try and see... If you would swap the graphics cards, the Xeon could have edge since it has more cores, although not as fast as the i7, but the Xeon has also 2x faster memory bus and over 2x more cache.

[jppierme]

Hello

 

I have a question. Do you plan in your road map

 

new version pour rasperrypi ? as your cubox-i version

 

on osx, use hqplayer as an audio card ?

 

Thanks

 

JPP

[bibo01]

NAA images for Raspberry already exist:

https://www.signalyst.eu/bins/naa/v3/images/

 

Perhaps is not as good as Cubox if a lot of LAN bandwidth is required because Ethernet and USB share the same channel on Raspberry.

[giordy60]

but in the longer version of Raspberry pi 3 there is still sharing the USB and ethernet?

[Aleph]

Unfortunately yes!

[Miska]

new version pour rasperrypi ?

 

No, RasPi hardware design is crap. The current image works fine with the only usable configuration which is audio cards using the I2S bus (HifiBerry, etc).

 

on osx, use hqplayer as an audio card ?

 

No... OS X is already constant source of problems and pain.

[bibo01]

If I have an old cubox-i image installed (Oct '14) with a static IP, is it possible to update the system (kernel and networkaudiod) maintaining at the same time the setup?

[Miska]

If I have an old cubox-i image installed (Oct '14) with a static IP, is it possible to update the system (kernel and networkaudiod) maintaining at the same time the setup?

 

Newest images are quite different from the old ones, so not very easily. If you like to upgrade gradually without just rewriting the microSD (or creating new one), I'd recommend going through the Debian route. That gives pretty much full upgradeability, although over time operating systems change and some configurations may need to be redone in a different way.

[bibo01]

Newest images are quite different from the old ones, so not very easily. If you like to upgrade gradually without just rewriting the microSD (or creating new one), I'd recommend going through the Debian route. That gives pretty much full upgradeability, although over time operating systems change and some configurations may need to be redone in a different way.

OK. Could you please tell me what Debian and deamon versions an Oct '14 Cubox image has.