Cebolla

  • Content count

    1,720
  • Joined

  • Last visited

About Cebolla

  • Rank
    Cepa Computensis Musicalis
  1. Messi's never scored against Chelsea (8 Champions League matches) and he's had plenty of incentive, not least the jeering of the Chelsea fans. Some things are just never meant to be: https://www.youtube.com/watch?v=ckfAtBoIJ1E Hopefully the gods will set up another 'CL Clasico' with Chelsea's return next season - can't wait to see him messi-it up yet again! https://www.youtube.com/watch?v=Aq9waHBArdo
  2. Yes, you can change the foobar2000 renderer's default network name in fb2k's configuration/preferences: Tools>UPnP>Server>Basic Settings Change the bottom (Media Renderer) Network name, not the top (Media Server) Network name. Also, since you are not using foo_UPnP's UPnP/DLNA media server, you may as well switch it off by pressing the (top) Stop Server button. Perhaps the problems you found with Linn Kazoo is that it only supports OpenHome renderers, ie, it doesn't support standard UPnP/DLNA renderers.
  3. Hi Paul The excellent free foobar2000 audio file player can be turned into a standard UPnP/DLNA renderer with the addition of the foo_UPnP plugin component. The foobar2000 foo_UPnP renderer uses the same audio output engine as its built-in audio file player, allowing you to configure the Windows audio output device for it and any choice of DSP settings as required. foobar2000 for Windows foo_UPnP - UPnP/DLNA Renderer, Server, Control Point Since Linn's Kinsky is a control point for both standard UPnP/DLNA renderers and OpenHome (aka UPnP with Linn extensions) renderers, an alternative would be to install OpenHome.org's own OpenHome renderer, OpenHome Player: OpenHome Player for PC OpenHome renderer emulation can be provided via the BubbleUPnP Server application, by using its Create OpenHome renderer function for any standard UPnP/DLNA renderer, such as foobar2000 foo_UPnP renderer: BubbleUPnP Server - Creating OpenHome renderers Incidentally, what device are you running the Kinsky controller on and what is your reason for using it in the first place? It has a reputation for being buggy with many standard UPnP/DLNA renderers (eg pause, track position, next/prev track, volume control may not work properly or not at all). Also, although it doesn't have those problems with OpenHome renderers, it lacks support of the full range of OpenHome functions. In fact Linn very rarely bug fix/update Kinsky and advise you to use the alternative well supported Linn Kazoo for controlling OpenHome renderers instead. John
  4. Hi Louise The BubbleUPnP Server acts as a proxy when being used for its OpenHome Streaming Services function, used for accessing online music services such as TIDAL. This means your Marantz streamer will be obtaining the TIDAL audio stream via BubbleUPnP Server, rather than directly from TIDAL's online server. Note, this proxying of the original audio stream does not occur when using its created OpenHome renderer with a UPnP/DLNA media server (such as MinimServer) for streaming your own audio files. The TIDAL stream itself could coincidentally be at fault, though unlikely. It's more likely that the proxying process itself is failing occasionally for some reason and is somehow related to the upgrade (a resource issue, may be?). BubbleUPnP Server requires the Java Runtime, so make sure you've got the latest version properly installed. Also, worth checking is the BubbleUPnP Server's log file, BubbleUPnPServer.log.0, normally located in the same folder as its executable file. When the track goes silent, does the controller app's track position slider/indicator advance as normal to the end of the track? Does any sound return before the start of the next track, however intermittent? Incidentally, support from Bubbleguuum, BubbleUPnP's developer, is available on the XDA-Developers site: https://forum.xda-developers.com/showthread.php?t=1118891BubbleUPnP John
  5. It should be a bare FLAC stream rather than OGG (containing FLAC). One of the players I tested the stream with cannot play OGG FLAC and all indicate the stream as FLAC; also tested with ffprobe and it reports the format is FLAC. The issue is that VLC appears to be by default setting the content type to the generic 'application/octet-stream' and presumably the players I tested with were happy enough to use the .flac suffix instead to identify the content type. Using the VLC --sout-http-mime parameter should force the correct content type for the stream.
  6. Hi blue2 I think you may have misunderstood my post which was intended for @bogi and others who could use the nightly VLC 3.0.0 to transcode the BBC's original MPEG-DASH FLAC to a more supported normal FLAC stream for use in a player other than VLC. So command line is not intended for VLC to play the BBC stream and output a sound within Windows, as its output is actually another stream! If you just want to use the nightly VLC 3.0.0 to actually play the BBC stream, just run it as normal, enter the stream's URL in the Open Network Stream function and hit play.
  7. Ok, understood. BTW, using the latest nightly version of VLC 3.0.0 mentioned above by @Bystander is another way of obtaining the BBC pilot radio stream. You can get that version of VLC to transcode the MPEG-DASH FLAC stream to a normal FLAC stream via its http file server. I've tried it myself, using the command line: vlc "https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/client_manifest.mpd" :sout=#transcode{vcodec=none,acodec=flac}:http{mux=flac,dst=:8080/bbcr3.flac} (the quotes around the stream's URL aren't necessary but I had to place them as this editor is interfering giving errors ) This produces a transcoded stream at http://aaa.bbb.ccc.ddd:8080/bbcr3.flac where aaa.bbb.ccc.ddd is the IP of the machine running VLC. The advantage of this method is of course no use of Firefox and redirecting of Windows audio output. However, I'm not sure how well the nightly VLC's MPEG-DASH FLAC decoder is working, as it reports decoding the 16/48kHz stream to 32/48kHz. Also, oddly, the players other than another VLC instance (foobar2000, OpenHome Player on a Raspberry Pi & a Pioneer N-50 streamer) I've tried receiving the transcoded FLAC stream, report it as 24/48kHz.
  8. This thread shows how you can route all Windows sounds through Virtual Audio Cable (bit perfect Kernel Streaming) to audio device of your choice. Not sure I follow how this would specifically help @Confused, given that the Devialet's AIR Streaming Windows audio device can be made the default Windows audio output device, in common with any other Windows audio device. Of course if you were making some sort of general statement, then of course I agree, as I regularly use the donationware VB-Audio HiFi Cable which performs a similar function (for streaming to UPnP/DLNA renderers, including Chromecast Audios emulated as such, via the foobar2000 + foo_record + foo_upnp method you also mention above - though I use the foo_out_upnp plugin too). Incidentally, using the Virtual Audio Cable or its VB-Audio equivalent would still require you setting it as the default Windows output device to redirect Firefox's audio, plus configure it to 16/48kHz for bit perfect access to the BBC pilot radio stream, regardless of what audio device you are redirecting the audio to.
  9. HQPlayer is going to need to play FLAC in an MP4 container being streamed by MPEG-DASH, ie, the BBC pilot stream is not a run of the mill FLAC stream.
  10. Presumably, you are listening to this via a Windows machine since Firefox always uses the default Windows audio device which appears to be set to 16/44.1kHz and hence the Devialet's indication. The stream is actually 16/48kHz as has been pointed out above, so you will need to change the Windows default audio device's setting to match in order to have bit perfect output to the Devialet.
  11. Thanks for the heads up. Looks like it'll be using MPEG-DASH streaming mechanism. Ironic that Cambridge Audio are getting involved, given their track record of supporting BBC's current 'HD' HLS AAC radio streams!
  12. In your Roon setup, the digital audio signal originates at the Sonic Transporter by the Roon Server decoding and playing the music files, is carried by the network to the microRendu with its Roon EndPoint and finally arrives at the Lindemann being used as a USB DAC. Contrast this with the Lindemann being used as a network audio file player, where all the decoding & playing of the music files occurs inside the Lindemann itself and the resulting digital audio signal output arrives directly at its internally connected DAC, ie, via the shortest possible route (with no involvement of the network, USB audio and any associated devices & software). With the Lindeman as a network player, the network is being used to supply the Lindemann with music files (from the UPnP/DLNA media server), not the digital audio signal.
  13. Ok, I think I know what you mean by the Lindemann's "native server", the built-in UPnP network audio file player (aka renderer aka streamer). The Lindemann's network player requires a UPnP/DLNA media server to supply it with music files on the network. The Lindemann itself doesn't have a UPnP/DLNA media server, so its network player will need to obtain the music files from one on a networked device. The UPnP/DLNA media server software usually runs on the same network device that contains the music files it is supplying, eg, a computer or a NAS. The Synology NAS you are using has a default UPnP/DLNA media server that comes with its DiskStation Manager software. This is likely to be the UPnP/DLNA media server you are using to supply the music files to the Lindemann from the Synology NAS, if you are not using a third party UPnP/DLNA media server on the NAS (such as the MinimServer UPnP media server you mentioned). Not sure what you mean by "Lumin server". There's no such thing as a Lumin UPnP/DLNA media server. There are of course the Lumin network audio player devices (so devices similar to the Lindemann) or the Lumin controller iOS & Android apps - were you referring to one of these?
  14. The only other OpenHome controller app I know for Android, with online streaming services support, is BubbleDS Next. It's an OpenHome only, cut down version of the BubbleUPnP app, so should be a bit friendlier for your partner to use. Not sure what gapless support issue is. It's the interaction between the BubbleUPnP Server's created OpenHome renderer and JRiver's built-in standard UPnP/DLNA renderer that manages gapless in that setup. So it shouldn't make any difference what OpenHome controller you're using. The only thing I can think of is perhaps you are using the BubbleUPnP app as a standard UPnP/DLNA controller instead of an OpenHome one (it supports both), so controlling the JRiver renderer directly rather than via the BubbleUPnP Server. Perhaps the BubbleUPnP app's (standard UPnP) gapless support has been switched off in its settings or there's some issue with it controlling the JRiver renderer. Another consideration is that the BubbleUPnP Android app itself would be providing the connection to Qobuz and proxying its audio file track streams in standard UPnP controller 'mode', as opposed to BubbleUPnP Server's created OpenHome renderer running on the Mac Mini with the BubbleUPnP app in OpenHome 'mode'.
  15. BTW, before you pull that "financial trigger", you do realise that the networked machine running the UPnP/DLNA media server has nothing to do with decoding and playing the music files? All it does is supply the music files completely unaltered over the network for the UPnP/DLNA renderer. As an UPnP/DLNA renderer, all the decoding and playing of the music files is done by sMS-200, specifically by its MPD (Music Player Demon) software.