Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[philippe_44]

Hi (again) - I'm trying to send now 24 bits PCM over DLNA to JRiver as it claims to support audio/L24 in ProtocolInfo. Unfortunately, when I do that, all I have is noise with a very faint the song, and slower than normal. JRiver says input is "44.1kHz 16 bits, 2 channels from source L24". So obviously the source is not detected properly which explains noise and slow playback.

The DIDL header contains "audio/L24;rate=44100;channels=2" and the mimetype in reponse to the HTTP GET request is the same. I've tried plain 24 bits samples as well as 24 bits packed LPCM with same result. I've captured the samples and stored them in a file and verified with audacity that they are 24 bits, big endian. I've also tried little endian, no success. Do I miss something?

Thanks

[AndrewFG]

I am not completely sure about this, as I didn’t check directly, but you might try adding a third parameter “depth=24” (or “bitdepth”) to the mime type in Content-Type and in the SetAVT meta data.

See my response to your other question concerning Chunked encoding too.

[philippe_44]

I tried both and it did not work unfortunately. It seems that the renderer is doing some smart to detect the actual bit depth and organization that fails with what I'm sending which is simply 16 bits PCM upshifted in 24 bits

[edit]: out of curiosity, is it possible to know what UPnP renderer engine JRiver uses? Proprietary or based on some open source one?

[AndrewFG]

MC uses an own developed proprietary UPNP library.

Concerning your issue with pushing L24 to MC, I suggest you use a network analyzer (Wireshark) to look at the HTTP headers when MC server is pushing to MC renderer, and compare them with when your server/control point is pushing to MC..

[philippe_44]

I'll do that (hopefully I can just use the same instance and loopback interface, just need to check that)

[philippe_44]

Interestingly enough, even in raw PCM with audio/Lxx;rate=yyyyy;channels=z in res@protocolInfo, MC still requires optional DIDL-lite field of sample rate, size and channels (in res@) to be set to handle 24 bits. Per our discussions, too many sources of truth as res@protocolInfo already contains that. I hate UPnP

[AndrewFG]

As I said before, I parse ALL sources of meta data — 1) the protocol info, 2) the HTTP headers, and 3) the headers in the media stream (although obviously in the specific case of PCM Lxx such stream headers are absent). I start with 1), and if any information is missing proceed to 2) and then 3).

Note: this does not just apply to playing data like bit rate, depth, channels, duration and size; it also applies to information data like tags and even cover art. Although pulling information from the media stream can be a bit more complex since the information is often at the end of the media stream rather than the beginning (and you don’t want to wait til the track has played out before you display the information to the user..).

[philippe_44]

I understand you do that, but what surprised me is that, according to http://www.upnp.org/schemas/av/didl-lite-v2.xsd, res@protocolInfo is the required field. I populated it with 

protocolInfo="http-get:*:audio/L24;rate=44100;channels=2:DLNA.ORG_PN=LPCM ..." so all the info for that stream, but that was not working.

The I added the optional fields

sampleFrequency="44100"  bitsPerSample="24" nrAudioChannels="2"

and then it worked

So I thought that the DIDL-lite had all the required info with just res@protocolInfo to evaluate the properties of the resource (and there is other metadata of course)

In addition, my response to the GET contained a content-type header with "audio/L24;rate=44100;channels=2", but it was still playing 16 bits streams.
I'm not complaining, just trying to point where I think the problem was to help

[bob]

Thanks Andrew and  Philippe, that was easy to track down because of the detail provided.

I added code to get the bitdepth without the res@. I imagine I should have done this in the first place.
I believe I was the first to implement L24. We needed it and no existing devices or implementations existed.
Since MC passed the bitdepth along with the res@ and we were the only ones to send/recv the format I wasn't concerned about falling back to the mimetype.

It will be in the next build...

[philippe_44]

Great - Let me know if you want to help with test