Solved? "Roon has lost control of the audio device"

I've had an ongoing issue with Roon stopping mid-song after ~45 mins with "Roon has lost control of the audio device". I've tried timing it and it's not exactly 45min like 44:38, etc. I'm running Roon Core on my M1 iMac. Also, running is HQ Player 5.5.1. The NAA is 4.5v and is on my SoTM SMS200 Ultra Neo firmware. All this is connected to a Chord Hugo TT2 via USB. I run only PCM (Chord doesn't do DSD natively) and only to 706.5/768. This issue has gone on for year or so. I'm not sure when it started doing this.

 

I've tried a lot of fixes and posted HQ logs here in the main HQP forum a couple of Times. No real smoking guns there. MIska said he suspected it was DHCP issues.

 

I've tried things with DHCP on, off, static IP, etc. And still would see these halts. The halts just stop and do not reconnect unless I manually go into Roon and restart things. I don't always listen for longer than 45 mins, so it's tough to "test" any fixes. However, I did test simply outputting via Roon not using HQP and I did not have the issue then.

 

Yesterday, I put in 100ms buffer in the HQP Preferences "Buffer Time" setting. This did make a change for the better - the music stopped about 90 mins in and only for a second and restarted on it's own. I kept the music running and it did this a second time, but for even shorter time stopped and instantly restarted.

 

This seems to be on the right track to solve the issue... but is it?

I have the very same issue (but different setup : Roon core on NUC, HQPlayer on iMac 27", network streamer Allo USBridge Sig connected via USB to HOLO MAY. All network is cable connected, no wifi).

 

It all plays great, but after 45 odd minutes, Roon goes into pause and "Roon lost control of the Audio Device".

Then, sometimes just need to press play again for the music to flow, sometimes need restarting Roon remote on iPad.

I tried raising the buffer time to 250, but to no avail.

Very frustrating ...

Did you find a fix?

Any hint from @Miska ?

 

22 hours ago, marcosax said:

I have the very same issue (but different setup : Roon core on NUC, HQPlayer on iMac 27", network streamer Allo USBridge Sig connected via USB to HOLO MAY. All network is cable connected, no wifi).

 

It all plays great, but after 45 odd minutes, Roon goes into pause and "Roon lost control of the Audio Device".

Then, sometimes just need to press play again for the music to flow, sometimes need restarting Roon remote on iPad.

I tried raising the buffer time to 250, but to no avail.

Very frustrating ...

Did you find a fix?

Any hint from @Miska ?

 

 

Do you have flow control enabled on your network?

thanks @jcn3 for your hint.

I didn't know of Flow Control, so I looked in System Preferences and found the current settings:

 

 

 

Flow Control shows up as an option if I choose Configure: Manually, as in this screenshot:

Can you suggest best settings ?

 

I can add that if in ROON Remote I choose my HOLO MAY as audio device (hence bypassing HQPlayer)  I get flawless play for hours with no stops (or dropouts)

 

35 minutes ago, marcosax said:

thanks @jcn3 for your hint.

I didn't know of Flow Control, so I looked in System Preferences and found the current settings:

 

 

 

Flow Control shows up as an option if I choose Configure: Manually, as in this screenshot:

Can you suggest best settings ?

 

I can add that if in ROON Remote I choose my HOLO MAY as audio device (hence bypassing HQPlayer)  I get flawless play for hours with no stops (or dropouts)

 

 

The place to look is on your router, not your Mac.  I'd leave your Mac as is.

@jcn3, my router is a Vodafone Powerstation / Vox30  https://openwrt.org/toh/vodafone/vodafone_power_station

 

Unfortunately, I can't find anything resembling Flow Control in its settings (in advanced mode).

The Powerstation works as a DHCP server, with several IP reservations for each device.

 

The Powerstation is directly connectedfrom one of its LAN output to the iMac running HQPlayer. 

From another LAN outlet another wire goes from the PowerStation to Apple Airport Extreme, this is in bridge mode, working basically as a LAN switch, feeding the wired connection to the house (through another three Ethernet unmanaged switches) and also generating wifi ( 5 and 2.4 GHz).

 

I don't know if this gives you any hint on what's causing the problem, which started happening a few HQPlayer and Ropieee update ago. Before all was working great.

Please note that if I switch to HOLO audio device in Roon, which is on the same wired network but bypasses the iMac with HQPlayer, everything works as expected.

 

5 hours ago, marcosax said:

 

Can you suggest best settings ?

 

The last one... But what ever the AVB/EAV mode does, it is not necessary. But it is not necessary to manually configure this, Mac will automatically use flow control on and EEE on the network when available (this is negotiated at ethernet hardware level).

 

On 9/14/2024 at 8:47 PM, marcosax said:

I have the very same issue (but different setup : Roon core on NUC, HQPlayer on iMac 27", network streamer Allo USBridge Sig connected via USB to HOLO MAY. All network is cable connected, no wifi).

 

It all plays great, but after 45 odd minutes, Roon goes into pause and "Roon lost control of the Audio Device".

Then, sometimes just need to press play again for the music to flow, sometimes need restarting Roon remote on iPad.

I tried raising the buffer time to 250, but to no avail.

Very frustrating ...

Did you find a fix?

Any hint from @Miska ?

 

Allo is based on old RPi3 which can be tricky. Which version of NAA is this? What is the error shown in HQPlayer logs?

 

Default buffer time should be fine, for some tricky devices, you could try for example 10 ms to see if it makes difference. But first and foremost the important thing is to check whether this problem is between Roon and HQPlayer or HQPlayer and the endpoint.

 

One known potential source of problems is jumbo frames, but it shouldn't be in use unless specifically configured.

 

Regarding switches, just some regular unmanaged should do as long as it supports 802.3x, 801.2p and potentially 802.3az. If router is suspected, then placing such switch in front of the router can help. Thus the router would connect to the switch with one cable for internet access, and everything else would connect to the switch.

 

3 minutes ago, Miska said:

 

Allo is based on old RPi3 which can be tricky. Which version of NAA is this?

 

 

Ropieee always updated to the latest rel., a version specifically written for Allo by the Ropieee author

 

3 minutes ago, Miska said:

 

What is the error shown in HQPlayer logs?

 

+ 2024/09/14 01:30:54 NAA output network engine started at: 1536000

# 2024/09/14 01:48:08 NAA output network timeout

! 2024/09/14 01:48:08 NAA output clNetEngine::PushPCM(): clNetEngine::SendStreamPCM(): clSemaphore::Wait() (19217)

! 2024/09/14 01:48:08 clHQPlayerEngine::Execute(): push to FIFO failed

2024/09/14 01:48:08 Stop request (reset)

- 2024/09/14 01:48:08 Playback engine stopped

& 2024/09/14 01:48:08 Stop...

& 2024/09/14 01:48:08 ...stopped

2024/09/14 01:48:08 Set volume: -3 +

~ 2024/09/14 01:48:08 Adaptive transport gain: 0 dB (1)

- 2024/09/14 01:48:08 Control ended from 10.0.1.21:40870

2024/09/14 01:48:09 NAA output network Audio IPv6 support disabled

2024/09/14 01:48:09 NAA output discovery from 0.0.0.0

& 2024/09/14 01:48:09 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210

2024/09/14 01:48:10 NAA output discovered 1 Network Audio Adapters

+ 2024/09/14 01:48:10 NAA output connect to 10.0.1.50:43210 [ipv4]

# 2024/09/14 01:48:10 NAA output clNetEngine::Connect(): initialize: clALSAEngine::Initialize(): snd_pcm_open(): Device or resource busy

2024/09/14 01:48:11 NAA output network Audio IPv6 support disabled

2024/09/14 01:48:11 NAA output discovery from 0.0.0.0

& 2024/09/14 01:48:11 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210

2024/09/14 01:48:12 NAA output discovered 1 Network Audio Adapters

+ 2024/09/14 01:48:12 NAA output connect to 10.0.1.50:43210 [ipv4]

# 2024/09/14 01:48:12 NAA output clNetEngine::Connect(): initialize: clALSAEngine::Initialize(): snd_pcm_open(): Device or resource busy

2024/09/14 01:48:13 NAA output network Audio IPv6 support disabled

2024/09/14 01:48:13 NAA output discovery from 0.0.0.0

& 2024/09/14 01:48:13 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210

 

3 minutes ago, Miska said:

 

Default buffer time should be fine, for some tricky devices, you could try for example 10 ms to see if it makes difference. But first and foremost the important thing is to check whether this problem is between Roon and HQPlayer or HQPlayer and the endpoint.

 

don't know how to find this put ...

 

3 minutes ago, Miska said:

One known potential source of problems is jumbo frames, but it shouldn't be in use unless specifically configured.

 

 

never heard of it and definitely didn't consciously turned it on ... :)

I pasted the last lines from the HQPlayer log, window which I left open when pause occurred.

 

 

9 minutes ago, marcosax said:

# 2024/09/14 01:48:08 NAA output network timeout

! 2024/09/14 01:48:08 NAA output clNetEngine::PushPCM(): clNetEngine::SendStreamPCM(): clSemaphore::Wait() (19217)

! 2024/09/14 01:48:08 clHQPlayerEngine::Execute(): push to FIFO failed

 

OK, so NAA has stopped responding.

 

9 minutes ago, marcosax said:

# 2024/09/14 01:48:10 NAA output clNetEngine::Connect(): initialize: clALSAEngine::Initialize(): snd_pcm_open(): Device or resource busy

 

And now either the NAA process is frozen with the device open. Or some other process has stolen the audio device meanwhile.

 

Just to check, you have remembered to disable this endpoint/DAC under Roon Settings / Audio? (see last bullet point here)

 

Now log from NAA side would help figuring out what is going on.

 

I think you just found it!

Do you mean I have to disable this and re-enabling it when I want to listen directly to HOLO?

 

6 minutes ago, marcosax said:

I think you just found it!

Do you mean I have to disable this and re-enabling it when I want to listen directly to HOLO?

 

 

Yes, otherwise Roon will try to mess with the device while HQPlayer is using it. This is most typical problem to happen with Roon + HQPlayer combination.

 

I knew you would have spotted the problem stright away... (and probably discussed already many times)

Thank you!

The Roon Bridge software module shouldn't be even running at the same time with NAA software module at the endpoint. Many endpoint OS make sure this is the case. Usually you would switch the endpoint mode through the endpoint's web interface or similar and only one is ever running at a time.

 

@Miska, it's happened just now, even if I disabled the HOLO audio device. But I did it while music was playing. 

I better quit and restart Roon and HQPlayer and try again

Next thing would be to check what the NAA software (networkaudiod) says at the NAA side when the issue appears.

 

5 minutes ago, Miska said:

The Roon Bridge software module shouldn't be even running at the same time with NAA software module at the endpoint. Many endpoint OS make sure this is the case. Usually you would switch the endpoint mode through the endpoint's web interface or similar and only one is ever running at a time.

 

hang on,  HQPlayer runs on my iMac.

What you say is I canNOT have Roon player running at the same time on the same iMac working as a remote, like  my iPhone or iPad, to select, read info and play music from the NUC (Roon core) ?

8 minutes ago, marcosax said:

hang on,  HQPlayer runs on my iMac.

What you say is I canNOT have Roon player running at the same time on the same iMac working as a remote, like  my iPhone or iPad, to select, read info and play music from the NUC (Roon core) ?

 

Sure, you can have Roon running on the same machine with HQPlayer. And you have likely set HQPlayer address as "localhost" or "127.0.0.1" in Roon. I had full desktop Roon and HQPlayer running side by side on iMac for many years. Now Roon runs on it's own dedicated NUC (Debian 12 as OS).

 

But Roon and HQPlayer cannot be configured to use the same DAC as output device at the same time. And with Roon it doesn't matter which zone is active, what matters is what is enabled under Roon Settings / Audio as output zones.

 

At endpoint (NAA) side, there shouldn't be multiple pieces of endpoint software running simultaneously. So Ropieee shouldn't have both Roon and HQPlayer endpoint software running simultaneously.

 

first off, thank you @miska for your patience and will to help.

 

2 minutes ago, Miska said:

 

Sure, you can have Roon running on the same machine with HQPlayer.

 great!

2 minutes ago, Miska said:

 

 

And you have likely set HQPlayer address as "localhost" or "127.0.0.1" in Roon. 

 

now i understand the lines in the log:

2024/09/16 00:41:18 Network interfaces:

2024/09/16 00:41:18 if[en0] ipv4=10.0.1.9 ipv6=fe80::cd:6302:96d0:fa5a%en0 idx=4

2024/09/16 00:41:18 if[en1] ipv4=10.0.1.28 ipv6=fe80::183d:e018:5cec:8e91%en1 idx=5

2024/09/16 00:41:18 if[lo0] ipv4=127.0.0.1 ipv6=::1 idx=1

 

2 minutes ago, Miska said:

 

But Roon and HQPlayer cannot be configured to use the same DAC as output device at the same time. And with Roon it doesn't matter which zone is active, what matters is what is enabled under Roon Settings / Audio as output zones.

 

At endpoint (NAA) side, there shouldn't be multiple pieces of endpoint software running simultaneously. So Ropieee shouldn't have both Roon and HQPlayer endpoint software running simultaneously.

 

 

so, by disabling HOLO in Roon as Audio Device (which I just did and restarted Roon and HQPlayer, and now Eric Clapton is playin), everything should play smoothly, do I understand correctly?

8 minutes ago, marcosax said:

so, by disabling HOLO in Roon as Audio Device (which I just did and restarted Roon and HQPlayer, and now Eric Clapton is playin), everything should play smoothly, do I understand correctly?

 

Should yes... If this is not the case, next step would be to check NAA side logs to figure potential reasons why things go wrong.

 

There are also other possible external reasons, such as antivirus trying to scan the audio stream for viruses like Windows Defender likes to do sometimes. Of course the amount of data is ever growing...

 

You can also smooth out the Roon's awkward HQPlayer controlling behavior by setting "Idle time" in HQPlayer for example to 30 seconds. This reduces amount of stream restarts significantly, and helps reducing Roon - HQPlayer interaction delays in many cases.

 

and it just happened again! music paused just now.

with HOLO disabled in audio settings-

 

In Ropieee web interface, among services, only HQPlayer NAA is enabled, with service name %h [RoPieeeXL]

 

I don't know where else to look, seems beyond my capabilities

 

running on a Mac, I don't have any antivirus...

 

check NAA side logs, I don't know how to do it...

 

 I just set "Idle time" for HQPlayer to 30 sec.

 

Pressing Play again and wait to see if it's happening again ...

 

If you need the log let me know, me I don't know how to read it ...

 

 

4 minutes ago, marcosax said:

check NAA side logs, I don't know how to do it...

 

I know nothing about Ropieee, I have never used it. But typically "journalctl -u networkaudiod" would do it if it's systemd-based Linux distro.

 

If you have spare Raspberry Pi4 that you could boot with my NAA OS image, it could be tested in place of your current NAA. If some other NAA works, then you know it is the particular NAA, either hardware or software. If it has the same problem, then you known it is a network problem. (some regular PC hardware would also do, for booting NAA OS or HQPlayer OS from USB memory stick)

 

3 minutes ago, Miska said:

 

I know nothing about Ropieee, I have never used it. But typically "journalctl -u networkaudiod" would do it if it's systemd-based Linux distro.

 

It is Linux-based, it's me who don't  have a clue where to input that command line ... 

 

3 minutes ago, Miska said:

If you have spare Raspberry Pi4 that you could boot with my NAA OS image, it could be tested in place of your current NAA. If some other NAA works, then you know it is the particular NAA, either hardware or software. If it has the same problem, then you known it is a network problem. (some regular PC hardware would also do, for booting NAA OS or HQPlayer OS from USB memory stick)

 

 

I don't have other Raspberry Pi4 to test, and no PC hardware neither. 

I'm a long time Mac user, for work  and leisure,  but I have no knowledge of networks or programming.

I decided to use my Mac hardware to run HQPlayer in my audio setup because it sounded straightforward and I read of all the  benefits.  I love music and I like to listen to it in the the best way I can. 

But I can't invest such a large amount of time to learn and bcome expert in new topics to me, like networking, protocols and such, just  to be able to run a piece of software.

Particularly because everything was working flawlessly until a few updates back (HQPlayer, Ropieee, MacOs, who knows which one caused it?).

As of now, Eric has played for 22 minutes, and just stopped at 01:49 am:  these are the lines from the log from that time on;

 

+ 2024/09/16 01:27:56 NAA output network engine started at: 1536000

# 2024/09/16 01:49:58 NAA output network timeout

! 2024/09/16 01:49:58 NAA output clNetEngine::PushPCM(): clNetEngine::SendStreamPCM(): clSemaphore::Wait() (24605)

! 2024/09/16 01:49:58 clHQPlayerEngine::Execute(): push to FIFO failed

2024/09/16 01:49:58 Stop request (reset)

& 2024/09/16 01:49:58 Stop...

- 2024/09/16 01:49:58 Playback engine stopped

& 2024/09/16 01:49:58 ...stopped

2024/09/16 01:49:58 Set volume: -3 +

~ 2024/09/16 01:49:58 Adaptive transport gain: 0 dB (1)

- 2024/09/16 01:49:58 Control ended from 10.0.1.21:50718

2024/09/16 01:49:59 NAA output network Audio IPv6 support disabled

2024/09/16 01:49:59 NAA output discovery from 0.0.0.0

& 2024/09/16 01:49:59 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210

2024/09/16 01:50:00 NAA output discovered 1 Network Audio Adapters

+ 2024/09/16 01:50:00 NAA output connect to 10.0.1.50:43210 [ipv4]

# 2024/09/16 01:50:00 NAA output clNetEngine::Connect(): initialize: clALSAEngine::Initialize(): snd_pcm_open(): Device or resource busy

2024/09/16 01:50:01 NAA output network Audio IPv6 support disabled

2024/09/16 01:50:01 NAA output discovery from 0.0.0.0

& 2024/09/16 01:50:01 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210

2024/09/16 01:50:02 NAA output discovered 1 Network Audio Adapters

+ 2024/09/16 01:50:02 NAA output connect to 10.0.1.50:43210 [ipv4]

# 2024/09/16 01:50:02 NAA output clNetEngine::Connect(): initialize: clALSAEngine::Initialize(): snd_pcm_open(): Device or resource busy

2024/09/16 01:50:03 NAA output network Audio IPv6 support disabled

2024/09/16 01:50:03 NAA output discovery from 0.0.0.0

& 2024/09/16 01:50:03 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210

2024/09/16 01:50:04 NAA output discovered 1 Network Audio Adapters

+ 2024/09/16 01:50:04 NAA output connect to 10.0.1.50:43210 [ipv4]

# 2024/09/16 01:50:04 NAA output clNetEngine::Connect(): initialize: clALSAEngine::Initialize(): snd_pcm_open(): Device or resource busy

2024/09/16 01:50:05 NAA output network Audio IPv6 support disabled

2024/09/16 01:50:05 NAA output discovery from 0.0.0.0

& 2024/09/16 01:50:05 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210

2024/09/16 01:50:06 Set convolution: overlap-add

& 2024/09/16 01:50:06 GoTo 1

& 2024/09/16 01:50:06 Play

# 2024/09/16 01:50:06 clMainWindow::trackSelected(): clHQPlayerEngine::GoTo(): clHQPlayerEngine::Play(): clStreamReaderHTTP::clStreamReaderHTTP(): clStreamReaderHTTP::GetHead(): 404

2024/09/16 01:50:06 NAA output discovered 1 Network Audio Adapters

+ 2024/09/16 01:50:06 NAA output connect to 10.0.1.50:43210 [ipv4]

# 2024/09/16 01:50:06 NAA output clNetEngine::Connect(): initialize: clALSAEngine::Initialize(): snd_pcm_open(): Device or resource busy

2024/09/16 01:50:07 NAA output network Audio IPv6 support disabled

2024/09/16 01:50:07 NAA output discovery from 0.0.0.0

& 2024/09/16 01:50:07 NAA output discovered network audio: name='ropieee [RoPieeeXL]' version='Signalyst Network Audio Daemon 5.0.1' @10.0.1.50:43210