HQPlayer's Network Audio Adapter

[Jud]

YashNo Clue, eat this!

 

What do you have to say for your sorry self?

 

That trying to outdo each other with regard to discourtesy does neither of you any credit, I would sincerely hope.

[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.

[Jud]

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.

 

No. No. No.

 

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

[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.

[Superdad]

 

Originally Posted by Miska

Hi,

 

HQPlayer makes some reverse-DNS requests for example for the NAA's IP. This is not necessary for the functionality and I have removed it from the upcoming HQPlayer version. At least it caused unnecessary delays on the discovery.

 

So while DNS is not by itself necessary for the functionality, it is used by versions prior to HQPlayer 3.6.0 (to make log output look more tidy on networks where reverse DNS works).

 

Another important detail is to make sure multicast goes out from all interfaces when there's more than one.

 

 

Johann:

 

The above is NEW information--since it is the first I have seen of an announcement of HQP 3.6.0 (unreleased as of today). I have done multiple searches here and elsewhere to find the original post and context for the post from Miska that you quoted. But I can not find it. Can you please point us to the source?

 

Indeed this is something have been asking him for for a while. My ADSL router is slow at handing DHCP lease addresses to my Cisco switch, so I have to connect any NAA computer to the ADSL modem/router in order for my desktop player (OS X version) to find/recognize it. I tried a bunch of things to make my desktop Mac into a DHCP/DNS router (am able to do so), but the OS X version never finds my NAA connected either to Cisco switch or direct to Mac EN port (the latter being my greatest desire since I already find better SQ with my Mac-to-Mac setup (with shared network drive on desktop Mac). That is partially why I have not been using HQP with NAA (just as player on modded, headless mini).

 

So if Miska's comment means that HQP 3.6.x is going to allow direct input of IP address (easy to see at boot time of NAA--even the text-only optimized Linux/NAA images for ARM and Intel from Miska--the lease IP shows in the last lines of the boot before the prompt), then that would be VERY good news for me and others who have been frustrated to date with NAA discovery.

 

Thanks,

--Alex C.

 

P.S. I wish both you and YashN would knock off the petty stuff. Really.

[johann]

Alex,

 

That was the reply to a PM asking about the DNS. It does not mean you can enter IP addresses in the tool.

It just verifies that DNS is not needed nor is DCHP since you can use fixed IP addresses in all nodes.

By using multicast, the NAA(s) will respond to the multicast and announce themselves to the HQPlayer.

 

This is exactly what I said much earlier and I also described a dump from tcpdump proving I as right.

But you guys were giving me the "We know better attitude", really annoying and ungrateful I must say.

So is it that surprising I overreact?

[Miska]

After doing some NAA update work on both HQPlayer and NAA side; to be precise, one possible problem I found was getnameinfo() returning an error and thus terminating the NAA discovery phase in HQPlayer. Functionally this is not necessary, result was only used for possible log output.

 

When name of the peer cannot be resolved, it should return just plain IP without error... (but documentation is ambiguous about when EAI_AGAIN can happen)

[victor]

Could be issues with multicast.

 

Try tcpdump, using the port as I did, will just give you communication that is relevant so not that noisy

 

I finally tried tcpdump , not specifying the port because I forgot but I think that it is not important in my case as there are almost no messages displayed. What I did:

 

0: Stop networkaudiod

1: Execute tcpdump in the NAA PC

2: Execute tcpdump in the HQP PC

3: Start networkaudiod manually as root in the NAA PC to see log (no log appears apart from initial message saying that it started )

4: Start HQP in the HQP PC (ALSA mode by default)

5: Select NAA in HQP

6: Wait and wait and wait and nothing happens

7: Ctrl+C in both tcpdumps

 

Both PCs have static IPs and the gateway set to the other PC's IP address.

HQP IP: 192.168.1.11

NAA IP: 192.168.1.8

Both PCs are interconnected using an ethernet cable and ping and ssh work from both sides.

 

tcpdump output in the NAA PC:

 

root@voyage:~# tcpdump -i eth0 not host 192.168.1.8

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

0 packets received by filter

0 packets dropped by kernel

 

tcpdump output in the HQP PC:

 

victor@hqplayer:~$ sudo tcpdump -i eth0 not host 192.168.1.11

[sudo] password for victor:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:07:31.732271 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:07:38.107551 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:09:12.482126 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:09:15.823232 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

^C

4 packets captured

4 packets received by filter

0 packets dropped by kernel

 

FULL VERBOSE:

 

tcpdump output in the NAA PC:

 

root@voyage:~# tcpdump -i eth0 not host 192.168.1.8 -v

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

18:46:50.191355 IP (tos 0x0, ttl 255, id 56166, offset 0, flags [DF], proto UDP (17), length 73)

^C^C^C^C^C 192.168.1.11.mdns > 224.0.0.251.mdns: 0 [2q] PTR (QM)? _ipps._tcp.local. PTR (QM)? _ipp._tcp.local. (45)

 

1 packet captured

2 packets received by filter

0 packets dropped by kernel

 

tcpdump output in the HQP PC:

 

victor@hqplayer:~$ sudo tcpdump -i eth0 not host 192.168.1.11 -v

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:10:28.493053 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))

192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.199 to_ex, 0 source(s)]

11:10:34.146278 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))

192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.199 to_ex, 0 source(s)]

^C

2 packets captured

2 packets received by filter

0 packets dropped by kernel

 

Are you able to see what is happening?

 

 

Cheers,

 

Victor.

[johann]

Hi Viktor,

 

I'm afraid we need to use port to see all multicast and traffic in both directions.

But her it looks like the naa don't receive the multicast request.

 

Cheers

Johan

 

I finally tried tcpdump , not specifying the port because I forgot but I think that it is not important in my case as there are almost no messages displayed. What I did:

 

0: Stop networkaudiod

1: Execute tcpdump in the NAA PC

2: Execute tcpdump in the HQP PC

3: Start networkaudiod manually as root in the NAA PC to see log (no log appears apart from initial message saying that it started )

4: Start HQP in the HQP PC (ALSA mode by default)

5: Select NAA in HQP

6: Wait and wait and wait and nothing happens

7: Ctrl+C in both tcpdumps

 

Both PCs have static IPs and the gateway set to the other PC's IP address.

HQP IP: 192.168.1.11

NAA IP: 192.168.1.8

Both PCs are interconnected using an ethernet cable and ping and ssh work from both sides.

 

tcpdump output in the NAA PC:

 

root@voyage:~# tcpdump -i eth0 not host 192.168.1.8

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

0 packets received by filter

0 packets dropped by kernel

 

tcpdump output in the HQP PC:

 

victor@hqplayer:~$ sudo tcpdump -i eth0 not host 192.168.1.11

[sudo] password for victor:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:07:31.732271 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:07:38.107551 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:09:12.482126 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:09:15.823232 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

^C

4 packets captured

4 packets received by filter

0 packets dropped by kernel

 

FULL VERBOSE:

 

tcpdump output in the NAA PC:

 

root@voyage:~# tcpdump -i eth0 not host 192.168.1.8 -v

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

18:46:50.191355 IP (tos 0x0, ttl 255, id 56166, offset 0, flags [DF], proto UDP (17), length 73)

^C^C^C^C^C 192.168.1.11.mdns > 224.0.0.251.mdns: 0 [2q] PTR (QM)? _ipps._tcp.local. PTR (QM)? _ipp._tcp.local. (45)

 

1 packet captured

2 packets received by filter

0 packets dropped by kernel

 

tcpdump output in the HQP PC:

 

victor@hqplayer:~$ sudo tcpdump -i eth0 not host 192.168.1.11 -v

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:10:28.493053 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))

192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.199 to_ex, 0 source(s)]

11:10:34.146278 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))

192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.199 to_ex, 0 source(s)]

^C

2 packets captured

2 packets received by filter

0 packets dropped by kernel

 

Are you able to see what is happening?

 

 

Cheers,

 

Victor.

[Jud]

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

 

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.

[shadowlight]

tcpdump output in the NAA PC:

 

root@voyage:~# tcpdump -i eth0 not host 192.168.1.8

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C

0 packets captured

0 packets received by filter

0 packets dropped by kernel

 

tcpdump output in the HQP PC:

 

victor@hqplayer:~$ sudo tcpdump -i eth0 not host 192.168.1.11

[sudo] password for victor:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:07:31.732271 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:07:38.107551 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:09:12.482126 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

11:09:15.823232 IP 192.168.1.8 > 224.0.0.22: igmp v3 report, 1 group record(s)

^C

4 packets captured

4 packets received by filter

0 packets dropped by kernel

 

 

Victor,

 

Try changing the tcpdump command and remove the "not" before the host. It's been awhile with using tcpdump but if you use "not" option you are basically saying give me all information other than what is after the "not". So your command

 

tcpdump -i eth0 not host 192.168.1.11 is basically giving you all traffic generated and any traffic from 192.168.1.11 is not being displayed.

 

Personally, I prefer to run the tcpdump command with out any option and then review the result.

 

tcpdump -i eth0

 

Can you confirm that you have ip connectivity between the two system. Are you able to ping NAA from HQP and HQP from NAA.

[YashN]

It would also be a total waste of my time...

 

Much rather listen to native Quad-rate DSD instead :P

 

That trying to outdo each other with regard to discourtesy does neither of you any credit, I would sincerely hope.

[YashN]

P.S. I wish both you and YashN would knock off the petty stuff. Really.

 

I have him on my ignore list like prot and a couple of others on the same level (ignorant and vulgar), but on the other hand, if you keep feeding them, I can see your replies because of course, I'd never put you on ignore (or John or Miska, or other good and knowledgeable folks).

 

So don't feed the trolls...

[YashN]

Not sure if these have been covered completely elsewhere on the forum but here are a few of my questions for the NAA setup:

 

1. Can I use Mac OS X as NAA? I saw Geoff mention easy switching of HQPlayer from Desktop to NAA mode just today or yesterday.

 

2. There are updated Linux images and other files for native DSD streaming support with XMOS. Can I use these on a Lubuntu 32-bit install? Can't find the install instructions again, a centralised FAQ on the Signalyst website would be helpful.

 

3. Should the idea of using a RaspberryPi as NAA with support for native DSD streaming be abandoned?

 

4. Is using an NAA through Wi-Fi possible? Not recommended? Is wired Ethernet the only way or the best way?

 

Thanks.

[YashN]

That is not a very nice comment. Johan has been trying a lot to help me with my hqp-naa issues and I believe that he is right:

 

I guess you haven't seen his comments and replies when I provided him the way to find more information about what Superdad and John Swenson are currently building as one of their next product?

 

Suit yourself.

[EuroDriver]

Not sure if these have been covered completely elsewhere on the forum but here are a few of my questions for the NAA setup:

 

1. Can I use Mac OS X as NAA? I saw Geoff mention easy switching of HQPlayer from Desktop to NAA mode just today or yesterday

 

the various versions of NAA only run in various Linux versions. No Mac OSX or Win :-(

 

 

4. Is using an NAA through Wi-Fi possible? Not recommended? Is wired Ethernet the only way or the best way?

 

Had surprisingly very good results with a Surface Pro 3 connected over WiFi to LAN where a SOTM SMS 100 was hooked up to with CAT5. Sounded better than a CAT5 wired Mac Pro Yosemite HQP playing to the same SOTM SMS-100

[shadowlight]

Not sure if these have been covered completely elsewhere on the forum but here are a few of my questions for the NAA setup:

 

1. Can I use Mac OS X as NAA? I saw Geoff mention easy switching of HQPlayer from Desktop to NAA mode just today or yesterday.

 

2. There are updated Linux images and other files for native DSD streaming support with XMOS. Can I use these on a Lubuntu 32-bit install? Can't find the install instructions again, a centralised FAQ on the Signalyst website would be helpful.

 

3. Should the idea of using a RaspberryPi as NAA with support for native DSD streaming be abandoned?

 

4. Is using an NAA through Wi-Fi possible? Not recommended? Is wired Ethernet the only way or the best way?

 

Thanks.

 

Hopefully Miska would not mind my sharing bit of information from email thread that I had going with him related to updated Linux packages. I had asked him if I needed to install updated Kernel or libasound2 packages to support DSD on Linux for HQPlayer and below is his response. My DAC only does 128bit DSD so it did not apply to me.

 

"Unless you have iFi or Marantz DAC, or DIYINHK interface, you don't need to install those packages. Both iFi and Marantz also work without those, but it open up support for DSD256 on iDSD Nano and DSD512 on iDSD Micro."

 

 

As for your question related to NAA through Wi-Fi I am running that setup but my wi-fi setup is around 802.11ac and I no issues so far. Installing xubuntu and NAA on the Lenovo i3 was quick and easy. Not sure about how easy it is to install it on RaspberryPi. I rather be listening to music instead of mucking around with installation :-)

[YashN]

I had similar issues to yours that you mentioned in another thread, Superdad, namely not finding the NAA with Core 2 Duo Mac OS X. Currently, I have no way of trying with updated hardware unless I confiscate the gf's shiny MacBook Air to tinker with, so for now I'll leave it at using my oldish Macs.

 

Another layer (ah ah ah) of complexity for me is that I actually hacked my router: last summer I hacked it with an open-source firmware so that I could use it as a Wi-Fi-to-Wi-Fi extender bridge, allowing the Wi-Fi from my iMac to be extend into the garden so that I can use my laptop there (fun).

 

This works well, but.... there are a few caveats:

 

Since the Linksys is now doing Wi-Fi-to-Wi-Fi, one antenna gets part of the full bandwidth, and the other, the other part of the bandwidth. In other words, although my music is on a smb share from my iMac, any computer accessing it through my hacked router now only has half bandwidth to play with.

 

Results: I can still stream through this router anything up to DSD128 and play it natively on a lowly P4 PC with Win and Foobar2000. DSD256 stutters, drops out (possibly only bandwidth related, possibly a combination of CPU + bandwidth).

 

Additionally, some features have had to be disabled in the router as bridge to enable the new setup, so I may need to go back and check that regarding multi-cast and so on...

 

Now, probably NAA is wired Ethernet only, so this is bound to fail with Wi-Fi anyhow if it's the case.

 

But the reality is: if I now want to get the router connected for NAA, I'll have to re-configure the router, and thereby lose the Wi-Fi bridge for now.

 

I might do this as for now I won't be using the Wi-Fi extender functionality much until spring is back and it's fun to be in the garden (totally white currently).

 

There seems to be some fishy things with Mac OS X Mavericks regarding network location configurations: in case of duplicating a location, if a bridge within it is removed or disabled for some reason, then the other location suffers.

 

Technically, since the iMac + Mac OS X Mavericks has bootpd/DHCP/DNS and so on, shouldn't a direct Ethernet connection between the iMac and an NAA work?

 

My ADSL router is slow at handing DHCP lease addresses to my Cisco switch, so I have to connect any NAA computer to the ADSL modem/router in order for my desktop player (OS X version) to find/recognize it. I tried a bunch of things to make my desktop Mac into a DHCP/DNS router (am able to do so), but the OS X version never finds my NAA connected either to Cisco switch or direct to Mac EN port (the latter being my greatest desire since I already find better SQ with my Mac-to-Mac setup (with shared network drive on desktop Mac). That is partially why I have not been using HQP with NAA (just as player on modded, headless mini).

 

So if Miska's comment means that HQP 3.6.x is going to allow direct input of IP address (easy to see at boot time of NAA--even the text-only optimized Linux/NAA images for ARM and Intel from Miska--the lease IP shows in the last lines of the boot before the prompt), then that would be VERY good news for me and others who have been frustrated to date with NAA discovery

[YashN]

I had asked him if I needed to install updated Kernel or libasound2 packages to support DSD on Linux for HQPlayer and below is his response. My DAC only does 128bit DSD so it did not apply to me.

 

"Unless you have iFi or Marantz DAC, or DIYINHK interface, you don't need to install those packages. Both iFi and Marantz also work without those, but it open up support for DSD256 on iDSD Nano and DSD512 on iDSD Micro."

 

Hey shadowlight, thanks. This I know, and if you've seen my sig and posts, I have an iFi iDSD Nano which has the XMOS interface/uC as well as the upgraded firmware from iFi, so it can do native streaming of DSD256.

 

Already tried that with an old PC / WIN 32 with Foobar2000 and Yarlung Records' tracks. Absolutely amazing!

 

So now, what's left is testing HQ Player + NAA + native streaming DSD256.

 

As for your question related to NAA through Wi-Fi I am running that setup but my wi-fi setup is around 802.11ac and I no issues so far. Installing xubuntu and NAA on the Lenovo i3 was quick and easy. Not sure about how easy it is to install it on RaspberryPi. I rather be listening to music instead of mucking around with installation :-)

 

Good to know. I may need to do something here with the router for bandwidth as well.

 

But the question remains: I have an old PC with 32-bits only. Managed to install Ubuntu 14, then the Lubuntu distro and desktop (otherwise it's too slow it's unusable...). Now, the requisite realtime kernel patches as well as libasound2 (any other thing, I can't remember and actually can't find the instructions again), can they be installed on this 32-bit setup or not?

 

If they can, I will then be able to do one or two things, like using a special mpd to play native streaming DSD256, and test HQ Player from Mac OS X to this Linux PC as NAA. Far from ideal, but at least we get some isolation from the server computer and its disk drive and electrical activity.

[YashN]

the various versions of NAA only run in various Linux versions. No Mac OSX or Win :-(

 

Tried setting up the MBP with the latest Ubuntu and had a lot of issues doing it, like the MBP overheating and even shutting down with LiveCDs and USB key. My MBP already overheats sometimes so could be part of the issue.

 

Also say that a lot of older MBPs are only known to be working with older distributions, like Precise Pangolin (~ v12)...

 

So I've pretty much abandoned that hope for now.

 

Installation on a old DELL PC that my gf had went without issues, except for the fact that Unity drags it down greatly! Lubuntu is fine though.

[YashN]

Had surprisingly very good results with a Surface Pro 3 connected over WiFi to LAN where a SOTM SMS 100 was hooked up to with CAT5. Sounded better than a CAT5 wired Mac Pro Yosemite HQP playing to the same SOTM SMS-100

 

Interesting results, EuroDriver, and that's also why I would like to try with Wi-Fi if I can.

 

Once I get the HQP + NAA thing going, I can then compare a few different setups to my the sweet spot in my rig and share the findings with others.

[Jud]

It would also be a total waste of my time...

 

Much rather listen to native Quad-rate DSD instead :P

 

Can't blame you for wanting to listen to music.

 

What I will say (then I'll shut up about this), and take it for whatever it's worth, is that (1) as Superdad hinted, the back-and-forth wastes *our* time; (2) as victor said, Johann and you are both knowledgeable and helpful forum members, and we would all be delighted to see more of that knowledgeable and helpful stuff from both of you.

[shadowlight]

 

But the question remains: I have an old PC with 32-bits only. Managed to install Ubuntu 14, then the Lubuntu distro and desktop (otherwise it's too slow it's unusable...). Now, the requisite realtime kernel patches as well as libasound2 (any other thing, I can't remember and actually can't find the instructions again), can they be installed on this 32-bit setup or not?

 

If they can, I will then be able to do one or two things, like using a special mpd to play native streaming DSD256, and test HQ Player from Mac OS X to this Linux PC as NAA. Far from ideal, but at least we get some isolation from the server computer and its disk drive and electrical activity.

 

I will have to let Miska answer your question about if NAA needs the kernel and libasound2 drivers.

 

Just looked at both NAA packages on the website and kernel/libasound2 directory. Looking at the directory listing and package naming convention the NAA package is 32bit while the kernel/libasound2 packages you have the option of installing either x64 or 32bit packages. So you should be able to install both just not 100% sure on all the dependencies for the packages.

 

Are you planning to use the 32-bit system strictly as a NAA/MPD. For NAA you do not need any of the desktop management options so you could potentially strip it down even further but uninstalling unnecessary packages/services which will free up some additional resources.

 

Once I have all the configuration working I plan to rebuild the NAA starting with network install of ubuntu server 14.04, which will have bare bone setup just for NAA

[YashN]

Yes, and if you reply to the trolls, they reply back, and hence waste all of our time including yours. What I am telling you (until you realise how they are): is to avoid them like the plague, then maybe we can all get back to the more interesting stuff at hand like getting the NAA working in our system.

 

Don't put Johan, 'knowledgeable' and me in the same bundle, thanks. Guy was looking for more info after Superdad said he couldn't write more, I pointed to him where to find the info, and he was dismissive, insulting and vulgar. Couldn't even take the time to read an understand John Swenson. Ignore List, Case closed.

 

Hopefully, I have more interesting stuff to share soon. Not sure I can finish that NAA setup as I have some particulars in my setup, old computers being one of them and not the least.

 

Shoemakers are the worst shod...

 

In the meantime, I did manage to get the native DSD256 streaming ready. Another thread soon perhaps as I get set for some critical listening.

 

What I will say (then I'll shut up about this), and take it for whatever it's worth, is that (1) as Superdad hinted, the back-and-forth wastes *our* time; (2) as victor said, Johann and you are both knowledgeable and helpful forum members, and we would all be delighted to see more of that knowledgeable and helpful stuff from both of you.

[YashN]

Yes, if I can, I'd like to do that. The purpose is to be able to isolate from the server and the Disk and test HQ Player in client-server mode.

 

I know that with GUI and such it's not as ideal, but Lubuntu 32-bit is all I have at the moment, apart from Raspbian on ARM. 32-bit Windows is not supported.

 

The O-Droid is on my mind as potential test-bed for the NAA as well but resources are tight as I would like to repair and DIY a couple of things as well.

 

Are you planning to use the 32-bit system strictly as a NAA/MPD. For NAA you do not need any of the desktop management options so you could potentially strip it down even further but uninstalling unnecessary packages/services which will free up some additional resources.

 

Once I have all the configuration working I plan to rebuild the NAA starting with network install of ubuntu server 14.04, which will have bare bone setup just for NAA