I’m giving studio another try but am already having issues with drops etc using ropiee
Current setup is:
MacBook Pro M1 >> WIFI >> Pi5 Ropiee >> USB >> Quad 3 Integrated amp
Is there anything that works well with Audirvana for UPnP on a raspberry Pi
I did try installing Audirvana on an Intel NUC and using the remote but just couldn’t get on with the small window size.
My recommendation is to forget UPnP and install Audirvāna on the small form-factor macOS, M4 Mac mini with a lot of RAM using a locally attached SSD library or NAS library, using Apple Remote Desktop from your MBP or via the iPad Audirvāna Remote app.
Or… Screen sharing:
Considering how many people have problems with UPnP I would also recommend direct USB output. The easiest solution might be USB out from your MBP M1 and Audirvana remote with iPad to get a bigger window size.
You problem experience networking problems, which means that using other software on the Pi won’t be a fix.
Recommendation: send an e-mail to [email protected]
They will probably instruct you to start some logs from within the Audirvana software and send the output to them, but that’s the only way to get it solved.
If you don’t want that: hook up your MacBook with a USB cable to your amplifier.
Laptop is too far from the amp to run a USB cable and I know it’s not a networking issue.
I’m not buying a Mac mini just to run Audirvana let alone using the clunky Remote Desktop app.
Don’t understand why it can’t support UPnP, I’ve tried it with several streaming amps like Devialet and Plinius plus god knows how many UPnP renderers/endpoints and nothing seems stable.
I’m using Roon which is rock solid but doesn’t sound anywhere near as good. Even the Innuos streamers I’ve had worked with UPnP ok.
Is using an ethernet cable instead of WiFi an option? It made all the difference for me.
And rebooting router from time to time helped as well.
I have zero issues with Chord Electronics 2Go/2Yu (Streamer/Bridge) combinations attached to my main system and a pair of KEF LS50’ Wireless II. Not cheap but have had zero playback issues with them for coming up to 2 years. My main system and KEF’s are located near to wireless routers so I connect each of the 2Go/2Yu (streamer / bridge) via ethernet to the routers. My laptop connects to the network over wireless. In this configuration streaming up to 768 KHz pcm or DSD 256 is flawless as stated.
On my main system I use USB out of the 2Go/2Yu to a Chord DAC, Amp, and B&W speakers. I use coax out for the KEF speakers
The KEF speakers also suffer no playback issues however for an unknown reason the last track in a play queue often fails, despite playing normally, to be recorded as played. This has never occured when using a 2Go/2Yu feeding them.
I would only recommend the 2Go/2Yu combo over Ethernet. The wireless connection is only 2.4 GHz band so can suffer from interference if your WiFi is subject to overcrowding.
Ok, have it your way. Good luck
Roon uses a proprietary transmission protocol ‘RAAT’ (Roon Advanced Audio Transport) that requires symbiotic RAAT endpoints, which provide feedback information about the status of the endpoint(s) which is a form of error-correction… UPnP provides no form of error-correction and there is no standardization beyond the primary protocol framework.
The reason the Audirvāna sound quality is superior, is because of the streamlined architecture of the audio-engine, which is not burdened by unnecessary computational overhead found in other playback systems and in its exploitation of the power of a properly configured computer/OS platform.
UPnP transmission protocol is about as bare-bones as can be employed, however, because of inconsistencies in platform to platform implementation(s), a user must design a network distribution scheme that is as simple as possible… A simple single-path Ethernet transmission scheme with no other traffic on the signal-path, or intermediary components (routers and switches) in the signal-path is optimum, providing the best possible signal flow. In concert with a simple transmission scheme, attention to the electro-mechanical power/ground/earthing and RF and EMF potentials that can and will corrupt the signal along the transmission path, is essential because Ethernet protocol and UPnP do not provide error-correction of the packetized digital-audio signal.
For example: Computer → Ethernet (copper or optical) → DAC.
The list below is the best reference for UPnP qualified playback devices compatible with Audirvāna, but even this is not a guarantee that any given device will provide reliable UPnP playback on any given network transmission scheme, due to the subjective nature of network architecture design and implementation in any given subjective playback environment.
I see folks spending large sums of money on building-out complex network schemes, where the simple implementation of a DAC connected directly to a M4 Mac mini (USB or Ethernet) running Audirvāna with a locally attached Library or NAS Library is the most reliable playback scenario, in concert with the Audirvāna iOS Remote running on an iPad. (This includes other similar playback platform/OS scenarios using this strategy) This Mac mini can also be employed in a wider LAN UPnP transmission scheme to other devices supporting UPnP, when attention to electro-mechanical potentials is properly addressed.
UPnP protocol is not equal to RAAT, Ravenna, Dante or AVB protocol(s) among other IP based digital-audio transmission protocols.
As friend @Amarok1969 mentions, do you happen to have a wired Ethernet connection you could use? That was definitely more reliable than Wi-Fi for me.
If you wanted to switch from Ropiee, I’m aware of 3 things you could try: Volumio; Moode; or install Raspbian and then install and configure mpd and upmpdcli yourself. The latter is obviously more learning and more work, though it also gives you more control.
I haven’t done any of these; I’ve got a Fitlet3 with a minimal Arch Linux install running mpd and upmpdcli as my UPnP endpoint connected by optical Ethernet , and that is rock solid. Other than a couple of Arch upgrades that broke things until I was able to figure out a fix (literally a couple over the course of two years), besides the ISP having an outage I can’t remember when I last had a dropped connection. But that’s quite different than your setup and changing it so drastically may be impossible or a level of inconvenience you don’t want to take on.
I was hoping you would add some perspective…
I have a question… Why are you not just running Audirvāna Core on this IoT device and connecting direct to your DAC and using Audirvana Remote, eliminating a UPnP network connection ?
Never had UPNP issues so far … and I’m using it since ten years more or less.
And I successfully helped a lot of friends to setup upnp environments …
Volumio is not a stable end point with Audirvana. Not that it has interruptions, but the Volumio end point disappears from the list of outputs in Audirvana after inactivity. You have to switch the UPnP option in the Volumio settings off and on again to make it reappear.
This is a known issue by both Volumio and Audirvana, and it is Audirvana that has something to do.
Thanks for the info. As I noted in my comment, I haven’t tried Volumio, Moode, or Raspbian myself so it’s good to get information from users’ experiences.
Devices like the Fitlet3 are small, fanless, inexpensive, with relatively low powered CPUs. The low acoustic and electronic noise suits them perfectly as UPnP endpoints, helping to assure minimum electrical noise getting to the DAC PHY and clock and thus low jitter.
Meanwhile, back in my office I can have a powerful general purpose desktop computer able to easily do my preferred upsampling to DSD512, and I don’t have to worry about minimizing acoustic and electrical noise. I also have storage for my local music connected there.
A directly connected server of the requisite speed, power, and storage capacity, but fanless with minimal electrical noise, would cost perhaps 5-10x as much as my endpoint, desktop, and storage combined, as well as its size and appearance causing problems with Spouse Acceptance Factor in the living room. 
If we were to compare a cost/performance playback scenario using the small form-factor and powerful, M4 Mac mini in its basic configuration ( Height: 2.0 inches (5.0 cm) Width: 5.0 inches (12.7 cm) Depth: 5.0 inches (12.7 cm) with your DAC and library locally attached, juxtaposed to your playback system architecture, including your computer platform(s). What would the price tag of your system amalgamation look like?
The argument regarding ‘fan noise’ is hinged on the thermal management scheme employed by the platform… In the case of Apple computer platforms the thermal management scheme is a very sophisticated architecture, ultimately employing a very specific mag-lev fan mechanism… Do you think by now in the evolution of the high-performance Apple ‘M’ series platforms, that the Apple engineers do not understand the nature of noise on the performance of the platform architecture? Generally acoustically, I sit two-feet from my M2 Max Mac Studio and about five-feet from it when I am critically listening to music and I have never heard noise coming from the platform… except for the start-up chimes when booting the computer. So, in the case of the M4 Mac mini, the potential influences on sound-quality performance by the employment of the sophisticated mag-lev cooling-fan design in the thermal management scheme is moot and inconsequential in the Audirvāna playback scenario…
With my DAC the M4 Mini would allow DSD256 over USB. On sale for Christmas season it would be a little less than $100 above what I spent for the Fitlet3 with optical Ethernet input. Of course I would still need the general purpose computer in my office.
So I could have DSD256 for ~$100 more than I’ve paid for DSD512.
So the $100 differential is fundamentally a subjective decision, in the context of native DSD256 sound-quality versus the modulated (up-sampled) DSD512 iteration…
It is hard to imagine that generally, a $300 Fitlet 3 employed in an amalgamated UPnP network playback scenario does not cost more to design and implement and provide a better overall performance quality, than a much simpler local employment of the M4 Mac mini…
Perhaps there’s an M4 in your future. Enjoy your listening!
Don’t need it… But for those considering a complex networked UPnP playback system, the locally attached M4 Mac mini brings a lot to the table in addition to a very reliable and hassle-free playback experience, when looking at the overall costs versus performance elements.