HQPlayer's Network Audio Adapter

[jabbr]

 

Here are the settings (buffer time is set to "Default", this pre-release build has a bug on that part of the dialog):

[ATTACH=CONFIG]16526[/ATTACH]

 

Using your settings. Same problem. The stuttering happens multiple times/sec and seems to slow the tempo of the song down. There also seems to be some ringing. I've tried a few songs of different tempo to see if the tempo of the song interacts with the tempo of the stuttering. The stuttering mostly consists of gaps in playback (multiple x/sec) but the entire song seems to be played.

[jabbr]

My CPU utilization is 193% but only 20% of my system (more cores than you). Network IOPS 3400-7000 out and 1700 in. data sent: 3-6 MB/sec, received 112 KB/sec.

[jabbr]

my NAA reports (via top):

[jabbr]

Now the only possibility I can think of is at the source side. Are you playing from a local HDD or from a NAS?

 

I have just released HQPlayer 3.6.1, so you could try with the updated version to see if it makes any difference. I've made some fixes and improvements here and there. First try setting buffer time to "Default" and then you can try different values starting from 100 ms if the default one doesn't behave.

 

What was the type of network interface at both sides? Some switch between? Ports are running at 1 Gbps at both ends?

 

Updating to 3.6.1 did the trick! I'm now converting PCM 24/192 -> DSD512 without a hitch. Uses CPU 265%. NAS or RAM Disk: no difference. Yes 1GBE switch connections.

 

Slightly more NAA utilization:

[jabbr]

Updating to 3.6.1 did the trick! I'm now converting PCM 24/192 -> DSD512 without a hitch. Uses CPU 265%. NAS or RAM Disk: no difference. Yes 1GBE switch connections.

 

Spoke too soon DSD512 works when source is PCM, but when source is DSD/DSF then the max I can get before stuttering is DSD256 ... well actually bitrate 1228000 works... but 22579200 causes stuttering.

[jabbr]

Spoke too soon DSD512 works when source is PCM, but when source is DSD/DSF then the max I can get before stuttering is DSD256 ... well actually bitrate 1228000 works... but 22579200 causes stuttering.

 

I've created a 4 core 4gb RAM VMWare VM where I've installed Ubuntu Studio 14.04.1 and HQPlayer 3.6.1. Host is my OS X machine. This successfully outputs DSD512 -> NAA

[jabbr]

So with the Linux under VM things work while the native OS X version doesn't? This is interesting... OS X has certain performance limitations, but it is interesting that the virtual machine would perform better than native. I'll have to look for approaches how to get around the certain OS X limitations with the native version.

 

It is interesting that when converting from PCM (under OS X) it does DSD512 successfully but stutters with DSD sources. I don't know the code paths but should narrow the issue down. I'll also try from my MBP which is running 10.10.1 -- are other folks trying to do this with OS X?

 

I have to say its sounding fantastic ... I also just installed the speedball/C4S into my Crack headphone amp so the sound is good from all angles

[jabbr]

Performing DSP on DSD content is very resource intensive process. Is there notable CPU load increase in your machine with the DSD source case? If you enable the "DirectSDM" setting (default) then DSD sources go through unprocessed and there's only very minimal CPU load. "IIR" set as "Integrator" is usually also lighter on the CPU, but you can compare load and sound difference between IIR and FIR integrators.

 

DirectSDM did the trick.

 

BTW my MBP (i7 2.5 Ghz x 4/16 Gb RAM) when accessing the source DSF over 802.11ac and outputing to NAA also over 802.11ac is able to do DSD512.

 

Its hardly using any CPU at all -- is this oversampling to DSD512?

[jabbr]

Sigh ... it looks like all the times my system has "worked" with with DSD/DSF sources and DSD512 i.e. bitrate 22579200 that in fact "DirectSDM" has been checked and so the output has been ?DSD64. DSD512 does work with PCM sources. It doesn't appear that my CPU usage is higher with DSF sources (without DirectSDM). When source 24/192 and output 22579200, CPU% = 300% When source DSF(64) and output 22579200 (stutters) CPU = 220% :{

[jabbr]

OK, so PCM sources work although total load is higher? I assume you have Pipeline SDM enabled?

 

Reason for this is that Pipeline SDM processing is not yet supported for DSD sources, it is only used for PCM sources. I believe it is time to add Pipeline SDM support also for DSD sources. I'll look into adding it to the next release (that would be probably 3.6.2).

 

Yes pipeline SDM enabled. Interesting.

[jabbr]

That seems to work. Sending out about 7 MB/s

[jabbr]

ETA for DSC2? Its either build this or I will start spending far too much money on overpriced output caps for my amp...

[jabbr]

First listen to new version suggests better source file access using NAS.

 

Previously I was seeing bursts in file access which corresponded to dropouts in output. Not so apparent for RBCD PCM or DSD64 but frequent dropouts with DSD128 -> DSD512 source files made it hard to do a comparison -- I was playing around with upsampling in Audinventory with the idea that it would allow less CPU cycles on playback. In any case I'm now seeing a smooth IOPS for file input and output which I hope will correspond with less frequent dropouts.

[jabbr]

I have not heard of anybody building Windows ASIO drivers for ARM architecture...

 

 

 

RasPi is also ARM...

 

I would say major drawback being poor support for ARM-based platforms. Practically the only ARM-based Windows installs are mobile phones running on a Qualcomm SoC.

 

Where we seem to be stuck at the moment for people using Amanero based USB inputs e.g. DSC1 but presumably Lampizator as well, and who desire DSD512, is that the only NAA platform which supports at the moment is Windows ASIO. What would be needed to get native DSD with Amanero on Linux?

[jabbr]

Goal number two is to listen to sound quality, then, if needed, swap out the SSD and go with a minimal Windows 10 install.

 

Question: is goal number two realistic, or is moving to an NAA with some small amount of meat on its bone a lateral move at best? Will my only real step up in sq to get Win 10 and then gut it (via lmitche's guide, etc)? Or is the truly real NAA benefit a tiny bootable Linux box (which is a no-go for me due to my DAC reviewing job...not enough DAC compatibility)?

 

These are all great questions I've got a few ARM boxen sitting on my desk awaiting evaluation. I'm currently leaning toward your approach.

[jabbr]

I don't think there is any need to remove extraneous software from the hard drive.

 

I just installed PPA V2 USB on my NAA -- using a gen 1 anker to supply FMC & PPA USB -- without enough listening time for a critical judgement: I'd say there is an incremental improvement -- not as much as the fiber/FMC and much less than the Corning optical/Regen USB combo.

 

In process of building a second NAA which will have a PPA USB and fiber optic NIC so need 2 PCI-e slots -- probably going with an Intel J1900 board and picoATX supply fed off LPS -- anyone have an idea for a small case that allows 2 PCI-e cards?

[jabbr]

Out, out, ye vile running daemons!

 

For kernel daemons you need a much stronger incantation!

[jabbr]

If you are not familiar with Audiophile Optimizer (aka AO) that is precisely what it does (disables unnecessary services and registry items, among other things). I run the latest 1.31b beta. Thanks.

 

If I am trying to make this more bare bones and simpler then Linux is not a choice for my NAA. I have way too many DACs that have no good Linux driver solutions currently.

 

I'm thinking Windows 10 may be a home run in this space.

[jabbr]

Hey everyone

What's the status on NAA running on BBB now?

I'm having problems install jessie dist NAA due to architecture and dependency problems.

I'm in progress of making my renderrer with NAA+BBB+sokris r2r.

I'm running r2r in NOS mode, and using hqplayer to do all filtering works.

Thanks

 

I was going to suggest Windows NAA because of the native DSD driver situation ... but wait! you aren't using DSD at all ... native real deal PCM

 

I'd love to hear that.

[jabbr]

I find 4GB is more than enough for NAA

 

 

 

SQ of powering SSD from smartphone battery is way, way better than powering from HDPlex on my PC in Sig

 

Ever tried using the mini-box UPS2 with Li batteries to supply the picoPSU?

[jabbr]

Could you not use a mini pcie to pcie flexible adapter to create a second pcie for the fibre card?

 

I've been using a Q1900DC-ITX for a while and it works well as an audio pc in a dual set up with JPLAY/ AO. There's a PPA card in the pcie slot and an Anker powers the SSD. The Q1900 draws very little power.

 

Question is how much noise the flexible PCI-e adapter cable causes vs direct PCI-e motherboard connection. I don't know but its something to consider. The advantage of using a fiberoptic NIC is that the copper Ethernet interface can be shut down.

[jabbr]

Yes, the NAA issue is really a purist's conundrum right now. On one hand it should be lightweight and isolated, on the other hand to truly isolate and make the best connection to the DAC it potentially benefits from a fiber card and a good USB card...which means two PCIe slots, which means "lightweight" (in the case of mobos) is not really a solution (i.e a small prebuilt NUC or something doesn't have this expandability). In the meantime I am foregoing a fiber card on my NAA, using a JCAT USB card and an FMC into my mobo RJ45, and my noise floor is wonderfully quiet. So..as I said, this is more a theoretical conundrum, not necessarily a practical one.

 

And the other option is using a USB regen with the motherboard USB rather than another USB PCI-e card. Have you tried the USB Regen, and do you find also using JCAT to improve upon that? People talk about using 2 regens... still an improvement with JCAT?

[jabbr]

Jabbr, geniuses think alike! I sent Alex an email about that exact issue last week. What if a $175 Regen could provide enough isolation and reduce enough noise to make a simply mobo USB connection shine as if it were a 3rd party USB card (which start quite a bit above $175 and require a slot, etc). He said that John (Swenson) postutates that the Regen will benefit from anything in front of it, so the theory is that 3rd party cards make the Regen even more effective...however, that is simply postulation. No one has reported these a/b comparisons. I have asked Alex for a review sample but he's backlogged extensively; good news is I have a local buddy who is on the order list. I will most definitely do the a/b/c (JCAT alone, mobo with Regen, JCAT with Regen).

 

Great. I was thinking about using my Regen Green board as the output from my NAA. Then USB cable. Then Amber (when I get my upgrade) right before the DAC. Frankly I've been testing so many different combinations out my brain is fried regarding subtle differences -- I don't trust myself as a great reviewer. That said I heard a tremendous improvement using the combination of Corning fiberoptic USB + Regen. Another substantial difference with FMCs isolating the NAA, fiber on my HQPlayer machine (but that could also be the NIC!).

 

Anker battery vs. iPower for the FMC ... I can't be sure of a difference.

 

If you could compare the Regen +/- JCAT that would be really really helpful.

[jabbr]

Reports are starting to come out that multiple Regens are an improvement over a single unit. So I would expect an improvement using one of the usb cards in conjunction with the Regen as well. It will be interesting to see what Colin says tonight.

 

Yes but if 2 regens are as good as SOtM or PPA + Regen, then we can use the PCI-e slot for an optical NIC.

[jabbr]

Now we will have to test two Regens with MoBo USB v/s JCAT USB, ....good grief! I think Ted has mentioned that he might be able to get his hands on one soon, and my order is 1406 or something, so I should be getting mine early July as well. I can send my Regen to Ted as well, so that we can put this to rest. You ok with this Ted? I think we can all trust your judgement. Thanks in advance.

 

To my ear, the combo of Regen and Corning Optical is a far more significant improvement than PPA USB alone. If Regen alone is equal to Regen + JCAT, for example, there may not be a big need to test Regen x 2.