Jump to content
4est

HQPlayer's Network Audio Adapter

Recommended Posts

Do I understand it correctly that this is akin to mpd, but on steroids- pre processing the FLAC and upsampling and then via ethernet sending those files to an NAA?

 

Yes, sort of. NAA is a way to expose remote audio devices to HQPlayer over asynchronous network link. It is just an audio "renderer" with support for number of different audio endpoint devices. Playback by NAA is completely clocked by the audio endpoint device and NAA performs only buffering, no decoding or processing at all. (A bit like asynchronous USB DAC, but having ethernet interface instead.) These endpoints are shown in the HQPlayer device selection just like local devices would, so you could have for example following kind of list:

livingroom: Mytek Stereo192-DSD DAC

livingroom: Musical Fidelity V-Link192

bedroom: Fostex HP-A8C

 

So in a local network there can be any number of NAA devices and each can have any number of audio endpoint devices.

 

All processing is performed by HQPlayer, either the Desktop-version which combines GUI and processing engine, or the Embedded-version which further splits the processing engine and GUI to separate entities.

 

Embedded version has a "headless" server process to perform all the actual file decoding and processing activities, it can play back audio to local devices or remotely to a NAA. For Embedded there's a separate touch-optimized remote control GUI that also operates over the network (can be run locally on the same machine too, nice for Win8 touch). Currently only Windows versions of these are downloadable, but Linux versions are possible too, just not offered due to low demand. I'm using both Windows and Linux versions myself.

 

Do you make such an NAA, or is it simply a Linux Ubuntu ALIX appliance or something that one builds themselves?

 

I'm not selling any hardware, not least due to EU regulatory overhead concerning direct electronics sales to consumers. One could also ask Demian/Auraliti or Jesus/Sonore for possibilities about having NAA on their devices.

 

Building a NAA device yourself is also an option, 32-bit x86 binary (deb) is offered for download. With ARM9 "armel" deb and Cortex-A8 "armhf" deb already in use here, and possibly coming available for download too. I also just got my Raspberry Pi and will be making a build for it too, just been a bit busy lately.

 

In purchasing a license for "embedded" does it include the rights to your Network Audio Daemon and the Desktop server, or does one need to purchase two licenses?

 

Any HQPlayer Desktop or Embedded license includes license to use any number of NAAs on your local network. Or to be exact, it's kind of vice versa, NAA EULA requires you to have a HQPlayer license.

 

Does the Network Audio Daemon do multi channel too?

 

Yes, up to 8 channels. DoP works too, up to 5.1 channels.

 

How do you suggest to go from ethernet>i2s?

 

Many of the SoC's (System-on-Chip) solutions have integrated I2S+I2C+SPI interfaces, so there are various ways how these can be utilized. Depending on particular hardware. So either interfacing to another box or directly to a DAC chip. But this is more hardcore, more for DIY hardware guys, or hardware companies (device manufacturers).


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites

Just some additional thoughts,

 

My point in the original posting was that a traditional "UPnP streamer" performs all kinds additional processing, like reading content from a mass storage, decoding a FLAC for example as well as commonly servicing a user interface too. So it practically becomes a single-purpose player computer.

 

Idea behind NAA is strip down as much as possible from the device that is connected to the DAC by keeping as much as possible behind the network in a player software. So NAA can become "whisper quiet" in terms of activity and also benefit from the isolation provided by Ethernet. And also isolate as much as possible at the software side by using a large asynchronous FIFO buffer. It also makes it easy to get high speed asynchronous optical isolation by using optical ethernet.

 

What I mean being quiet is also that it is possible to make a NAA run out of four AA batteries, or from a proper linear PSU. While not giving up any amount of processing at the player side.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites

One example photo:

 

NAA (ARM Cortex-A8 CPU) -> MuFi V-Link192 -> Mytek, playing back 192k PCM in this photo:

arm-naa-small2.jpg

 

(this board could run the Embedded engine too...)


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
At the risk of seeming silly, but can you make some specific device suggestions. The ARM device in the photo for starters, and maybe some bare bone computers. You mentioned a raspberry pi, and I assume a beagle board would work as well, but I do not know enough about any of them to dare just start. I think that I (and others) might be interested in some more turn key sort of options doable by novices such as myself.

 

No, not silly at all. I have just not yet decided what to specifically recommend. And since I have really limited technical support capacity I have to pick up only one thing that is easy enough if I start publicly offering something other than just a software component for DIY.

 

One option is to use some passive cooled Intel Atom, AMD Fusion or VIA Nano -based computers and install the provided binary package there. Ubuntu Server is a good starting point. Logic Supply sells bunch of different kind of suitable computers. Plus there are some companies selling VIA Artigo computers. I've sold a couple of pre-installed bootable USB memory sticks for these kind of computers.

 

The board in picture is BeagleBoard xM. I have also two BeagleBone boards, a Raspberry Pi (yet to find time to power it up) and Acme Systems FOX G20. (Note: USB on G20 is limited to 12 Mbps so 24/96)

 

Apart from plastic boxes for Raspberry Pi and FOX G20 I'm not aware of any ready-made casings for these, so it becomes more DIY and sourcing a good linear PSU requires some care.

 

I'll probably make ARM binary packages available sometime soon, when I get the same version of NAA software module built for all. Now the binaries I have are different versions I've built when I played with the particular hardware...


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
I hate to say this, but there may even be a market for something simple like a raspberry pi with a plastic case that outputs USB.

 

That's pretty much it... And zero-configuration (OK, you can give it a name through the player GUI). I still have to check what is the easy&optimal way to put it together and write some instructions for example here, needs a bit stripdown from the default OS. Audiophile-grade case for the Pi:

Pi Holder milled aluminum case for Raspberry Pi with logo ID: 1039 - $74.95 : Adafruit Industries, Unique & fun DIY electronics and kits

 

Found a casing for BeagleBone too (there seem to be some other too):

Adafruit Bone Box - Enclosure for Beagle Bone ID: 699 - $19.95 : Adafruit Industries, Unique & fun DIY electronics and kits

 

Heck, make it work on 5v or 12v and there are plenty of LPSs and more to come.

 

That's one reason I'm using these ARM-boards, they consume very little power, produce no heat in NAA use and run out of single 5V supply.

 

(and prices are tolerable)


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
The NAA that my PK90USB provided was, of course, ethernet in, USB out.

 

Yep, easy way to obtain a ready-made NAA with USB connectivity. Probably works on the other Auraliti variants too.

 

Since a goal of the possible hardware-based generic NAA is simplicity and uniformity (tech support would be minimal), what do you envision the digital output variations or options to be, if any? USB only? S/PDIF?

 

The ones currently in use are USB, SPDIF/AES and Firewire. Most popular at the moment is NAA with Firewire connection to a Mytek DAC. But of course there are good USB options too, like the Sonore/exD DAC.

 

Or you can build NAA straight into the DAC. Practically all ARM SoCs have I2S, I2C and SPI so it is possible to build a DAC with straight ethernet connection. Or have just an I2S output. (BeagleBoard and Raspberry Pi have a not-so-great DAC on-board)

 

These are the options I'm prototyping. Which one is best depends on the particular implementation and preferences... At least for me personally it is nice to be able to make almost any existing DAC network-connected with a tiny configuration-free box.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
I2S- really? Is that on the pin headers, or do you tag it off the board? If there is a way to back clock it from the DAC (or an external clock), then sign me up!

 

Usually it is on the headers, as well as I2C to control the DAC chip registers. Typically clocking can be also modified, depending on capabilities of the particular SoC.

 

To deal with the particular DAC chip and clocking configuration it needs a small custom ALSA audio driver. This adaptation is part of a BSP.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
Does the Rasp Pi package support i2s?

 

I2S is at much lower level, there's an ALSA audio driver layer between the NAA software package and hardware.

 

I tested it with USB audio ALSA driver last night.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
I am confused Miska. Are you saying it does not support i2s? I'll cancel my order, and try one you suggest if that is the case. It did seem too good to be true.

 

It supports what ever the Linux kernel drivers support. The default driver supports HDMI and headphone/line output that are on the board. Looking at the Raspberry Pi forum, people seem to be in process of modifying the default driver to support I2S for the purpose of using it with a DAC. The easier part seems to be to use it in "PCM" mode which doesn't have a master clock (only bit clock, word clock and data line). There's also discussion about slaving the I2S to external clock.

 

My stuff is about getting audio to the drivers. What kind of hardware is behind the driver is outside of this scope.

 

For my own purposes I write the necessary ALSA drivers to support the particular DAC chip I have connected (programming the settings of a DAC chip over I2C or SPI) in a certain way to the specific SoC. This is the BSP part I was talking about, adaptation work to make use of certain specific hardware configuration.

 

I got my Raspberry Pi couple of weeks ago, so I haven't done much on it yet, powered it up first time last night to compile NAA software package. BeagleBoard and FOX have been in active use for fairly long time.

 

If you want to use other than the on-board devices by connecting to the pin headers, be prepared to write your own custom drivers for your particular connection. :) Pin headers lead to the SoC's GPIO data lines which you can define to do all kinds of different things. By following the hardware forums, you may find out useful drivers someone else has made for similar purpose though...


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
* does it make any sense to put a SOtM USB card in the NAA (i.e not in the source since that is only network-connected)?

 

Yes, it makes sense for PC-based NAA when using USB connection.

 

* how are you (or would you envision) browsing a large library from your listening position in a main (i.e not headphone or desktop) system? It seemed (months ago) that Miska's software is not very GUI or remote friendly, compared to things like J River/jremote, etc.

 

With the HQPlayer Desktop recommended remote control is to use the Microsoft's Remote Desktop Client. Our family has been also using the Mac version on MacBook Air. Works fine because the GUI is lightweight with minimal re-draws. I'm not fan of VNC's protocol...

 

I have fairly large collection and the HQPlayer Desktop works just fine for me, because of the three filters in main window (artist/performer/album). Those allow basic asterisk style filters like Artist: "pink*" Album: "*wall*", or by prefixing with hash mark (#) you can use regular expressions for more powerful filters. And since content is expressed as a tree model in artist/performer/album/song structure (idendepent of where the files are located), it should be fairly quick to browse too. In the library editor you can add directory trees by scanning starting from given base folder. The already known leaf (content) folders are ignored so you won't get doubles even if you rescan already known tree. If some metadata is incorrect, you can edit the read metadata by double-clicking on the cells in the library editor. Editing won't touch the original files, just modifies the metadata stored separately by the HQPlayer...

 

HQPlayer Embedded separates the player into headless server and touch-optimized GUIs. The GUI works also with mouse, but is designed specifically for touch. It is probably most convenient with Windows 8 (non-RT) tablets. It supports both 4:3 and 16:9 display ratios with different layouts. Embedded server uses same configuration file as the Desktop version and is usually most convenient to initially configure using the Desktop version smaller modifications can be made by hand with text editor.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
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?).

 

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

 

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

 

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.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
Miska, when you talk about a 'PC-based NAA', I'm assuming you mean a machine with a regular mobo/CPU, as opposed to something like a Raspberry Pi, right? Some people might confuse 'PC-based NAA' with 'Windows-based NAA' and I just wanted to be clear.

 

Yes, exactly, "x86 architecture" hardware as opposed to "ARM architecture" like Raspberry or Beagle*.

 

My other question: have you got the Mytek Linux USB drivers working yet? I'd love to try this...

 

Kind of, it would probably work with latest NAA due to the way NAA deals with the driver. But it doesn't work with HQPlayer Desktop's Linux-version. And it's a bit tricky since I cannot redistribute the needed firmware files (for the FPGA and Cypress USB MCU), which the driver uploads to the DAC every time the DAC is started or re-connected.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
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....

 

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.

 

This is how my current lab test system looks like:

bbnaa.jpg

 

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?

 

"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)


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
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?

 

NAA needs to have a DHCP server on the network, so I usually recommend to just connect it to a normal home network hosted by a router/firewall that has a built-in switch, something like Airport Extreme, but there are many other suitable and less expensive devices (Cisco, NetGear, D-Link, Zyxel, etc). Airport Express configured as a bridge could work too, I have not tested such configuration though.

 

I'm a bit concerned about having WiFi cape on a BeagleBone or use of WiFi USB adapter, it could work, but it could cause quality degrading amount of RF noise too...

 

I have entire house covered by CAT6 network cabling with a gigabit switch in the central patch bay. My switch has VLAN and QoS support. But this is cheapest media/QoS gigabit switch I know of:

GS-105S | ZyXEL


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
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?

 

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


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
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)?

 

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.

 

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.

 

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

 

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


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
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)?

 

No, that's all it prints out...


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
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.

 

Strange, maybe the system is running at some other run level and it is not set to start at that level. You can ask update-rc.d to specifically start it at some run level too. "runlevel" will tell the current level.

 

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.

 

Which interface was it that worked when you first tried? Do you have pulseaudio or similar running? Please always try first with buffer time setting set to default, for NAA that should work fine in most cases. Does this happen when running networkaudiod as a root?

 

The system I am using is really minimal with just kernel, shell and networkaudiod and sshd running.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
I am interested in the concept of the NAA...and have a couple of question (hopefully not too stupid)...here it goes:

 

There are no stupid questions, only stupid answers... :)

 

1) Can the NAA receive data from other sources than the HQPlayer/PC?

If yes, could we use a NAA to point to a NAS and feed itself on the "music" directory?

 

No, it is only for use with HQPlayer. NAA is intended to be as dummy as possible to run on very minimal hardware with minimal activity. If it would feed itself from NAS it would already need to have a full player functionality, such as understanding about different file formats, decoding FLAC and things like that. There are already various "UPnP streamers" on the market for that purpose.

 

(I understood that HQPlayer is capable of many operations, I am not very inclined to explore them and tweak, as I prefer a purist approach of "Select and Play").

 

HQPlayer has default settings, and you can modify the default settings too, but you don't necessarily have to. But on the other hand, I don't want to pretend to know what would sound universally best on all material and to everybody. :) I myself use different settings for classical and pop/rock.

 

I just have my own vision how I like things to be implemented, and I do recognize and accept that it's not everything for everyone (which in turn, is IMO, definition of bloat and compromise).

 

2) Does the NAA build a local database of the music, or is really just a "fifo buffer of a playlist (as I believe it's the case)...

 

No, it's much lower level. You can think of it as a network equivalent of USB Audio Class, it could also be called something like "Network Audio Class". It's a way to add a network interface to your DAC. It just happens to support also multiple such adapters on the network with multiple DACs connected to each.

 

3) is it apple to play gapless?

 

One of HQPlayer's main design goals was to get true gapless playback. That's why it for example never changes DAC's sampling rate between "play" and "stop". Changing clock would create a gap or other kind of discontinuity, even a millisecond long gap is still a gap.

 

That's why it's also "album player" in a way that GUI's main usage pattern is to select an entire album for playback instead of individual tracks. Album is always considered to be one entity, instead of a track.

 

4) on the output, can it work with SPDIF? If it connects directly to a DAC via SPDIF is this considered to be sub-optimal someway?

(for now I am looking forward to change my dac, which as AES and SPDIF entries.

 

I have a NAA on my table at the moment, with Musical Fidelity V-Link192 connected to it... So any audio interface supported by the OS are available regardless of connection type.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
My main concern is that it seems you must have a pc turned on in this configuration - Is this true??

 

Yes, the player computer is needed to do all the dirty work of playback. Currently either Windows or Linux PC, but possibly soon also on some small ARM-based computers. With tablets like Microsoft Surface Pro it is possible to run the player on a tablet too.

 

Does it creat any limitation on creating playlists from different albuns?

 

Limitation is that playlist contents must be possible to play with the selected upsampling algorithm without changing output sampling rate. For example with "poly-sinc-*" filters practically any source file sampling rate is possible - the output is running at fixed rate like 192k while source file sampling rate can vary.

 

Could you open HQPlayer to another server (I prefer minimserver for it's intelligent browsing functionality and the flexibility of using my own tags anywhere in the navigation).

 

Sort of... I have (/had) an SDK for developing different kinds of front-ends to the player engine. But I'm not considering UPnP because of it's combination of bloat and limitations.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites

The hiFace/Evo/Young driver should work just fine. All the versions I've tried have been working without problems.

 

There used to be a separate build meant for BeagleBone, but now the latest versions incorporate the necessary changes (in the standard 2.0.4 "armhf" package).

 

I have not found a kernel that would not work, but of course if there are some really unusual patches applied there could be some problems in some cases. But I would consider it more of a bug in the kernel than the networkaudiod, since it doesn't use anything extraordinary from the kernel. So as long as the kernel is technically compliant with all features of upstream / pe-rt kernels, it should work. Scheduler is expected to be standards compliant.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
Have you any special feedback about Lubuntu ( I've the idea of using this distro ) tuning ?

 

Just use the "lowlatency" variant of kernel available from Ubuntu repositories. Everything else is already taken care by HQPlayer.

 

If you prefer more pretty GUI, you can also use plain normal Desktop version of Ubuntu (instead of Lubuntu). Of course the graphics side will be heavier that way since then there's a desktop compositor using OpenGL. When using NAA it doesn't matter...


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites

For BeagleBone Black, easiest way to get started is to install minimal Wheezy image from here to the internal MMC flash:

BeagleBone Black

 

From Windows you can use for example PuTTY to remotely login to the device and upload files.

 

Once installed, just:

1) Install latest OS updates

sudo apt-get update

sudo apt-get dist-upgrade

 

2) Install necessary dependencies (alsa-utils is optional, but the utilities are helpful sometimes)

sudo apt-get install libasound2 alsa-utils

 

3) Download the latest networkaudiod deb package for armhf architecture from my website either directly to the device using "wget" or upload the downloaded through SSH.

 

4) Install the package (correct the version number to what ever is latest at the time)

sudo dpkg -i networkaudiod_2.0.4-19_armhf.deb

 

5) Done. Just start the HQPlayer in network mode (only mode available on Mac version) and select correct output device from settings.

 

 

I have tested this method and it works like charm (for me) at least up to 384/32 stereo which consumes about 14% CPU time on the BeagleBone Black. Tested with M2Tech hiFace DAC.

 

HDMI audio output seems to be also available, but I didn't test it. Need to get suitable HDMI cable first...


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites
So basically I can reach BBB console by remote login service on putty working on Pc.

 

Is a MicroSD absolutely necessary ? Reading the link you posted looks like you definitely need an SD to download the .xz image and then install into the internal eMMC

 

Is it right ? Thanks. Max

 

Yes, with the image available at the armhf.com it boots up with SSH server, so you can remotely access it and dump the image to the internal flash (/dev/mmcblk1). And the way to boot the device to something other than the default OS image is microSD.

 

So the procedure I did was to dump the image first to a microSD card on PC (you need to be careful on the destination device, otherwise you risk wiping your HDD!). Then I re-inserted it to refresh the OS partition table and then mounted the filesystem and copied the compressed image inside there too. Then I booted the microSD by holding down the alternate boot button while powering the device up. Then I just SSH there and dump the contained image to the internal flash. Then clean shutdown (shutdown -h now) and power down once it's properly down. Then removed microSD, powered it up again and then the procedure I posted earlier. That's it...

 

I know this is still not plug'n'play, but about as simple as these small ARM devices can get. Less than an hour total for me. Some more tricky devices can take a week of fighting to get all things up and working!

 

Warning! If you are not familiar playing with raw disk images, use a computer that doesn't contain any important data, because it takes only a small mistake and your HDD is wiped.


Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Share this post


Link to post
Share on other sites



×
×
  • Create New...