philippe_44 wrote: > 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.
Thank you for taking the time to look at this and for your detailed reply. Your clear explanation makes perfect sense to me. Unfortunately changing the <raw_audio_format> to just wav didn't work. As you say sending FLAC from Roon completely resolves the problem and I do understand that the player ends up with the same data once the placer has decoded the FLAC back into PCM. The processing overhead in the legacy Naim streamer does generate noise which makes a very subtle difference to the sound quality and therefore PCM/WAV is the preferred option. I could address this by purchasing the new model which supports Roon but at £13000 for the bare unit (I could reuse my power supply) it's quite a stretch! On balance the slight inconvenience that this issue causes is probably worth keeping the system completely optimised for sound quality. I only noticed it with a mixed playlist. It did take me 2 years to notice that this was happening! Another workaround is to constrain to 24/96 within your software as the difference in sound quality between 24/96 and 24/192 is questionable. Then the streamer sees PCM all the time and is happy. Thanks again Richard ------------------------------------------------------------------------ rdmaidment's Profile: http://forums.slimdevices.com/member.php?userid=70292 View this thread: http://forums.slimdevices.com/showthread.php?t=103728
_______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
