Cebolla

Oops, just read that the current version of ConvoProxy works as a renderer and not as a media server as I remember! My apologies, please ignore my previous post. May be worth testing with another UPnP/DLNA controller all the same, to make sure that the problem isn't an issue with MinimServer.

Double clicking on the file only tests if the playlist file is configured correctly (& the web radio stream linked to in it is working), not if whatever you've configured ConvoProxy to do with that web radio stream (as linked to by MinimServer) is working & being presented properly to a UPnP/DLNA controller such as JPLAY for iOS. - Have you tested if a UPnP/DLNA controller other than JPLAY for iOS is finding the WAV file stream that ConvoProxy is providing (as a result of it doing whatever you've configured ConvoProxy to do with that web radio stream)? - Have you tested if the JPLAY for iOS app can find that web radio stream itself as actually linked to by MinimServer, ie, not using the ConvoProxy 'middleman'?

Yes, it requires you use specialised software that can capture the PC's audio & buffer it for streaming over the network using one of the 2 network audio streaming protocols supported by the N-50, ie, either UPnP/DLNA or AirPlay. However, bear in mind that the buffering of the computer's captured audio for network streaming adds a 1-2 second delay to the audio that eventually arrives and gets played by the N-50. Also, presumably you are using a Windows PC and not a Mac, as Macs have built-in support for network streaming the computer's audio via AirPlay. Standard UPnP/DLNA media servers, such as MinimServer, don't have the a computer audio capture function - hence the need to use specialised software for this, such as: - SWYH (Stream What You Hear), which uses UPnP/DLNA for streaming; - or TuneBlade, which uses AirPlay for streaming.

Oops, looks like I just missed this while writing my previous post - glad you've sorted it out!

Ok, so you have restricted yourself to using a particular UPnP/DLNA controller app in JPlay for iOS/iPadOS - so preumably you won't be interested in using LMS natively, anyway (LMS also provides the control interface for its native streamers). Incidentally, the JPlay iDevice app isn't just a mere 'UPnP control point' given the main feature of it running its own full blown music management & cataloguing database - a task that most (if not all) other UPnP control point running apps expect the UPnP/DLNA media server application to do instead! Wow - that's some complex, part network/part USB audio connected, multi-device "hub" just to get an audio signal into HQPlayer Desktop! Is it not possible to run a UPnP renderer in the same PC running HQPlayer Desktop and 'simply' capture the UPnP renderer's audio output internally for HQPlayer Desktop, so no need for the input NAA RPi & USB audio connection? Or, if that is not possible, perhaps run a UPnP renderer in Device B instead of Device A, with its output internally captured for the input NAA & no need for the USB audio connection? Also, did you at least explore the alternative of 'just' replacing HQPlayer Desktop with HQPlayer Embedded, so that you can then simply use HQPe's own built-in UPnP renderer for the ideal situation of HQPlayer actually receiving the original audio file tracks, to itself decode & play (never mind no need for external UPnP renderer, USB audio connection & NAA input RPi)? To be clear, the only 'flow' from the JPlay app to Device A UPnP renderer should be UPnP control commands or UPnP info requests. So the actual music file track data flow should be from Qobuz's online server or the UPnP media server directly to Device A UPnP renderer - unless the JPlay iOS app is (unusually for a UPnP controller) for its own reasons acting as the go between & therefore itself running an http server to proxy the music file tracks (do you know if this is the case?). Plus, it's not the actual (audio file) tracks that are being transferred between the UPnP renderer and device B (via USB audio), but the UPnP renderer's continuous audio signal output, produced by the UPnP renderer itself decoding & playing the audio files, that is being transfered and then being sent through the LAN by the input NAA in Device B to HQPlayer Desktop. So a fair amount to consider in order to be confident in that process being bit perfect 🙂.

It's about reliability and features, rather than anything to do with sound quality. As long as a UPnP/DLNA media server is behaving correctly all it should be doing is providing the audio files over the network to the streamer untouched and therefore have absolutely no influence on sound quality - unless your requirement is to alter the files in some way by engaging the UPnP/DLNA media server's transcoder if it has one.

What hardware do you intend to run the UPnP/DLNA media server on? What UPnP streamer(s) are you intending to use the UPnP/DLNA media server with? Are you restricting yourself to using a particular user interface for control (presumably via a UPnP/DLNA controller app) and on what hardware?

The OP is already familiar with Volumio's UPnP/DLNA media server as it's miniDLNA (via plugin). https://community.volumio.com/t/plugin-minidlna/45994 Also, although the Logitech Media Server is highly regarded when operating natively in its primary function as a media server for Squeezebox type streamers, LMS is unfortunately rather buggy when used via Andy Gundman's ancient long unsupported UPnP/DLNA Media Interface plugin which provides its ancillary UPnP/DLNA media server function. For example, see: https://forums.slimdevices.com/forum/user-forums/logitech-media-server/1626974-lms-as-upnp-dlna-server

How do you know if whatever (presumably proprietary) network audio streaming mechanism that the Headless Plexamp (for Raspberry Pi) software uses for obtaining its audio from the Plex Server is bitperfect (like Roons' RAAT is supposed to be)?

For an application not known to support MQA, HQPlayer likely won't have the necessary MQA decoder to be able to truly identify MQA from the played audio file's actual (MQA encoded) PCM signal output. This means that, as @wklie suspects, HQPlayer would instead merely be sourcing the MQA 'identity' for its desktop display from the audio file's tags/metadata.

If you don't mind having the Windows machine running at the same time as you are playing the transcoded multichannel files on the Pioneer LX78, you may be able to save yourself the hassle of having to manually transcode every DSD file & physically storing the resulting FLAC files for later playback by instead using foobar2000 as a proxy server for 'live' transcoding as and when you need it via UPnP/DLNA streaming. However, you first need to test if the Pioneer LX78 is able to play the continuous FLAC file stream that is produced by foobar2000's foo_output_upnp plugin, as some UPnP renderers don't support playing FLAC file streams that don't have a defined length.

Not only is Spotify currently a lossy online music service, it also supplies a range of audio quality streams: https://support.spotify.com/us/article/audio-quality/ Has the A95k TV's Spotify app got a setting that allows you to change the audio quality? - If so, is it set to the highest possible quality? - if not, how do you know what quality of audio streams the Sony TV's Spotify app is receiving? Worst case, assuming you are using a Spotify Premium account, the difference in audio quality could be due to rather poor (Spotify Low quality) 24kbps lossy audio streams being played by the Sony Bravia A95k TV compared to good almost CD quality (Spotify Very high quality) 320kbps lossy audio streams being played by the Apple TV.

The Aavik S-280 is using a Conversdigital mconnect streamer board which can only be controlled by Conversdigital's mconnect Control (aka Mcontrol) series of apps, not Conversdigital's mconnect Player series of apps (which are for controlling Chromecast devices & standard UPnP renderer containing streamers such as your Sonore & Briscati). See: https://www.audiophilia.com/reviews/2022/6/9/ijrv97bybjaybjn7uaq6smcvox0ppn https://conversdigital.com/eng/product/product03.php This also means that the Aavik control app is a branded version of the mconnect Control HD app, not the mconnect Player HD app. Hence you were not using the same app in your own tests.

Your're right - apologies to my fellow hobbyists. Plenty of more important things going during these holidays to merit getting riled about yet still wish everyone peace.

I wouldn't be confident in audiophiles even understanding what network streaming audio file tracks actually is, given the amount of nonsense statements that come from some of them - the ones that regard the network audio file streaming process prior to the audio file tracks arriving & being played by their devices as somehow being part of their audio system's playback chain. Give those audiophiles the knowledge for the potential of audio files being resampled at various stages of network streaming and you'll be encouraging a whole new set of nonsense statements. Or, perhaps that's what you mean by it being "probably of little use". 😀