HQPlayer's Network Audio Adapter

[Jud]

Let me see if I am getting the topology right, and then a further question:

 

I would run HQPlayer on my desktop upstairs with Lubuntu as OS, let us say, and then have a Raspberry Pi as NAA connected via USB to my DAC downstairs, controlled with a suitable remote app (would Win RDC work here?).

 

Should a DAC that doesn't require custom Linux drivers for USB work (e.g., my Schiit Bifrost)?

[Jud]

Apologies in advance, I've got a bunch more questions that I'm pretty sure would be obvious to others, but not me.

 

Yes, you would be controlling the HQPlayer running on the desktop. NAA itself in turn is handled by HQPlayer.

 

At the moment I don't recommend Raspberry Pi until the USB hardware issues it has have been sorted out (mine is older hardware revision, newest one may be better). But I have pretty nice setups with BeagleBone powered by four AA batteries and another one using BeagleBoard xM. Of course AA battery powered solution works only when connected to a USB device that doesn't draw any significant current from the USB... For a Firewire device like Mytek something like PC-based main board is needed to be able to accommodate Firewire adapter.

 

All right, the battery powered version sounds like something I may be interested in. A bit less expensive than the XM version of the board, too. The Bifrost uses wall power (IEC plug) so no worries about current draw, and I'm assuming the 5v from the batteries is enough for the BeagleBone to let the DAC know it's there. But here I start running into problems with my thought process. How do I get wi-fi, battery power and a usb connection to my DAC all at the same time? Wi-fi seems to use USB or a cape, battery power appears to use a cape....

 

I'm supposing I would install the HQPlayer on Lubuntu on the desktop. Would the daemon also be installed on the desktop, or on the BeagleBone? Can Angstrom Linux remain installed on the BeagleBone, or does it need another OS and/or application software?

 

Yes, although I remember Demian mentioning something about compatibility problems between the Linux driver and the CMedia chip used in Bitfrost, but it may have been solved since, I don't know.

 

There's now also driver for M2Tech devices, so those also work.

 

I'm hoping a new USB board for the Bifrost, which should be available very soon if it is not already, will resolve any remaining problem - it has been updated at least to the extent of allowing use of the USB input with a 176.4kHz signal, which is not possible with the original board.

[Jud]

In any case BeagleBone accepts 5 VDC through a standard round socket, so if more power is needed a separate linear PSU is also good option. Another option is to use split USB wire with separate power feed. So there are many possible options. I don't recommend using WiFi because it would need extra configuration and such, my current OS builds have WiFi support disabled. Current one is plug-and-play.

 

OK, so since my desktop that would be running HQPlayer is upstairs in my office and my main audio system where I'd want the NAA is downstairs in the family room, I suppose I would need an Airport Express or something similar (or even my MacBook Pro) from which to run an Ethernet cable to the BeagleBone. If a router, any recommendations for something good and inexpensive? What is your assessment, if you have one, of the sonic tradeoff of having WiFi running on the BeagleBone versus having the BeagleBone connected via an Ethernet cable to a laptop or something plugged into the mains? Would such an arrangement cause any problem at all for HQPlayer to recognize the NAA on the network?

 

Mani, how is your NAA hooked up to Ethernet?

 

This is how my current lab test system looks like:

[ATTACH=CONFIG]3316[/ATTACH]

 

 

 

"Network Audio Daemon" runs on the BeagleBone. Ångström can be possibly used with the daemon binary I'm currently using. However I have a complete custom OS build for the NAA use. Since BeagleBone boots from a microSD card you can easily have number of different cards to play with. Plus there's a package for Ubuntu on my website already.

 

I have not yet decided a distribution model for the BeagleBone OS build, but probably I can at least mail a ready made microSD for some reasonable compensation. (a bit of Linux command line work is needed for creating the microSD)

 

Depending on what the command line work is, it's possible I could do some or even all of it myself, though if not I certainly don't mind compensating you. I'll PM you to talk about details.

[Jud]

Sounds good, I have a home network with a Netgear N900 upstairs that hands out the internal DHCP addresses. There is an Airport Express downstairs that currently connects a PS3 to the home network, but the PS3 is rarely in use, only when playing SACDs. So it would be easy enough to plug the Ethernet cable from the Airport Express into the NAA. Connecting to the MacBook Pro Ethernet port, if possible, could be interesting since the MBP can be run on battery power, but I wonder if that would work or necessarily make for better sound.

 

Anyway, I can certainly provide a wired Ethernet connection for the NAA. So let's do this thing! :-)

[Jud]

Sounds good, I have a home network with a Netgear N900 upstairs that hands out the internal DHCP addresses. There is an Airport Express downstairs that currently connects a PS3 to the home network, but the PS3 is rarely in use, only when playing SACDs. So it would be easy enough to plug the Ethernet cable from the Airport Express into the NAA. Connecting to the MacBook Pro Ethernet port, if possible, could be interesting since the MBP can be run on battery power, but I wonder if that would work or necessarily make for better sound.

 

Anyway, I can certainly provide a wired Ethernet connection for the NAA. So let's do this thing! :-)

 

So I now have a BeagleBoardXM on which I've installed a minimal Lubuntu and the Network Audio Daemon. (My tremendous gratitude to Robert C. Nelson for his fairly foolproof scripts, which made this easy, as well as to Miska for pointing out Nelson's page to me, answering a large number of more or less clueless questions I had, and not least for developing HQPlayer, the Network Audio Daemon, and the idea of the NAA.) I've tested HQPlayer's network audio (running on Lubuntu on my desktop in the upstairs office) with the Daemon running on the BBXM, and it works. Tomorrow evening I'll hook up the BBXM to my main rig downstairs and see if that works.

 

Another question at this point: Is there any reason I would *not* want the Network Audio Daemon on the BBXM to automatically start at login? If automatic startup at login is desirable, what's the best/easiest way to do this?

[Jud]

By default it should automatically start already at boot time, no need to login at all...

 

It doesn't, so I did something wrong - probably the first few times I started it or stopped it using the terminal screwed it up. I don't know Linux as well as FreeBSD (not that I'm any sort of hacker on the latter), so what should I do to restore normal function - go looking around in /etc/rc.d runlevels (which FreeBSD doesn't have so I'm not at all versed in them)?

 

But of more significance - I can connect to the BBXM downstairs through the Airport Express, and the network player on the upstairs desktop machine runs, though I had to set buffer to the max 250ms to keep the connection up. But I got no sound through the USB connection from BBXM to Bifrost, even with the volume on the desktop turned up to 100. (Actually, if I turned the volume way up on my preamp downstairs, I could hear electrical noise in time with the pulsing of the Ethernet connection light on the BBXM; I had the USB cable lying over top of the Ethernet cable just while running the test to see if it worked.) When Lubuntu was shutting down, I got a repeating console message to the effect that it could not enumerate whatever was attached to USB hub 4. So I'm guessing the CMedia USB chip in the Bifrost doesn't yet work in this application. (A new USB board should be available soon.) I need sleep tonight, but tomorrow evening if there is time I will try with the Dragonfly upstairs to see if that works.

[Jud]

There's "update-rc.d" for controlling loading of the boot up services. It should get enabled with "update-rc.d networkaudiod defaults".

 

You can also start-stop the service with "/etc/init.d/networkaudiod start" or with "stop" to stop it.

 

Thanks.

 

I'm assuming you had the Bitfrost selected as a device from HQPlayer (since the BBXM has on-board audio too)...

 

Whoops, actually only the BBXM was available under devices in speaker setup (I just unthinkingly assumed since it was connected to the Bifrost, that was the same as the Bifrost). Should maybe have given me a clue, eh? I'll check with the Dragonfly and make sure that's shown under its own name as a separate device.

 

Could be a compatibility problem Demian was talking about in the past, maybe it has been fixed in recent kernels and the BBXM installation should already have fairly recent one.

 

You can also see how things are going by starting networkaudiod manually (just check that it is not already running in the background) and it'll print out some status information as things proceed. When doing this, run it either as a root or make sure your userid has been added to group "audio"...

 

I've been running it manually from a terminal, and it prints console messages about the alsa device being connected, how many channels, resolution, etc. Is there any additional information available (a -v setting or something similar)?

[Jud]

There's "update-rc.d" for controlling loading of the boot up services. It should get enabled with "update-rc.d networkaudiod defaults".

 

You can also start-stop the service with "/etc/init.d/networkaudiod start" or with "stop" to stop it.

 

Doesn't run at boot, or at all unless I manually start. But if I try update-rc.d... it says the link is already there. Sigh.

 

But anyway - guess I know how to mess something up, because with the Dragonfly plugged into the BBXM's USB and selected in the Network Player's settings, yes, I can get music to play, but it's pretty well submerged behind loud static-like noise. With regular HQPlayer on Lubuntu, everything works nicely, sounds good.

[Jud]

 

It is reported Peter St in his NOS1a has a USB receiver implementation that is immune to PC USB issues, but he is not telling how he did it !

 

It was thought so by at least some users early on, but since then it's been established (subjectively) that there is some susceptibility of the sound to things like USB cable changes. PeterSt agrees this is the case. I will say, though, having through the generosity of another forum member had the NOS1a for several weeks in my home, that the *degree* of difference in sound quality owing to changes in USB cables seemed to me much less than in other DACs I've tried this with.

[Jud]

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

 

It's nothing to do with async. It's whatever electrical noise is caused in the USB receiver by it having to call for more data when the buffer is emptying. Nice steady supply of data, less electrical noise in the USB receiver.

 

At least that would be what's going on conceptually. I haven't done any testing, so I cannot say to what degree if at all this would affect the sound.

[Jud]

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.

 

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.

[Jud]

I would think not at all for ASYNC, good for adaptive perhaps?

 

johann, as I mentioned upthread to EuroDriver, this is definitely not about clocking of the bitstream into the USB input, which is what async was designed to make irrelevant. Rather, as John Swenson has mentioned in several comments on the site, it would (at least conceptually) be about how much electrical work the USB receiver on the DAC side must do to keep the buffer filled.

[Jud]

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 ?

 

I don't think so.

 

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 ?

 

No - odd to me that the layout would be such that path length (for what - channel, two different processes on the same execution path, something else?) would be so different in the first place.

[Jud]

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.

 

When you find a DAC with a 16GB memory buffer at the USB input, let me know. :-)

 

The memory buffer for software players is at the computer, so we're talking about two different things.

 

Yes, there are a wide variety of methods Peter utilizes. I certainly don't know of or understand all of them.

[Jud]

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.

 

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.

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

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

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

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

[Jud]

If I had an NAA setup, I would strive to make it as bare-bones as possible, not only apps-wise (some may contain daemons running in the background)

 

Out, out, ye vile running daemons!

[Jud]

Wow, you are on a roll these past couple of days Jud. (All that sparing with Priaptor in that nasty other thread much have sharpened your wit a bit. )

 

Unfortunately the result understandably exasperated some folks. Hope alfe does not actually wind up leaving.

 

Will have to redouble efforts to keep the conversation to audio, even when diversions seem interesting.

[Jud]

Depends on your situation though, if you need remote playback and installing cabling is difficult, NAA works. But you need 3! computers alt a renderer device to play music...it's clunky. One to control HQ Player on the host or via VNC, a renderer or another PC, the host PC Player plus the cabling. Great empire building for your network.

 

 

I personally would say two computers for remote operation: HQPlayer remotely running on a host, and the NAA as client connected to the DAC.

[Jud]

I don't think you'll be able to get an ASIO driver running on it.

 

 

I may very well be confused/wrong about this: I have a Geek Out running on Windows 10, and I thought the driver was ASIO.

[Jud]

Windows 10 LoT?

 

Ah, *that's* where I'm confused/wrong.

 

Win 10 IoT (Internet of Things) Core looks interesting - wonder if it actually *is* interesting? But this is likely OT, my apologies....

[Jud]

I suppose those powerful capabilities would be being able to leverage the development time already invested in windows based applications/drivers, while still having low overhead close to Linux.

 

Great example being I can run a Exasound E28 on my NAA and take advantage of the NAA multichannel capabilities. Can you do this on a Linux based NAA?

 

The situation seems rather paradoxical:

 

- More audio devices *that need drivers not already built into the OS* have them for Windows than for Linux.

 

- Many more audio devices have drivers already built into Linux than have them already built into Windows (all of USB Audio 2.0 for a start).

 

- If you need to have a driver for an audio device added to an OS, there is much greater likelihood you will find someone willing to do it for Linux than that MS will be willing to do so.

 

- If you need to have a driver built to have an audio device work with an OS, I don't know whether there's a better chance of getting it done for Linux or for Windows. Perhaps a slight advantage to Windows due to manufacturers being possibly more concerned about whether their devices will work with Windows than are worried about customers who are Linux users, but I'm not sure.