HQPlayer's Network Audio Adapter

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.

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

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

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

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.

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.

I am interested in the concept of the NAA...and have a couple of question (hopefully not too stupid)...here it goes:

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?

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

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

3) is it apple to play gapless?

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.

Thanks!

Miguel

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.

Thanks Miska for the very clear answers!

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

 

 

 

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.

Yes, I must congratulate you for having created a difference concept!

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

True!

My main concern is that it seems you must have a pc turned on in this configuration - Is this true??

This was one of the thinks that keep me away from JRemote as a control application in my situation.

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.

Creative indeed!

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.

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

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

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.

I was drawn into NAA not only for the concept but also on the reports on the sound quality versus a "normal" CAPS server...

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.

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

Hi Miska. I would like to start a HQplayer trial with NAA ( need to compare with my cMP2 setup ) and I was ready to acquire a BeagleBone Black board ...

So, reading your comment, I understand Beaglebone it isn't going to work as is, but need a spacial package ( not currently available ) right ? In addition, my current USB>SPDIF converter is Hiface EVO, so NAA must definitely support Debian Package built for VoyageMPD:

EVO package .DEB

Two questions:

- What NAA do you suggest me ?

- Do you think Hiface EVO .DEB package can be load into the NAA ?

Thanks in advance. Massimiliano

I used to run NAA with EVO with no problem. It should work.

But my evo driver was compiled by myself so YMMV.

Also Ive noticed that NAA seems to conflicting with some kernel Ive used.

Does it require to run with original linux scheduler?

Bests

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.

I guess the problem might have something to do with my brain fuck scheduler.

Otherwise it's just some modules enabling the i2s output of my rpi.

I will give it a try later to see what the problem is.

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

Great. Thanks for reply and comments. Yesterday I ordered a BeagleBoneBlack board and a new linear power supply in order to have Pc, Hiface EVO+Clock and NAA powered by a clean source. So I expect to start soon your player evaluation ... :-)

See you soon, Max.

@Ikong. What's the difference between your EVO driver respect the "classic" one ?

@ipoci If they all came from the same source code there shouldn't be any.

@Miska

BeagleBone Black arrived, linear PS arrived, I'm still traveling but plan to be back at home soon and start HQplayer evaluation. I've the idea to configure two identical Linux based setup, one without NAA and another one with NAA in order to evaluate improvement of one against the other.

Have you any special feedback about Lubuntu ( I've the idea of using this distro ) tuning ?

Thanks in advance. Max

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

Thanks, I will try to find out and install the "low latency" ... Normal Ubuntu should be ok as well, I have some laptop computers available for testing and most of them are i5 processors ...

See you soon, Max

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

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

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)

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

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

Hi Miska, I goy my BBB ... Just a stupid question due to the fact I never played with this minimal computer.

In order to install Wheezy, do I need this kind of connection, right ?:

Router --+---ethernet---BBB

|

+---ethernet---PCWindows

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

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.

Wow ... Working with BBB it isn't straightforward ... :-(

First I tried with an Debian 7.1 netinstall .iso file. I downloaded file from here, then using Unebootin in a Linux PC I dump the image into a MicroSD connected by USB adapter.

Then I put MicroSD into BBB, boot with the switch button pressed, nothing happened ... no boot at all ...

I did a second try following the procedure here from the Linux PC to the MicroSD ... Then I moved the SD into BBB and I was able to boot.

I added the required libasound2 etc.etc., connected the M2Tech EVO but I wasn't able to play any sound. To be honest I wasn't able to see any advice M2Tech was present as recognized device.

Are you using 7.1 iso image or 7.0 .xz image ?

How to check on BBB if an audio USB adapter is there or not ?

Thanks in advance, Max

This is what I see on NAA ...

root@debian-armhf:/home/debian# ls -l

-rw-r--r-- 1 root root 111656 Oct 5 17:27 networkaudiod_2.0.5-20_armhf.deb

root@debian-armhf:/home/debian# aplay -L

null

Discard all samples (playback) or generate zero samples (capture)

default:CARD=Black

TI BeagleBone Black,

Default Audio Device

sysdefault:CARD=Black

TI BeagleBone Black,

Default Audio Device

Max

 

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.

How do I start HQ Player in network mode for Linux ?

M2Tech Hiface DAC should have XMOS chipset ... totally different than my EVO/Hiface1/Young DAC ...

Max