rdmaidment wrote: > I wonder if I can be given any assistance into an issue I am > experiencing. > > I use lms-to-upnp to bridge Roon with my Naim NDS. It's been working > well for 2 years. > > However have identified an issue with mixed format playlists. > > If I have a playlist which has a 24/192 track and the next track is say > 24/96 when the track finishes it does not advance on to the next track. > I can go the other way so 24/96 to 24/192 is OK. > > 24/192 tracks seem to be the only issue. i.e. if I have a 24/96 track I > can advance to a 16/44 track OK. > > I can work around this in one of 2 ways. > > 1. If I set stream_length to -2 the track will advance. However the > last 10 seconds of the track doesn't play, i.e. it advances 10 seconds > too early. This happens for all tracks regardless of format so isn't > really workable. > > 2. If I set FLAC compression in Roon to on then I don't see this issue. > I don't want to do this as Naim streamers perform best if they receive > PCM/WAV and don't have to transcode. If I get lms-to-upnp to transcode > FLAC to PCM that track advance issue is reintroduced. > > One thing I have noticed is that 24/192 files show as being played as > WAV if I check on the streamer whereas all other formats show as PCM. I > wonder if it's the change from WAV to PCM that causes the issue? > > I've tried many permutations of settings and cannot seem to get to the > bottom of this so any help would be appreciated > > Here's the Common section of the config file > > <common> > <codecs>aac,ogg,ops,flc,alc,aif,pcm,mp3</codecs> > <raw_audio_format>raw,wav,aif</raw_audio_format> > </common> > <device> > <name>Sitting Room</name> > <mac>bb:bb:f6:b1:d4:f3</mac> > <friendly_name>Sitting Room</friendly_name> > <udn>uuid:5F9EC1B3-ED59-79BB-4530-0011F6B1D4F3</udn> > <enabled>1</enabled> > <accept_nexturi>1</accept_nexturi> > </device> > > > Thank you
So I've looked at the log and here are a few comments: first, using the bridge for Roon will always be a bit of a hit an miss because it's not what I designed it for. Roon does not fully emulate a LMS server and so I'm missing the metadata (at least Roon does not expose them through the query method I'm using). The unencoded formats authorized for the bridge are set by <raw_audio_format>, in order of preference. You have set "raw,wav,aif" which means that I'll send raw pcm if the player has declared that it can support such format in its "protocolinfo" manifest (for example audio/16;rate=44100 or audio/L24;rate=192000) and if not found I'll fallback to wav then aif (again, assuming the protocolinfo declares them). In the case of 24/192, well obviously the Naim is *not* declaring that it supports audio/L24;rate=192000. It might, but their "protocolinfo" manifest is incorrect then. So in that case, I fall back to WAV. Now, to send WAV to the upnp device, I need to set the length in the header and I dont get' it from Roon and I don't know either the duration (no metadata) so all I can do is set a fake length with is 2^32-1. Then, when Roon tells the bridge the track is finished, I have to abruptly cut the connection to the upnp player hoping that it will understand that, although it has not received all the promised bytes in the wav header, it means really the end of the track. Not all players accept that gracefully but at least when using stream_length to -1 or -2, there is not HTTP content-length header set many players just accept that the *wav* header is faulty and they move on. But, when you send 16/44.1 then the bridge finds its in the manifest and sends raw pcm, which is much better because there is no header to fake. Now, when there is a transition from "wav" to "raw pcm", something seems happens and I don't know what. Are you 100% sure that if you play three 24/192 tracks *or* 3 16/44.1 track they advance normally? Now, if you set stream_length to -2, I'm *forcing* a content-length field in th HTTP headers and because I don't have a real one (again, can't get it from Roon) then this is closest multiple of 2^32 from 192000*3*2 (happens to be 4924656000+44 for wav header). Per my previous comment, telling in HTTP headers that you'l receive X and sending Y is *bad* and most player will not react happily to that. Why does it end 10 seconds before the end of a track, well I don't know but I suspect the exactly Naim does not like the HTTP connection being closed before content-length has been received so it "punishes" you :). What can you do? Well, you can ask Naim to fix their manifest... or you can try to only use "wav" as the unencoded format sent to it by setting <raw_audio_format> to just wav, it might work. Now, candidly, if the Naim does not declare 24/192000, the good reason might be that, in reality, it does not accept it (even if the manual says it...) and all it does when receiving 24 bits in a wav envelop, is truncating audio. Would not be the first time I've seen that... I know you don't want to hear that, but the wise choice is to ask Roon to send flac. You'll have a nice header then and every player and bridge will be happy. I can guarantee you for a fact that there is 0.0 difference between, wav/pcm and flac. Nothing, zip, nada, zilch, zero. 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 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=103728 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
