I did some more experimenting over the weekend and answered some of my own questions. I set up LMS 8 on another server, also running 1.40.9 version of the bridge plugin so I can compare what I'm seeing with the bridge and Roon as the upstream LMS server versus the behaviour of the bridge with regular LMS.
duncsimpson wrote: > > I've done some more experimenting with the debug log enabled and I think > it is Roon that is converting all upstream content, regardless of file > type or codec, to LPCM/WAV when its FLAC compression flag is disabled, > or to FLAC when its compression flag is enabled. I'm basing this on two > entries in the bridge's debug log > > With FLAC compression disabled in Roon, this appears in the bridge log > at the start of the stream: > > [10:47:52.528150] process_strm:307 [0xbb9f40], strm s autostart: 1 > transition period: 0 transition type: 0 codec: p > > With FLAC compression enabled in Roon, this appears in the bridge log > at the start of the stream: > > [10:52:09.995058] process_strm:307 [0xbb9f40], strm s autostart: 1 > transition period: 0 transition type: 0 codec: f > > Am I interpreting that correclty, ie does that indicate it is the Roon > LMS server that is doing the processing, not the bridge? > > In both cases there is nothing in the debug log to indicate the bridge > is doing anything other than passthru. My observations using regular LMS and the bridge configured for passthru show the bridge is behaving consistently when comparing the bridge's logs with Roon as the upstream LMS. When LMS is offering a codec the bridge knows it can passthru, the bridge's log entries around the upstream codec and the subsequent behaviour of the bridge with regard to processing or resampling are consistent with bridge logs when used with the Roon LMS as upstream. I think this confirms that the bridge is behaving in passthru mode when Roon is the upstream LMS server. I think this also confirms it is Roon that is processing any track into PCM (or FLAC if FLAC compression is enabled in the LMS endpoint in Roon). However Roon doesn't report it is doing this in it's UI. This surprised me, because Roon typically tries to be transparent about any manipulation of the stream so the end user knows what is happening in every step of the chain they can see or control (which they can in this case). They do report that the last step in the stream is "Squeezebox Streaming" which is Roon's LMS implementation and it is the step that appears to be altering the stream in my observations. The Roon UI doesn't elaborate on this or say that this means the stream is being transcoded to PCM (or FLAC). Roon also has a "light" indicator if any step in the playback chain is materially changing the stream, however it is showing no changes when used with an LMS endpoint. For example, if I play an ALAC track, or a FLAC track, or WAV track, Roon reports in every case the track is being streamed as is, ie untouched, but the bridge and my NDX both report receiving a PCM in wav format. duncsimpson wrote: > > As a side note, when playing back DSD64 tracks from Roon to the LMS > endpoint configured for DoP, the bridge's debug log indicates the > incoming stream is already at 176.4kHz sample rate, both in case of FLAC > compression enabled or disabled for the LMS endpoint in Roon, and the > bridge is again simply performing passthru. Interestingly with FLAC > compression disabled in Roon, the DSD playback reports on the NDX itself > as WAV 2.8Mhz sample rate, whereas with FLAC compression enabled, again > the bridge reports passthru but the NDX reports FLAC 176.4kHz. I also saw this with the bridge when using LMS 8 as the upstream LMS server, ie despite having DSDPlayer plugin in LMS configured to do DoP, my NDX player reports the incoming stream is FLAC 176.4khz when playing DSD64 or DSD128 tracks. From what I can tell in the bridge's logs, the bridge is recieving a FLAC stream from the upstream server, so it must be LMS doing that transcoding. I had trouble viewing the LMS transcoder logs, so I can't confirm what the LMS server actually did. In either case the FLAC behaviour could be a side effect of FLAC reporting a sample rate that differs from the actual underlying PCM data when the given server is using DoP with FLAC instead of DoP with PCM/wav, I'm not sure. duncsimpson wrote: > > I also noticed the artist/album info is displaying on the NDX's display > as blank/unknown and the server is "Streaming from LMS". Looking in > the debug log I see this: > > [11:11:35.536470] sq_callback:339 [0xc3f500]: > artist: > album: > title:Streaming from LMS > genre: > duration:0.000 > size:0 > cover: > offset:0 > > Does that indicate that the Roon LMS server is not sending the > artist/album data? I found three things here: 1. In my experiments, when LMS 8 is the upstream LMS server, the bridge logs show the album/artist data coming through in the sq_callback logs. So I think this confirms the blank data and "Streaming from LMS" is the upstream Roon LMS server's behaviour. 2. Again, in my experiments, when using LMS 8 as the upstream LMS server, the bridge logs show the stream begins again at track changes, and each time there is new metadata. When using the Roon as the upstream LMS, there is only one long stream, unless the sample/bit rate changes between tracks, at which point there is a new stream with the new sample/bit rate. Each time Roon starts the new stream, there is empty metadata with only "Streaming from LMS". 3. I searched through Roon's community forums for anything on this, and found a number posts that confirm the above 2 findings. Other Roon users observe the same thing with both Roon's LMS and Chromecast support, and Roon's developer's also replied on the topic. Apparently with Roon's Chromecast and LMS support, the Roon developer's chose guaranteed gapless playback over accurate metadata when streaming to Chromecast or LMS. They found the only way to guarantee gapless playback is to send one continuous stream, however when doing so, there is no way to update the meta data midstream with most protocols like Chomecast, LMS, UPnP etc. The Roon developers said they chose to prioritise gapless playback, knowing there is this trade off, and as part of that, they chose to send no metadata rather than the metadata for the first track. This seems a reasonable tradeoff to me, I think I would chose the same tradeoff. So to sumarise, when using the LMS2UPnP bridge with Roon, there are some trade offs, all of which appear to be due to the upstream Roon server's LMS implementation, or limitations of the protocols being used, ie the trade offs are not caused by the bridge itself: 1. The bridge and thus the downstream DAC sees one continuous stream with no meta data. It is Roon that is doing this in order to guarantee gapless playback, and they chose to send no metadata due to the limitation in the protocols being used where meta data can't be updated mid stream. 2. The Roon server's implementation of LMS support is altering the stream into either PCM in wav or FLAC, however the Roon UI is only reporting "Squeezebox streaming", and doesn't indicate there an alteration happening. This could be seen as a little misleading, especially given the Roon developers usually go to great lengths to report any alterations. To be clear, the playback is probably still bitperfect ie the output stream is always in the same sample/bit rate as the input stream in all cases, possibly with the exception DSD playback. See next point on that. 3. The "Enable FLAC compression" setting in Roon for the LMS endpoint converts all playback to FLAC if enabled, or PCM in wav format if not enabled. In either case you should be getting bitperfect playback because the raw data is the same. The exception seems to be with DSD playback. With FLAC compression enabled for the LMS endpoint in Roon, the bridge and the DAC both report receiving 176.4kHz PCM in FLAC. As noted above, I'm not sure if the upstream server is transcoding or if this is a side effect of using DoP over FLAC. With FLAC compression disabled in Roon, the PCM/wav stream appears to be 2.8Mhz (eg with a DSD64 file). If any of this matters to you, then disabling this feature (its enabled by default I think) is the way to go. Roon themselves are clear that the LMS support is "as is where is", ie they developed it a while back, it is still there for now and works for the most part, however it is now unsupported. I think this means that any change requests or bug fixes relating to it are likely to be low in their prioritised backlog, if it makes there at all. I think its up to each person whether any of these trade offs are a problem. In my case, I've enjoyed digging under the covers and learning about all of this, and I'm happy to continue using my Roon setup with the LMS2UPnP bridge knowing about these trade offs. I'm posting my observations in case it helps explains things for others who wonder what is happening. I suspect many people won't care at all, or not enough to dig any deeper, and will just enjoy the music. And that's what its ultimately all about. ------------------------------------------------------------------------ duncsimpson's Profile: http://forums.slimdevices.com/member.php?userid=70703 View this thread: http://forums.slimdevices.com/showthread.php?t=103728 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
