HQPlayer's Network Audio Adapter

[mvilla]

5 hours ago, Miska said:

Just a short note, there are new bootable images downloadable for BeagleBone Black, RasPi3 and x86-64. The former two work up to DSD256 / 384k PCM for me and the latter of course to DSD512 / 768k PCM.

 

Now root login is enabled and I added alsa-utils, so there's "alsamixer" and such if needed (for adjusting output volume with some portable interfaces etc).

 

The x86-64 image requires modern BIOS capable of UEFI boot.

 

Hi Jussi, is the x86-64 image ok for Cubox-i2?

thanks

 

[Miska]

5 minutes ago, mvilla said:

Hi Jussi, is the x86-64 image ok for Cubox-i2?

 

No, it is for Intel/AMD PC hardware (possibly including Mac's, not tested though).

 

Since NXP acquired Freescale, they've changed license terms for some of their software components to a new stupid and unacceptable one. So no more images for CuBox-i for the time being. Of course you can still take the normal Debian 9 + networkaudiod package route which works perfectly fine!

 

[RRSR]

11 hours ago, Miska said:

Just a short note, there are new bootable images downloadable for BeagleBone Black, RasPi3 and x86-64. The former two work up to DSD256 / 384k PCM for me and the latter of course to DSD512 / 768k PCM.

 

Now root login is enabled and I added alsa-utils, so there's "alsamixer" and such if needed (for adjusting output volume with some portable interfaces etc).

 

The x86-64 image requires modern BIOS capable of UEFI boot.

Hi Miska, i´m seeing x64 image only, would  you mind upload x86 image please?

Thank You!

[Miska]

1 hour ago, RRSR said:

Hi Miska, i´m seeing x64 image only, would  you mind upload x86 image please?

 

Only x64 available, I'm not planning x86 (32-bit). Tool old hardware. I also dropped older RasPi's.

 

But you can always install 32-bit Debian 9 and networkaudiod package on it.

 

[RRSR]

11 hours ago, Miska said:

 

Only x64 available, I'm not planning x86 (32-bit). Tool old hardware. I also dropped older RasPi's.

 

But you can always install 32-bit Debian 9 and networkaudiod package on it.

 

But there are many users with 32 bits systems installing your NAA software in windows, and best bit depth in most Dacs is 32 bits also, so why do you think 32 bit system aren’t suitable for run NAA image?

 

[Miska]

1 hour ago, RRSR said:

But there are many users with 32 bits systems installing your NAA software in windows, and best bit depth in most Dacs is 32 bits also, so why do you think 32 bit system aren’t suitable for run NAA image?

 

 

I really wonder how all this is related... This has nothing to do with Windows. And bit depth of the DAC has nothing to do with this either.

 

x86-64 platform was published in 2000, 17 years ago...

 

As I said, you can still use 32-bit Windows or Linux and run the provided networkaudiod there to create a NAA. But I won't publish bootable OS images for such old hardware architectures. It is cheaper for you to buy new hardware for NAA than for me to create and distribute 32-bit OS images.

 

[ambre]

On 10-11-2017 at 9:38 AM, Miska said:

Just a short note, there are new bootable images downloadable for BeagleBone Black, RasPi3 and x86-64. The former two work up to DSD256 / 384k PCM for me and the latter of course to DSD512 / 768k PCM.

 

Now root login is enabled and I added alsa-utils, so there's "alsamixer" and such if needed (for adjusting output volume with some portable interfaces etc).

 

The x86-64 image requires modern BIOS capable of UEFI boot.

Dear Miska/Jussy

Does HQPlayer also support Allo USBridge which is running on OS DietPi. Do you have suitable bootable images for this NAA endpoint too?

Thanks in advance, Andreas

[bibo01]

@Miska please some support  on behalf of a friend of mine...

He has Win10 PC with HQPlayer (latest version) cannot see NAA (latest version) on another PC. The same PC with Linux has no problem seeing NAA.

No firewall blocking network connection. He can ping NAA.

This is HQPlayer log:

* 2017/11/13 11:45:07 Starting...
  2017/11/13 11:45:07 Signalyst HQPlayer Desktop v3.18.2
  2017/11/13 11:45:07 Engine selected: 
* 2017/11/13 11:45:07 Control server started
  2017/11/13 11:45:12 Restore GUI state
  2017/11/13 11:45:12 libDSP version 19.0.1
  2017/11/13 11:45:12 Number of processor cores: 4
  2017/11/13 11:45:12 DSP thread pools disabled
  2017/11/13 11:45:12 Pipelined DSP enabled
  2017/11/13 11:45:12 Audio engine: network
  2017/11/13 11:45:12 Network Audio IPv6 support disabled
  2017/11/13 11:45:12 Discovery from 0.0.0.0
  2017/11/13 11:45:13 Discovered 0 Network Audio Adapters
  2017/11/13 11:45:13 Set channels: 2 (2)
! 2017/11/13 11:45:13 createEngine(): clHQPlayerEngine::Initialize(): clNetMiniEngine::Initialize(): adapter not found
& 2017/11/13 11:45:16 Playlist save: C:\Users\filippo\AppData\Local\HQPlayer\current.m3u8
- 2017/11/13 11:45:16 Network engine stopping...
  2017/11/13 11:45:16 Network Audio IPv6 support disabled
  2017/11/13 11:45:16 Discovery from 0.0.0.0

Any suggestion?

 

[ambre]

On 6-11-2017 at 3:21 AM, Miska said:

 

I suspect some other application or macOS is still messing with the same audio device and that why it goes wrong. And that can happen if the audio device is set as default in macOS settings. So please check that and make sure it is NOT the default device.

 

Dear Miska/ Jussi,

 

I have re-installed High Sierra latest version 10.13.1 on both Mac Mini’s. No other applications are running audio.

Most of the times (60-70%) I don’t have problems connecting the NAA 3.5.2. on my other Mac Mini.

 

When I have problems with connecting the NAA the log gives following data. [/Applications/networkaudiod] (575): push to queue timed out. Running my Music from a USB drive connected as sort of Time capsule with my Airport Extreme. Please see attached screen capture for the push to queue timed data.

 

My Mini’s are both Cat6 wired. Is this caused by lack of speed / responsiveness of my drive? Ps. In the nearby past, I used one of the 2 hard drives of my Mac Mini for music. But I really prefer running via improved Ethernet with Uptone Regen with dedicated SMPS-es.

 

But when I just start with PCM instead SDM(DSD) I instantaneously succeed to connect with the NAA. But most of the times with following sequences with buffers set as 116.  

 

[/Applications/networkaudiod] (575): start 384000/24/2 [pcm]

[/Applications/networkaudiod] (575): Set channels: 2 (2)

[/Applications/networkaudiod] (575): Set sampling rate: 384000 (384000)

[/Applications/networkaudiod] (575): CoreAudio engine starting...

[/Applications/networkaudiod] (575): CoreAudio using integer mode

[/Applications/networkaudiod] (575): CoreAudio virtual format: 384000/32/2 [ SignedInteger NonMixable ]

[/Applications/networkaudiod] (575): CoreAudio using non-mixable mode

[/Applications/networkaudiod] (575): CoreAudio physical format: 384000/32/2 [ SignedInteger NonMixable ]

[/Applications/networkaudiod] (575): CoreAudio engine started at: 384000 (384000)

[/Applications/networkaudiod] (575): enter streaming mode

[/Applications/networkaudiod] (575): CoreAudio allocate buffers of size 116.

 

But after restarting the NAA the buffers are set to 512 for both PCM and SDM. Than I stop the PCM conversion and start playing SDM flawlessly the whole day. Strange isn’t?

 

Another question: Teac UD 501 is set by default Mac Mini NAA  in the audio/midi as 2 channels, 24 bits integer 44.1 kHz. Should this be set at a higher sample rate? Or is this managed by HQ-player?

 

Thanks for your reply in advance.

Best regards, Andreas

[Miska]

3 hours ago, ambre said:

But after restarting the NAA the buffers are set to 512 for both PCM and SDM. Than I stop the PCM conversion and start playing SDM flawlessly the whole day. Strange isn’t?

 

Another question: Teac UD 501 is set by default Mac Mini NAA  in the audio/midi as 2 channels, 24 bits integer 44.1 kHz. Should this be set at a higher sample rate? Or is this managed by HQ-player?

 

It doesn't matter. But again, make sure your DAC is not set as default audio device in macOS Audio & MIDI Settings. Set the built-in audio or whatever else as default, as long as it is not the DAC.

 

Otherwise macOS itself may screw up things right away.

 

[Miska]

5 hours ago, bibo01 said:

Any suggestion?

 

Is this multi-homed setup perhaps? Also try with IPv6, it usually works better, but make sure it is enabled in the adapter settings (it is enabled by default).

 

[Miska]

8 hours ago, ambre said:

Does HQPlayer also support Allo USBridge which is running on OS DietPi.

 

AFAIK, DietPi comes with networkaudiod, so it should work.

 

8 hours ago, ambre said:

Do you have suitable bootable images for this NAA endpoint too?

 

No, only x86-64, BeagleBone Black and RasPi3 at the moment.

 

[Allander]

@ambre 

I have been using the Allo Usbridge as an Hq Naa with great results. There was an issue when I began with the unit where it was dropping connection while cycling tracks or artists however with the recent v158, I and all others posting, have found this to be resolved. 

Awhile ago I posted in this thread about an inability to use Hq player for dsd 512 with a mR at the time. Since then I have tried the uR, sotm 200 and sotm ultra and found the same results every time. Dsd 256 functions with Hq however to use dsd 512 I had to use Roon only at a step back in sound quality in my experience. 

 

I tried a number of suggestions in the thread to the same result. I finally surrendered it the the fact I was using a Singxer Su1 in the system and that unit requires windows drivers to function at dsd 512. With the Linux based Naa and no ability to house those drivers It seemed unworkable. Long story short, I am left a bit puzzled as the Allo Usbridge(also Linux) functions beautifully at Dsd 512 with Hq player. I had intended to ask @Miska about this as I am hoping to understand what's going on and if it likely the other units gain this functionality at some point. Or if I have missed something else along the way. Have literally tried everything to this point.  

 

Regardless, the Allo Usbridge is operating beautifully as Hq Naa, including Dsd 512 

singxer su1- LKS da004. 

[bibo01]

12 hours ago, Miska said:

 

Is this multi-homed setup perhaps? Also try with IPv6, it usually works better, but make sure it is enabled in the adapter settings (it is enabled by default).

 

Thanks for your reply.

He has solved by removing a VirtualBox network.

[ambre]

On 13-11-2017 at 8:20 PM, Miska said:

 

It doesn't matter. But again, make sure your DAC is not set as default audio device in macOS Audio & MIDI Settings. Set the built-in audio or whatever else as default, as long as it is not the DAC.

 

Otherwise macOS itself may screw up things right away.

 

Thanks for help 

[ambre]

On 13-11-2017 at 10:55 PM, Allander said:

@ambre 

I is point.  

 

Regardless, the Allo Usbridge is operating beautifully as Hq Naa, including Dsd 512 

singxer su1- LKS da004. 

Nice to hear. Hq-player doesn't  support an image but ask Jessy / Miska stated " AFAIK, DietPi comes with networkaudiod, so it should work."  

[Allander]

For any interested, Hq player Naa version 3.5.2 and the updates that came from Sonore, max volume -6db, buffer set to 50ms, Dsd 512 seems to now work flawlessly with both the Micro Rendu and Ultra Rendu. 

@Miska

 

 

[d_elm]

31 minutes ago, Allander said:

For any interested, Hq player Naa version 3.5.2 and the updates that came from Sonore, max volume -6db, buffer set to 50ms, Dsd 512 seems to now work flawlessly with both the Micro Rendu and Ultra Rendu. 

@Miska

 

 

Resolved now but I found support from Signalyst and Sonore dissapointing on this issue.  A problem with software was never acknowledged and @allander was left spinning for months.  Business model I suppose.

[Miska]

On 11/18/2017 at 6:12 PM, d_elm said:

Resolved now but I found support from Signalyst and Sonore dissapointing on this issue.  A problem with software was never acknowledged and @allander was left spinning for months.  Business model I suppose.

 

With my price level, you try the software and see if it works for you... If it doesn't, you don't buy it in first place. Very simple.

 

I don't sell or make any money with any hardware, so I don't provide any hardware support either.

 

[ambre]

On 6-11-2017 at 3:21 AM, Miska said:

 

I suspect some other application or macOS is still messing with the same audio device and that why it goes wrong. And that can happen if the audio device is set as default in macOS settings. So please check that and make sure it is NOT the default device.

 

Dear Jussy,

 

Unfortunately, back again.

Despite the fact that all Audio/ Midi settings for my Mac Mini running HQ-Player and my Mac Mini acting as NAA are set to default output.= display port resp. monitor speakers .   I have again problems with connecting the NAA.

 

Main issues are:

·      Several times push to queue timed out! =>> begin disconnection. Despite the fact I have changed Buffer time form default to 100 ms.

·      Started for example at 352800/32/2 and later for example 192000/32/2. Finally, after several times the NAA started. But buffers of size 58.

·      Stop NAA after restart and after a several “ push to queue timed out” the  NAA started. But buffers size 108.

·      Restarted both HQP-player and NAA buffer etc. Buffers are set to the normal default 512. After..... a quick prayer  , I play for hours !!!

 

Strange behavior isn’t it. In my opinion something changed comparing earlier versions 3.17 <-> 3.18. Or something has changed at release OS High Sierra 10.13.1 approx. 2-3 weeks ago?

 

I find this pretty annoying. Please check this out thoroughly. On request, I can send the log files of HQ-player and the NAA again.

 

In awaiting your reply bets regards,  Andreas from the Netherlands

[Miska]

16 minutes ago, ambre said:

Strange behavior isn’t it. In my opinion something changed comparing earlier versions 3.17 <-> 3.18. Or something has changed at release OS High Sierra 10.13.1 approx. 2-3 weeks ago?

 

When you have audio output on Mac, HQPlayer or NAA doesn't have control over the buffer size. It is decided by CoreAudio on macOS.

 

So it possibly has something to do with macOS changes from Apple or then some other application in the same computer is doing something strange. The CoreAudio code I have in NAA/HQPlayer has not changed in long time, last change was February 2016.

 

Please consider if you've had any other audio related applications on the same computer where NAA is running.

 

Alternatively you could try to dump my NAA image to USB memory stick and boot it up (by holding Alt-key at power up) to get rid of macOS problems. Seems to work on my Mac Mini (apart from Apple keyboard, which is not anyway usually needed). Image package naa-352-x64.7z is here: https://www.signalyst.eu/bins/naa/images/

 

[ambre]

Hi Miska,

 

I am not running  any kind of audio related applications on my Mac Mini HQ-player NOR Mac Mini NAA .

My remark can the new release High Sierra/ CoreAudio causes this  problem?

 

push to queue timed out! =>> begin disconnection.  Is this also managed/decided  by the CoreAudio program too?

 

Is there a possibility to reset by means of PRAM / NVRAM the CoreAudio ?  And should I reset then both Mac Mini's?

 

I am running now my OS from a Sdxh card. If  I dump your X64.7z package on a such SDXH card  will that also possible? And set by default as the  start-up disk? 

Than my Mac Mini will become a headless Windows or Linux  NAA computer only ?  Remarkable

 

Regards, Andreas

[Miska]

47 minutes ago, ambre said:

My remark can the new release High Sierra/ CoreAudio causes this  problem?

 

Possibly...

 

48 minutes ago, ambre said:

push to queue timed out! =>> begin disconnection.  Is this also managed/decided  by the CoreAudio program too?

 

That happens when the audio device (DAC) has not been accepting more data in 10 seconds. IOW, it is stuck. It may also indicate problem with USB, such has faulty or out of spec cable.

 

49 minutes ago, ambre said:

Is there a possibility to reset by means of PRAM / NVRAM the CoreAudio ?  And should I reset then both Mac Mini's?

 

Not sure what that would help...

 

50 minutes ago, ambre said:

I dump your X64.7z package on a such SDXH card  will that also possible? And set by default as the  start-up disk?

 

It could possibly work the same. I never tested that though.

 

50 minutes ago, ambre said:

Than my Mac Mini will become a headless Windows or Linux  NAA computer only ?

 

Yes, you just boot up the image and you are ready to go. It is Linux based.

[scan80269]

On 11/10/2017 at 12:38 AM, Miska said:

Just a short note, there are new bootable images downloadable for BeagleBone Black, RasPi3 and x86-64. The former two work up to DSD256 / 384k PCM for me and the latter of course to DSD512 / 768k PCM.

 

Now root login is enabled and I added alsa-utils, so there's "alsamixer" and such if needed (for adjusting output volume with some portable interfaces etc).

 

The x86-64 image requires modern BIOS capable of UEFI boot.

I got all three bootable images working fine with their respective hardware.  In particular, naa-352 for BBB appears free of functional issues encountered with earlier versions.  Thanks, Miska!

 

Would it be possible to get an naa-352 image for RPi2 also?

 

[Miska]

3 hours ago, scan80269 said:

Would it be possible to get an naa-352 image for RPi2 also?

 

I dropped the older RPi's because they have more challenges managing network + USB simultaneously and as result are not very suitable for use with USB DACs. Those only work OK with the DAC and S/PDIF boards that use the internal I2S straight. Since the RPi's are so cheap, I decided that is better to have the old ones replaced with RPi3 rather than continuing to support the old hardware.

 

Doing and testing each image is quite a bit of effort for me, so I try to minimize the number of images.