Probably not directly, as you would need to be able to pass your 4 DACs through to the HAOS VM, and then HA would also need to be able to make use of local devices if it could see them. It’s a lot of hurdles trying that way.
You might however have more luck exposing your 4 DACs as DLNA/uPNP renderers using some server application. Music Assistant already supports UPNP/DLNA renderers as player providers.
JRiver Media Center on Windows is able to expose an audio device through DLNA/UPNP. You can create a zone for it, and assign an audio device. Music Assistant will see it.
I just tried it myself, and that’s as far as it goes, though. I am unable to select the JRiver DLNA player, even though it shows up in the list. It could be some compatibility issue, or possibly something to do with the fact that it’s a 7.1 device rather than 2.0 . I’m using an ECHO Audofire 8a on my desktop. It’s not on the same host that runs my HAOS VM, but that doesn’t matter.
The Audiofire 8a also has a stereo mode of operation where it will expose four 2.0 devices, like your 4 DACs presumably are. I just tried changing it to that mode. The first (default) zone got changed from 7.1 (it’s actually a 4.1 setup using the first 6 channels) to 2.0 . And I created a separate zone for ouputs 7-8 . Those outputs go to zone 2 of my Yamaha AVR, and power speakers above the digital organ. So it’s really a physically separate zone.
Both the JRiver main zone and the JRiver organs zone showed up in the player list in Music Assistant. That’s the good news.
However, I encountered multiple problems :
-
the main zone player (HIGGS:HIGGS) has the name dlna-xxxx and isn’t recognized as a DLNA renderer. I cannot edit the player settings in MA
-
While I am able to select this HIGGS:HIGGS player for playback in MA, when I start playing, I get the following error :
-
the organ zone player shows up correctly as a renderer in MA, and I can edit its settings, including disabling volume normalization . When I start playing back media, i don’t get an error, but I also don’t get any sound, and the transport stays at 0:00 .
The good news is MA is definitely communicating with JRiver over DLNA .
Here is the MA side :
And the JRiver side :
Notice how they are both showing the same media/track.
I believe there may be some settings I’m missing on either the JRiver or MA side, and there could be a bug or two that needing fixing on either or both sides. DLNA is apparently a fairly loosely defined protocol, and I have seen many problems between players, controllers and servers.
BTW, most of the zones you see in my JRiver screenshot on the left aren’t powered by any PC. They used to consist of Chromecast audio, attached to very old AVRs with 7.1 analog inputs, that I basically got for free - pre-HDMI, non-networked models. But which sound great and without any processing on those inputs. The volume is set at 0 dB on every receiver, and never changes. They all stay on the multi-channel input, also. There are smartplugs and automations to turn the amps on or off since they can use a lot of power even when idle.
The CCAs didn’t have Ethernet, so I added a USB OTG / Ethernet NIC to each CCA. That made the cost about $50 per zone between the CCA and NICs. Amps were free and already there anyway, and speaker wire. Most of the speakers came built-in with the house
CCA were very flawed devices, though. In particular lack of gapless support. Roon supported it, but I didn’t like their approach or the price. Very glad to see that Music Assistant supports gapless with CCA now. 12 of my CCAs have been replaced with WiiM Pro Plus last year. They expose CCA, Airplay2 and DLNA interfaces. JRiver shows the WiiM DLNA renderers since it doesn’t support Google Cast or Airplay. I still have 5 cast devices though, 2 CCAs, 1 CC ultra, 2 CCwGTV.