Jump to content

Cebolla

  • Posts

    3096
  • Joined

  • Last visited

  • Country

    Ukraine

1 Follower

Retained

  • Member Title
    Cepa Computensis Musicalis

Recent Profile Visitors

13927 profile views
  1. Oops, looks like I just missed this while writing my previous post - glad you've sorted it out!
  2. 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 🙂.
  3. 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.
  4. 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?
  5. 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
  6. 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)?
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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". 😀
  13. Good idea - though not one at a time, ie, make sure you use a list of them so with at least the audio/dsd MIME type always being there - otherwise the DSD transcoder gets used & so you get FLAC files being streamed, not the native DSD files. I've just tested & discovered another 'feature' - if neither one of the audio/dsf and audio/x-dsf MIME types are present then the file name being sent for DSF file streaming by UPnP/DLNA Bridge contains a .dsd suffix, not the expected .dsf suffix!!!! Some players might fail because of this. So to summarise, use the following list of MIME types in the Additional MimeTypes setting to make sure the DSF (& DFF) files get streamed natively & with their correct suffixes: audio/dsd,audio/dff,audio/dsf
  14. Ah that might not look like progress, but at least now the Naim is actually attempting play the dsf tracks being sent by the UPnP/DLNA Bridge. The non playing & skipping to the next track is a tell take sign that the UPnP/DLNA Bridge is for some reason having an HTTP network streaming communication problem with the Naim when attempting to send the DSF file data. The best thing you can do now is to report the issue to the UPnP/DLNA Bridge developer's official thread on the LMS/Squeezebox community forum, who hopefully will come up with a fix: https://forums.slimdevices.com/forum/user-forums/3rd-party-software/100256-announce-upnpbridge-integrate-upnp-dlna-players-with-lms-squeeze2upnp BTW, I have found similar problems testing the UPnP/DLNA Bridge with some players when streaming DSD files, but the same players are fine with the UPnP/DLNA Bridge when streaming PCM files - both JRiver (with UPnP renderer enabled) & foobar2000 (foo_UPnP plugin installed & its UPnP renderer enabled; foo_input_sacd plugin installed for DSD file playing support) have this problem. Other players, eg MPD (UPnP renderer front end provided by upmpdcli), are ok when streaming both DSD & PCM file types with the UPnP/DLNA Bridge.
  15. Don't use Daphile, but when the UPnP/DLNA Bridge 3rd party LMS plugin is used with the standard Logitech Media Server and the UPnP/DLNA Bridge's Codecs settings for the UPnP renderer includes DSD file types, LMS does not give you the options to invoke either of LMS's DoP & DSD to PCM conversion transcoder functions (as FLAC via the DSDPlayer plugin) - your only choice is to stream the DSD files natively. However, the UPnP/DLNA Bridge also needs to recognise the UPnP renderer as supporting DSD file streaming by (specifically) the audio/dsd MIME type, otherwise the DSD file types in the Codecs settings are ignored and the DSD files won't be streamed natively. Unfortunately, it does not recognise any other MIME types that are commonly used by UPnP renderers to indicate DSD file support, such as, audio/x-dsd, audio/dff, audio/x-dff, audio/dsf & audio/x-dsf. This is likely where your problem is - the Naim is not using the audio/dsd MIME type to indicate its support of DSD file streaming and therefore you need to add audio/dsd in its Additional MimeTypes setting in order to get the UPnP/DLNA Bridge to recognise it as supporting DSD file streaming:
×
×
  • Create New...