Home of the Squeezebox™ & Transporter® network music players.
Page 289 of 291 FirstFirst ... 189239279287288289290291 LastLast
Results 2,881 to 2,890 of 2905
  1. #2881
    Senior Member
    Join Date
    Apr 2019
    Location
    Wunstorf, Germany
    Posts
    356
    Hello!

    I think I can use this plugin for using an Ikea Symfonisk (Sonos) speaker.
    I only have one question regarding this.

    Is it possible to set the volume of the speaker in LMS (controlled by Material skin) like it is when using an Airport express with attached Speaker or do I have to use the volume buttons on the speaker itself?
    Pi4 4GB piCorePlayer with LMS and Squeezelite for USB; Pi3B+ (7" Display, Hifiberry DAC+ Pro) piCoreplayer with Squeezlite/Jivelite for Hifiberry and Bluetooth headphone; two Airport Express

  2. #2882
    Junior Member
    Join Date
    Sep 2020
    Posts
    5
    Noise with high sample rate since version 1.40.x, roon_mode, and wav codec support not working?

    Hi, I recently updated from 1.25.0 to 1.40.8 of the LMS2UPnP bridge and found I get noise with any high sample rate tracks.

    This is not the wall of white noise problem, I've had that in an earlier version where some tracks would just play a wall of white noise and if i skipped forwared to another spot in the track, or to the next track, it would correct itself. That was solved by updating to 1.25.0.

    Instead this current problem is more like garbled digital noise modulated by the track itself, ie it varies with the pitch and tone and content of the track. If I skip to another spot in the track, it sometimes comes right. If I skip to the next track that will have the same problem.

    The issue appears to be any tracks > 16/44.1 which are FLAC or WAV being played from Roon (eg 24/44.1, 16/88, 24/88 and so on). ALAC tracks > 16/44.1 playback fine with no noise. My renderer doesn't support ALAC natively, so I think this is because the bridge is transcoding in this case.

    I tried all 4 different setting for L24_format, none of them fixed the problem.

    I've reverted back to 1.25.0, and the problem goes away, ie it is not reproduceable in that version. I jump forward to 1.40.8 and the problem returns. I've tried all major versions from 1.25.0 to 1.40.0. Everything up to 1.31.0 works fine, the problem seems to be introduced with 1.40.0, and is still present in 1.40.7 and 1.40.8.

    I'm running the standalone version of the bridge on Arch Linux with roon_mode enabled, and controlling playback from Roon. My config file is the generated config with roon_mode enabled and the sample rate changed to 192000.

    My UPnP renderer is a Naim NDX which is capable of playback up to 24/192 in WAV and 24/96 in LPCM (as reported in DeviceSpy). I tried reordering the raw_audio_format setting to prefer WAV first however the problem is also present there.

    LMS endpoints in Roon (when LMS support is enabled) have an option to enable or disable FLAC compression. By default this is enabled, however I have it disabled.

    The noise problem with 1.40.x disappears if FLAC compression is enabled for the endpoint in Roon, and playback of any file format/codec up to 24/192 registers on the NDX as FLAC in the matching sample rate. However the reason I normally have FLAC compression disabled is twofold - when FLAC compression is enabled in Roon, then all playback is forced in to FLAC and playback of any DSD files is not longer bitperfect as it appears to always get resampled to 24/176.4 FLAC (not sure if Roon is doing this or the bridge). Secondly I think with the FLAC compression off in Roon, the WAV/LPCM stream is putting less load on the NDX processor because it doesn't have to decompress the FLAC stream which should result in a lower noise floor assuming its processor has to do less, and thus should in theory lead to better sound quality. During critical listening it does sound better for some tracks, more attack in the bass, highs sort of "sing" more, slightly more energy, more toe tapping goes on etc (however I also accept the times I think I've noticed those differences could just be confirmation bias ). When DSD's are converted in Roon using DoP with FLAC compression disabled, they get reported as WAV 2.8Mhz for example for a DSD64 file, so whilst not native DSD playback, it is closer to original quality than FLAC 176.4.

    All of this also leads to my second question - what does roon_mode actually do? The user guide documentation doesn't provide any detail other than "Set to Ĺ1ĺ to if you intend to use this player from a Roon server.". The diagrams in the documentation, for example, don't mention this mode at all.

    I have normally have FLAC compression disabled in Roon for this endpoint, and the bridge's mode is set to thru, and yet my NDX reports the stream is either LPCM or WAV regardless of what format file is being played on Roon, eg FLAC, WAV, ALAC, DSD, etc. When FLAC compression is enabled in Roon the NDX reports everything is FLAC during playback again regardless of what format file is being played on Roon, eg FLAC, WAV, ALAC, DSD, etc.

    So it seems that with roon_mode enabled, and if Roon has FLAC compression disabled on the playback device, then the bridge is not really in pass thru mode and instead it processes all incoming streams (FLAC, WAV, ALAC, DSD etc) to the first format listed in the raw_audio_format, despite mode being set to thru. If Roon has FLAC compression enabled, the bridge appears to pass through the FLAC (or perhaps it is doing some reprocessing the FLAC stream because flac_header is enabled by default?).

    I also noticed when using debug logging on the bridge that it is not offering wav support to the upstream Roon LMS server when using 1.40.x, even though my renderer supports wav and I have regenerated the bridge's config.xml to get the additional wav entry in the codec setting.

    In the interim I'm back to running 1.31.0 version of the bridge, but I'd be grateful for any help with the noise problem, or explanations of what roon_mode is doing behind the scenes, or why the newer wav codec support in 1.40.x doesn't appear to work in my setup.

  3. #2883
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,144
    Quote Originally Posted by duncsimpson View Post
    Noise with high sample rate since version 1.40.x, roon_mode, and wav codec support not working?

    Hi, I recently updated from 1.25.0 to 1.40.8 of the LMS2UPnP bridge and found I get noise with any high sample rate tracks.

    This is not the wall of white noise problem, I've had that in an earlier version where some tracks would just play a wall of white noise and if i skipped forwared to another spot in the track, or to the next track, it would correct itself. That was solved by updating to 1.25.0.

    Instead this current problem is more like garbled digital noise modulated by the track itself, ie it varies with the pitch and tone and content of the track. If I skip to another spot in the track, it sometimes comes right. If I skip to the next track that will have the same problem.

    The issue appears to be any tracks > 16/44.1 which are FLAC or WAV being played from Roon (eg 24/44.1, 16/88, 24/88 and so on). ALAC tracks > 16/44.1 playback fine with no noise. My renderer doesn't support ALAC natively, so I think this is because the bridge is transcoding in this case.

    I tried all 4 different setting for L24_format, none of them fixed the problem.

    I've reverted back to 1.25.0, and the problem goes away, ie it is not reproduceable in that version. I jump forward to 1.40.8 and the problem returns. I've tried all major versions from 1.25.0 to 1.40.0. Everything up to 1.31.0 works fine, the problem seems to be introduced with 1.40.0, and is still present in 1.40.7 and 1.40.8.

    I'm running the standalone version of the bridge on Arch Linux with roon_mode enabled, and controlling playback from Roon. My config file is the generated config with roon_mode enabled and the sample rate changed to 192000.

    My UPnP renderer is a Naim NDX which is capable of playback up to 24/192 in WAV and 24/96 in LPCM (as reported in DeviceSpy). I tried reordering the raw_audio_format setting to prefer WAV first however the problem is also present there.

    LMS endpoints in Roon (when LMS support is enabled) have an option to enable or disable FLAC compression. By default this is enabled, however I have it disabled.

    The noise problem with 1.40.x disappears if FLAC compression is enabled for the endpoint in Roon, and playback of any file format/codec up to 24/192 registers on the NDX as FLAC in the matching sample rate. However the reason I normally have FLAC compression disabled is twofold - when FLAC compression is enabled in Roon, then all playback is forced in to FLAC and playback of any DSD files is not longer bitperfect as it appears to always get resampled to 24/176.4 FLAC (not sure if Roon is doing this or the bridge). Secondly I think with the FLAC compression off in Roon, the WAV/LPCM stream is putting less load on the NDX processor because it doesn't have to decompress the FLAC stream which should result in a lower noise floor assuming its processor has to do less, and thus should in theory lead to better sound quality. During critical listening it does sound better for some tracks, more attack in the bass, highs sort of "sing" more, slightly more energy, more toe tapping goes on etc (however I also accept the times I think I've noticed those differences could just be confirmation bias ). When DSD's are converted in Roon using DoP with FLAC compression disabled, they get reported as WAV 2.8Mhz for example for a DSD64 file, so whilst not native DSD playback, it is closer to original quality than FLAC 176.4.

    All of this also leads to my second question - what does roon_mode actually do? The user guide documentation doesn't provide any detail other than "Set to ‘1’ to if you intend to use this player from a Roon server.". The diagrams in the documentation, for example, don't mention this mode at all.

    I have normally have FLAC compression disabled in Roon for this endpoint, and the bridge's mode is set to thru, and yet my NDX reports the stream is either LPCM or WAV regardless of what format file is being played on Roon, eg FLAC, WAV, ALAC, DSD, etc. When FLAC compression is enabled in Roon the NDX reports everything is FLAC during playback again regardless of what format file is being played on Roon, eg FLAC, WAV, ALAC, DSD, etc.

    So it seems that with roon_mode enabled, and if Roon has FLAC compression disabled on the playback device, then the bridge is not really in pass thru mode and instead it processes all incoming streams (FLAC, WAV, ALAC, DSD etc) to the first format listed in the raw_audio_format, despite mode being set to thru. If Roon has FLAC compression enabled, the bridge appears to pass through the FLAC (or perhaps it is doing some reprocessing the FLAC stream because flac_header is enabled by default?).

    I also noticed when using debug logging on the bridge that it is not offering wav support to the upstream Roon LMS server when using 1.40.x, even though my renderer supports wav and I have regenerated the bridge's config.xml to get the additional wav entry in the codec setting.

    In the interim I'm back to running 1.31.0 version of the bridge, but I'd be grateful for any help with the noise problem, or explanations of what roon_mode is doing behind the scenes, or why the newer wav codec support in 1.40.x doesn't appear to work in my setup.
    Starting version 1.40.0 I've added proper header WAV/AIFF parsing and I guess this is conflicting with DSD or something like that. Give a try to 1.40.9

    <roon_mode> simply forces a couple of parameters to be compatible with Roon server which is not exactly acting as a proper LMS server
    Last edited by philippe_44; 2020-09-24 at 23:55.
    LMS 7.9 on Pi 3B+ & Odroid-C2 - SqueezeAMP!, 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, Riva 1 & 3

  4. #2884
    Junior Member
    Join Date
    Sep 2020
    Posts
    5
    Quote Originally Posted by philippe_44 View Post
    Starting version 1.40.0 I've added proper header WAV/AIFF parsing and I guess this is conflicting with DSD or something like that. Give a try to 1.40.9
    Thanks @philippe_44, the 1.40.9 version fixes the noise issue, much appreciated thank you!

    Quote Originally Posted by philippe_44 View Post
    <roon_mode> simply forces a couple of parameters to be compatible with Roon server which is not exactly acting as a proper LMS server
    Out of curiosity what are those parameters?

    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.

    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 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?

  5. #2885
    Junior Member
    Join Date
    Sep 2020
    Posts
    5
    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.

    Quote Originally Posted by duncsimpson View Post
    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.

    Quote Originally Posted by duncsimpson View Post
    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.

    Quote Originally Posted by duncsimpson View Post
    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's Squeezebox/LMS implementation 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 Squeezebox/LMS support is always altering the stream into either PCM in wav or FLAC, regardless of the file/codec being played. 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 appears to still be bitperfect ie the output stream is always in the same sample/bit rate as the input stream in all cases from what I observed. 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.
    Last edited by duncsimpson; 2020-09-27 at 14:03.

  6. #2886
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,144
    Quote Originally Posted by duncsimpson View Post
    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.
    It's a long post so I won't quote t but here are a few informations wrt what the bridge do and Roon

    - In short, the bridge does transcoding only if configured to using the <mode> parameter. Otherwise, it's a passtrough except for PCM where limited changes (sample size & headers) and flac where headers can be updated on the fly. But there is *no* decoding of audio in "thru" mode.
    - When a player discovers a server (and Roon emulates one), in its HELO message, it tells a bit what it can do, including a codecs list and a maximum sample rate. That informs the server when it should do transcoding on his side. Information like maximum sampe size is not provided.
    - In "thru" mode, the codecs set in <codecs> are what it is reported to LMS as supported codec, pending that the UPnP side of the player claims to support them. When doing transcoding, <codecs> are what's reported to LMS pending successful loading of the codec libraries (-static versions have them all). When doing transcoding, the bridge also can do resampling
    - Roon does not emulate some part of a LMS server and especially does not respond to the bridge query for metadata and that explains why you don't see anything. There is an alternative to get metadata that is supported by Roon, but this is not the one I've chosen to use and it's an important work to do the change.

    Hope this helps
    LMS 7.9 on Pi 3B+ & Odroid-C2 - SqueezeAMP!, 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, Riva 1 & 3

  7. #2887
    Junior Member
    Join Date
    Sep 2020
    Posts
    5
    Quote Originally Posted by philippe_44 View Post
    It's a long post so I won't quote t but here are a few informations wrt what the bridge do and Roon

    - In short, the bridge does transcoding only if configured to using the <mode> parameter. Otherwise, it's a passtrough except for PCM where limited changes (sample size & headers) and flac where headers can be updated on the fly. But there is *no* decoding of audio in "thru" mode.
    - When a player discovers a server (and Roon emulates one), in its HELO message, it tells a bit what it can do, including a codecs list and a maximum sample rate. That informs the server when it should do transcoding on his side. Information like maximum sampe size is not provided.
    - In "thru" mode, the codecs set in <codecs> are what it is reported to LMS as supported codec, pending that the UPnP side of the player claims to support them. When doing transcoding, <codecs> are what's reported to LMS pending successful loading of the codec libraries (-static versions have them all). When doing transcoding, the bridge also can do resampling
    - Roon does not emulate some part of a LMS server and especially does not respond to the bridge query for metadata and that explains why you don't see anything. There is an alternative to get metadata that is supported by Roon, but this is not the one I've chosen to use and it's an important work to do the change.

    Hope this helps
    Thanks philippe_44, yes that helps.

    That reminds me, in the debug logs, it appears the bridge is not offering wav as an option to the upstream LMS server.

    I see this with both LMS 8 as upstream and with Roon as upstream LMS server. I am using 1.40.9 in both cases (with LMS 8 and with Roon), I have regenerated the config xml which now includes wav in the common sections codecs list, and my UPnP player is reporting it supports wav. I tried overriding the codecs in the player's config section by adding +wav, and I also tried adding audio/wav to forced mimetypes, and yet I don't see wav offered to the upstream LMS server.

    codecs line in config

    Code:
    <codecs>aac,ogg,ops,ogf,flc,alc,wav,aif,pcm,mp3</codecs>
    The log entry where the bridge is reporting what the UPnP player reports:

    Code:
    [10:35:27.966743] GetProtocolInfo:370 [0xc3f500]: ProtocolInfo http-get:*:audio/L16;rate=44100;channels=1:DLNA.ORG_PN=LPCM,http-get:*:audio/L16;rate=44100;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/L16;rate=48000;channels=1:DLNA.ORG_PN=LP
    CM,http-get:*:audio/L16;rate=48000;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/L16;rate=96000;channels=1:DLNA.ORG_PN=LPCM,http-get:*:audio/L16;rate=96000;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/L16;rate=88200;channels=1:DLNA.ORG_PN=LPCM,http-get:*:audio/L16;rate=88200;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=44100;channels=1:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=44100;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=48000;channels=1:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=48000;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=96000;channels=1:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=96000;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=88200;channels=1:DLNA.ORG_PN=LPCM,http-get:*:audio/L24;rate=88200;channels=2:DLNA.ORG_PN=LPCM,http-get:*:audio/mpeg:DLNA.ORG_PN=MP3,http-get:*:audio/wav:*,http-get:*:audio/x-mpegurl:*,http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMABASE,http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMAFULL,http-get:*:application/ogg:*,http-get:*:audio/mp4:*,http-get:*:audio/x-flac:*,http-wavetunes:*:audio/x-ms-wma:*,http-get:*:audio/x-aiff:*,http-get:*:audio/x-m4a:*,http-get:*:audio/dsd:*,http-get:*:audio/x-dsd:*,http-get:*:audio/x-dsf:*,http-get:*:audio/x-dff:*,http-get:*:application/x-mpegurl:*
    Log entry of what the bridge offered to the upstream server:

    Code:
    [10:35:27.968431] sendHELO:135 [0xbb9f40] cap: CanHTTPS=1,Model=squeezelite,ModelName=UPnPBridge,AccuratePlayPoints=0,HasDigitalOut=1,MaxSampleRate=192000,aac,ogg,flc,alc,aif,pcm,mp3
    From what I understand of how this works, and the support for wav since 1.40.x I think the bridge should be offering wav to the upstream LMS. Is that correct, would you expect the bridge to offer wav in this case, and if so what is preventing it in this case?

  8. #2888
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,144
    Quote Originally Posted by duncsimpson View Post
    From what I understand of how this works, and the support for wav since 1.40.x I think the bridge should be offering wav to the upstream LMS. Is that correct, would you expect the bridge to offer wav in this case, and if so what is preventing it in this case?
    You're absolutely correct, 'wav' was missing from supported list - fixed in 1.40.10
    LMS 7.9 on Pi 3B+ & Odroid-C2 - SqueezeAMP!, 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, Riva 1 & 3

  9. #2889
    Junior Member
    Join Date
    Sep 2020
    Posts
    5
    Quote Originally Posted by philippe_44 View Post
    You're absolutely correct, 'wav' was missing from supported list - fixed in 1.40.10
    Wow, quick fix yet again, and I've confirmed it is working in my setup, many thanks philippe_44.

    Code:
    [14:06:19.264670] sendHELO:135 [0xbb9f40] cap: CanHTTPS=1,Model=squeezelite,ModelName=UPnPBridge,AccuratePlayPoints=0,HasDigitalOut=1,MaxSampleRate=192000,aac,ogg,flc,alc,wav,aif,pcm,mp3
    Last edited by duncsimpson; 2020-09-27 at 18:18.

  10. #2890

    Any Lumin Users?

    Are there any Lumin users that could share their configuration file?

    I'm using LMS to stream radio (iPlayer and Radio Paradise) to my Lumin T2.
    I've spent the morning trying different permutations, but have found I need

    HTTP mode as fixed for FLAC, and chunked for AAC radio.

    Is there a setting that will work for both streams?

    Simon.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •