philippe_44 wrote: > One comment I forgot to make about the "24 bits PCM" parameter. This one > has a complex interaction... > > Uncompressed PCM can be sent to players totally raw, without any header > of any kind. In that case, the format *must* be set in the HTTP response > using Content-Type: audio/Lss;rate=rrrrr,channels=c (where ss = sample > size). But uncompressed PCM can also be sent with a wav or aiff header > first which then contains information (sample rate, size, channels) > about the data that follow. > > The Bridge has to make some sort of complex decision when PCM is sent: > using raw, or wav or aif, depending on players's capabilities (bitrate > and sample size). Players advertise what they support in term of various > audio/Lss, audio/wav, audio/aif ... in this ProtocolInfo message, but > most of them do not advertise any audio/L24 option although when > receiving a 24 bits wav file, they can handle them. > > When sent in a wav or aif file, the 24 bits format is well defined: 3 > bytes for each channel, in sequential order. But when sending raw audio, > many options exist: send 3 bytes sequentially for each channel, send 32 > bits full integer and put the 3 bytes at the top, or at the bottom, and > finally a very complex packing option which requires 12 bytes (2 packets > of 6 bytes each made of - say it's just stereo - L and R) and then > combines that into a strange other 12 bytes packets with a different > bytes ordering (that's what I'm trying to get to work with @PasTim, it's > a nightmare everytime I'm changing things because I had no way to test - > I have some limited options now) > > So the "24 bits PCM" parameter governs the following options: > > - When transmitting 24 bits samples using "raw" pcm, decide if you want > "packed" mode, or "plain" or do a truncation to 16 bits if your player > does not advertise audio/L16 by using "16 bits raw only". > - You can also always do a truncation to 16 bits, even if "wav" is sent > using '16 bits always' > > How does the bridge decide which format to send? It will try the options > in order according to 'PCM format' parameter (any combination of 'raw', > 'wav' or 'aif'). > > 1- When examining a "wav" option, if audio/wav capability exists it's a > match and optionally truncation to 16 bits samples is made if "24 bits > PCM" is set to "16 bits truncate always" > 2- When examining a "raw" option, it will try to find an exact matching > capability for audio/Lss. In case of 24 bits sample, if it does not find > an audio/L24 match but you have specified "24 bits PCM" to any of the 16 > bits truncation option, then it will try to find an audio/L16 match > > Now, to make it even e bit more complex, the way UPnP works, is that you > must tell player what it should expect to receive before LMS sends > actual audio data so if you intend to sent to the UPnP player 'raw' pcm, > you *must* tell it the sample rate and size very early, certainly before > you have received any audio data from LMS. > > But when LMS sends compressed format, such information is only known > after LMS audio transmission has started, so I *have* to use wav or aif > format (as per 'PCM format' parameter) *unless* you *forced* the sample > rate and size to a known value in which case I can use any option set in > 'PCM format', including 'raw'. Of course, if LMS send me already > uncompressed pcm, I will have the information at the early stage and I > can use the full choices of 'PCM format' > > So in 'pcm' mode, if you have *forced* a sample size to 24 bits, the "24 > bits PCM" option of truncation '16 bits always' will be ignored (which > sounds logical, you really want 24 bits) but if you have set it to "16 > bits raw only", then that rule will apply and the bridge will accept 16 > bits matching in case no 24 bits is found, when examining the 'raw' > option > > I'm sure your head already exploded at this time :) (mine did a few > times when I was coding that, hence my call for help testing)
Thanks for the explanation - no wonder you asked for help with testing ! The Yamaha makes no claim for 24 bit raw PCM support in the specs - just FLAC & WAV. The Protocol Info response only claims 16 bit support - audio/L16 - but then we've learned to take that response with a pinch of salt :D Certainly I if try 24 bit raw at the moment I get a codec error - 16 bit raw works ok - so do you think I could force it to try 24 bit raw by adding audio/L24 to the additional mimetypes ? or would it need something else ? If it doesn't work I can't be sure whether it's just the player that doesn't support it or some other issue - but I can give it a try... LMS 7.9.2, Ubuntu-MATE 18.04, Yamaha CD-N301 (UPnP/DLNA Bridge), Cambridge CX-A60, Monitor Audio Bronze 2, Soundstyle Z2 LMS 7.9.2, Ubuntu-MATE 18.04, Squeezebox Touch, Arcam Solo, KEF iQ5 FLAC up to 24/192 ------------------------------------------------------------------------ SteveBamber's Profile: http://forums.slimdevices.com/member.php?userid=66397 View this thread: http://forums.slimdevices.com/showthread.php?t=103728 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
