HQPlayer's Network Audio Adapter

[jabbr]

You need Windows and ASIO driver to get DSD256 on iDSD Nano. Same thing for DSD512 on iDSD Micro...

 

For DSD512 on iDSD Micro do I need Windows as desktop (HQPlayer) or for NAA? Was is best hardware for NAA?

[jabbr]

I have NO idea. The only comparison test I did was between my 2012 i7 16GB Mac mini and the CuBox-i4Pro (both powered by JS-2 LPS; both booted with text-only Linux/NAA image created and optimized by Miska).

 

I think Miska feels that there should not be such a large difference as the one I hear. But maybe the quality of the CuBox-i USB is not so good, or that the large cache of the Mac's i7 is some advantage--I really don't know. And I have never listened to a SOtM sMS-100, but I hear that many people enjoy it as an NAA and s/w support for that is excellent (can also be used with LMS, DLNA, and several other server softwares).

 

Hard to know here ... don't really want to spend $1400 for a 16gb i7 mac mini on an experiment ... or to use it as a FIFO in an Ethernet -> USB adapter.

 

If this approach were to work, I would also consider something like RaspberryPi with an I2S output.

 

The fact that you find the sound so much different really calls into question the whole basis of these ideas about power supply and digital switching noise. I'm inclined to test the Cubox vs. my Macbook Pro given that its only 10% the cost of the mini. I guess I could also look at some of my older Mini's ... hmmm think I might have an older one whose hard drive is on the fritz anyways

[jabbr]

Gee, I bought mine as a refurb with warranty from the Apple Store this past July for $679 (then paid $125 for the 16GB of RAM, and of course went the LPS and fan controller route).

 

But yes, my customized Mac mini is a LOT more expensive than a CuBox-i. And based on direct experience of the SQ of MacBook Pros and Airs (booted with the same Mavericks SD card as I use for my mini; tried both on battery and from the wall), I would not expect it be much better than the CuBox.

 

Fair enough -- unfortunately the latest (2014) mini's no longer allow memory upgrades :-/

 

Theories about what makes better SQ are all fine and good. Clearly digital noise is an issue. On the other hand theories can degenerate into a bunch of gobbledygook if they don't make useful predictions about future behavior.

 

So here's my issue: if the idea of minimizing interfaces thus reducing switching noise affecting the power plane is true, then wouldn't a low power fanless SOC (e.g. Cubox etc) be predictably better than a Mac Mini with its multiple interfaces and fan and power requirements?

 

What is the minimum "power" that is needed for NAA let's say using DSD512? Celeron? Atom? ARM v7? v8? Since we are running Linux would an Intel NUC be better (SQ) than an ARM platform?

[jabbr]

I have both, a CAPS v3 with a SOtM USB card and a SMS-100 as an NAA.

I just ordered the parts for the CAPS v3 Lagoon -- talk about low power! -- planning to power it with a Salas shunt regulator/Reflektor-D. A pair of Reflektor-D's would also make a nice supply for the Jussi DAC -- if that ever gets built.

[jabbr]

1. installed HQ Player in Ubuntu on Mac Mini
   
2. Switched sMS-100 to run NAA
   
3. Verified I could get it to play hooked up to my network that has DHCP and DNS
   
4. Pulled network cables from both Ubuntu box and sMS-100
   
5. Configured Ubuntu box to have fixed IP address with another address than it had with dhcp and shut it down
   
6. Connected both devices to a dedicated switch with no connection to any other network so no DHCP, DNS, etc.
   
7. Booted the Ubuntu box, logged in and
   
8. Started hqplayer
   
9. Opened preferences in hqplayer and set it to also and then to network, took a short while but the sMS-100 showed up.
   
10. Closed preferences and started playing, which worked again
    
11. Pulled ethernet cables from both devices
    
12. Hooked them up with a crossed cable.
    
13. 8-10, worked again
    
14. Re-booted ubuntu box
    
15. 8-10, worked again
    
16. Rebooted sMS-100
    
17. Opened preferences in hqplayer, could not find any NAA
    
18. Pulled cable from sMS-100
    
19. Connected it to network with dhcp
    
20. Booted it and verified i could connect to it
    
21. Pulled cable from sMS-100
    
22. Plugged in the crossed cable in sMS-100
    
23. Quit hqplayer in Ubuntu box
    
24. 8-10, worked again.
    
25. Repeat 18-24
    
26. Done
    

 

Hope that helps.

 

Wow ... that's complicated. It sounds like you want a point to point Ethernet connection i.e. don't want to be on a network.

 

Use static IP addresses.

 

(You could try ferrite cores on your Ethernet cables if you are concerned about Ethernet RF -- and remember that Ethernet connections are all transformer isolated)

[jabbr]

I just helped Victor who problems getting the combination of Ubuntu HQP and Auraliti PCto work using just a TP cable between. I don't know why he wants that off his normal network. He had been told he needed DNS for this, which was wrong. So to establish if it could work, I just did a staged approach to change one parameter per stage. So I got it to work without DNS, can't say I was surprised.

 

Today I used tcpdump and it verified my theory that the protocol was using multicast to have hqp query for naas.

 

 

 

Or static on one and have that provide DHCP service to the other one., That is, if you can live with certain boot sequence.

 

 

 

I'm fully aware of that and as I mentioned above it was not for me.

 

:-)

 

The network dump proves that it works as you would expect (multicast). I was responding to the thread. I mentioned ferrite cores because certain people seem too willing to give up the idea of an ethernet switch before trying the normal methods for reducing noise. Its fine for any individual to do as they please, or what sounds acceptable to them, its just that for 99.999% of people, Ethernet switches are rather useful.

[jabbr]

When the USB bitstream is just used for data bytes going into a FIFO buffer, why is the clock important ? That's what I can not get my head around. Irregular jittery bitstream going in to the FIFO buffer affects the regularity of Bytes coming out ? Async was supposed to take care of this, but I guess the devil is in the details

 

The idea of a buffer is that the irregularity of the data in doesn't affect the regularity of the data coming out. At least for a well implemented buffer which is why the devil tends to be in the details. If you have a large enough buffer you can entirely load it with data before clocking out thus eliminating the effect of input noise.

[jabbr]

Even with a reasonably large buffer, more messages must be sent by the USB receiver if the speed of the incoming bits is not well matched to the speed with which bits leave the buffer.

 

Interestingly, users of XXHE and PeterSt himself are tending to use quite low SFS settings (quite small memory buffers) these days for best sound.

 

With a sufficiently large buffer e.g. 16gb, you could put an entire and very large playlist in memory prior to any readout. No need to match input and output speeds.

 

I suspect PeterSt uses other methods to achieve SQ and/or reduce the effects of noise. I'm not suggesting a large buffer is the only method.

[jabbr]

True, I have read in several places, that a larger buffer is damaging to SQ, and one wants to select the smallest buffer possible that still results in no dropouts.

 

Larger buffer results in timing issues ? When the buffer is large, the last bit to come out has further to travel than the first bit ?

 

Umm... this could be true for certain specific applications but doesn't make this generally true. There are hardware buffers and software buffers. In terms of a buffer in a general purpose CPU with RAM, there is no such timing issue nor length of travel issue.

 

 

In Audio applications where timing is everything, software simplicity hits hardware reality. I have also read John Westlake saying that exactly the same code executed in different locations on the Sabre chip sound different

 

 

I can't say anything about the Sabre chip ... but if this is true it doesn't make this generally true for all sounds on all chips.

 

Did you see the Light Harmonic video which shows a printed circuit board trace which is a series of hairpin bends, and is done to equalize signal path length ?

 

There are reasons to do this that have nothing to do with the 'distance' the electrons travel i.e. equalization of capacitance and inductance are important. This has nothing to do with buffer sizes. Be careful about generalizations.

[jabbr]

I came across this post in the DDR3 thread

RE: Thanks for the response! - John Swenson - Computer Audio Asylum

 

The explanation sounds pretty plausible to me.

 

For non intrusive ground plane noise we want frequent small bursts rather than infrequent large bursts of activity.

 

Not necessarily. Imagine:

 

1) read entire playlist into memory.

2) Wait x seconds.

3) Play.

 

Where 'x' is of sufficient length to allow noise transients to decay.

[jabbr]

But it is the act of transferring the bits out of memory and to the DAC that causes the ground plane noise John was discussing. (See also Meitner and Gendron's 1991 paper on "logic induced modulation.")

 

This isn't to claim a particular significance for this sort of noise, but just to clarify the mechanism.

 

Ok, but this noise is inherent to the computer and not (necessarily) affected by any disc drive or ethernet packetization. In this case the RAM/buffer would seriously reduce to eliminate any downstream noise. You are down to RAM readout noise.

[jabbr]

No. No. No.

 

It's *the noise of the USB receiver in the DAC* when those bits are received.

 

Think about it: don't play music while the bits are being received over the network. Receive, wait, play.

[jabbr]

Since #2 is my goal, the logical choice is to have the desktop Mac (the one running HQP) act as a DHCP server for the NAA. But while I CAN do that (the NAA gets an IP from the desktop Mac), HQP still does not "see" the NAA. And the Linux/NAA boot images I use are those provided to me preconfigured by Miska (for ARM and Intel). They just boot minimally to a prompt.

 

Alex C.

 

You do realize that you are doing very unusual things with your network and asking Miska to read your mind

 

Multi-homed is tricky and you may need to set up routing tables.

You are also asking your ADSL modem to be your DHCP server!

 

What I do at home is have a separate firewall/router device which acts as a DHCP server and ties together my distinct networks, including wireless.

[jabbr]

You do realize that you are doing very unusual things with your network and asking Miska to read your mind

 

Multi-homed is tricky and you may need to set up routing tables.

You are also asking your ADSL modem to be your DHCP server!

 

What I do at home is have a separate firewall/router device which acts as a DHCP server and ties together my distinct networks, including wireless.

 

How about trying something very simple like this: WRT54GL which could be run off a 12v/0.5A linear power supply. Uses Broadcom SOC and runs Linux. It will give you 4 Ethernet ports for your home router.

[jabbr]

At some point when I have time... It requires update to the kernel and libasound2 to have advantages over previous version (IOW, to support non-DoP DSD) and doing all that for the image takes some time.

 

Where can NAA 3.x be found -- the netaudiod is version 2.05?

[jabbr]

I think I do have a Linksys WRT54GL in a drawer somewhere, but I don't see why I would want to add that to my network--especially since I prefer not to have wi-fi in my studio. And its 4 ports would not be nearly enough for my LAN--that's what my 10-port Cisco Gigabit managed with is for. Besides, as I have said, I can get HQP to find NAA devices (both ARM and Intel) as long as they are plugged directly into my DSL modem/router. I don't think there is anything non-standard or unreasonable about expecting to be able to plug them into my Ethernet switch and have them be seen by my desktop Mac (also plugged into EN switch).

 

I admit that my other desire--to be able to have HQP find NAA device that is directly attached via EN cable--is not typical and Miska has already explained what it is hard for him to accommodate that easily. But based on prior comparisons (with direct connection versus through switch; with HQP running on optimized headless i7 mini--getting its music files from shared drive at desktop machine over that EN), there is a distinct sonic advantage to the direct connection.

 

I understand that you hear a better sound when you direct connect your NAA vs through your switch. I am suggesting that you might instead try a low-power router which you could easily power via a LPS, one that is actually a low powered 'cpu' running Linux rather than an actual switch -- might make a difference for you with the added benefit of doing a better job at DHCP/NAT/UPNP and other functions that your ADSL modem may not be the best for (but who knows

 

Gee, if that works you could actually attach two different NAA on your network

[jabbr]

Groan ... after seeing that NAA 3.0 runs on OS X, I rushed to my office ready to pry apart my old Mac Mini (the one with the dead hard drive), ready to upgrade its memory and install an SSD. Unfortunately its circa 2007 ... a core 2 duo which uses DDR2 ... great now I can entirely eliminate the 'row hammer effect' :) ... and then I see that it won't install 10.8 as its really limited to 32 bits... time to really retire my third mac device, the first being a 2002 g5 whose motherboard has too many glitches and the second an old white MacBook that my son killed by dropping (not worth replacing the screen). Oh well.

[jabbr]

Right, which is why I said earlier I wasn't aware of a DAC with, e.g., 16GB of memory into which to pre-load music files.

 

Different issue. Communication of computer and DAC is not necessarily packetized which is the theory that is being invoked to shift noise into the audible spectrum (and does seem plausible given certain conditions).

 

Assuming in memory: DSD512 (for example) -> DAC ... I'd expect a much different power plane noise pattern than the same file read from a hard drive, or sent via Ethernet (each different).

 

Think about a 1ghz square wave -- not much audible frequency harmonics if it is continuous. Now modulate the same 1Ghz square wave with a 1khz square wave -- now you've got lots of audible harmonics. So if your disc or network system does 1000 IOPS its much more like that and you expect audible harmonics.

 

My impression is that I2S isn't packetized so less of an issue, and that with USB Audio you'd want IOPS > 20,000 to minimize/eliminate this as a potential issue.

 

I found this: SSD Throughput, Latency and IOPS Explained - Learning To Run With Flash | The SSD Review to illustrate -- you'll see that for both HD and SSD, IOPS can easily be in the audible range (but RAM is way up there).

[jabbr]

Thank you for the kind and reasonable suggestion jabbr. I may in fact give it a try .

 

--Alex C.

 

You are welcome ... I'm still working on converting a mac mini into a NAA vs player ... you have me very curious about why this would have better SQ than the cubox ... would be interesting in comparing mini vs. atom (12v 3 amp draw) vs. ARM (2 amp draw).

[jabbr]

That's the case because there are no Amanero specific Linux drivers yet, so Linux support relies on the UAC2 standard which means max DSD128 through DoP.

 

Non-DoP support on Linux is currently limited to:

Playback Designs

iFi

Marantz

DIYINHK

Matrix

 

I have just configured my linux NAA 3.0 on an intel DN2800MT board. I have an iFi iDSD micro so I'm trying to get to DSD512.

 

I've installed Ubuntu Server 14.04.1. Also libasound2. When I configure HQPlayer 3.6.0 (running on OS X 10.9) into non-DoP mode, it doesn't allow DSD. When I configure the NAA with DoP it allows DSD.

 

Is this a USB driver issue?

[jabbr]

Thanks ... when I follow the directions correctly it works much better Looks like networkaudiod and ehci_hcd each use a whopping 10% of the cpu when playing DSD512! I'm sending about 2.4 - 3.1 MB/sec over the network.

 

FWIW When I first connected the NAA to the DAC I got a clear background hum regardless of whether the Aqvox was powering the DAC or not. Went away when I plugged the NAA into the same outlet used to power the Aqvox->DAC as well as my Bottlehead Crack. SQ got alot better also. Sounds great. Next steps will be to LPS power the NAA and install a better USB card ... probably Paul Pang but also considering SOtM.

[jabbr]

Note: I did:

 

apt-get install linux-image-lowlatency

 

but that didn't work until I installed Miska's particular linux-image-lowlatency (via dpkg -i)

[jabbr]

When I output at DSD512/22579200 (HQPlayer 3.6.0 OS X/NAA 3.0.0 ubuntu/atom->iFi iDSD micro) the output stutters. Plays fine at DSD256/11289600. Regardless of buffer settings. Uses 33% CPU with DSF64 sources an 50% CPU with PCM 24/192 sources.

[jabbr]

What kind of CPU do you have on the Mac?

 

I7-4930x (IVB-E) on gigabyte GA-x79-up4

 

 

Sent from my iPhone using Tapatalk

[jabbr]

Just turn on the Pipeline SDM setting and you should be fine...

 

On, tried various buffer times, different modulators. Using poly-sinc-mp tried poly-sinc-mp-2s.

 

The stuttering isn't just once in a while, its continuous.