@wklie Lumin U2 user here.
I’m curious about JPlay iPhone (or iPad) app with the U2.
Is there any difference in the way the music files are streamed (and processed by Lumin hardware ) from Tidal or Qobuz servers and that is eventually transferred out of the USB DAC port to my DAC?
Another way to ask this: does the native Lumin app have a different audio pipeline than when the Lumin is controlled by UPnP apps like JPlay or Mconnect?
Thank you
No UPnP is the same across any application. It instructs server and renderer as to what to do. Streamer pulls the stream from the server by means of url that get sent by the server via the controller app.
Lumin app uses OpenHome which is an offshoot of DNLA that allows playlists to be saved on the server so allows transfer from one controller device to another. Standard UPnP it’s all done via controller app.
For playback from local UPnP media server, Lumin native playback and JPlay should probably be the same unless the latter chooses to do additional buffering and present itself as a UPnP server - I don’t know whether JPlay does this but a third party app can choose to do this and do special things (e.g. resampling by Audirvana).
For Tidal / Qobuz, it is different because of the difference in which piece of software (JPlay or Lumin firmware) does the Tidal / Qobuz login, and there can be differences in the way Tidal / Qobuz API is invoked for getting the Tidal / Qobuz stream - and depending on which API or the parameters the stream can potentially be in a different format. In the past when Tidal supported MQA, only an authorized MQA client can get a 24-bit MQA stream from Tidal using the proper Tidal API with proper rights. Again a third party app can choose to do additional buffering if they want to, and do a decryption and/or decompression to WAV if they want to.
Peter,
Thanks so much for the details. When you mention format differences what are the options? I figured once a Tidal server gets a request for a song the FLAC file is encoded by whatever standard there is for encapsulation then the packets are transmitted.
Also how could JPLay add buffering ? What FIFO / memory would control this… it has to reside in the Lumin U2 processor correct? Jplay IOS is just an app on the phone and only sends commands …unless the app can request the sender (Tidal) to buffer ??
I apologize for my lack of understanding on networking.
Regards
It’s a UPnP pure controller it doesn’t buffer anything, they claim it does less polling processes to minimise noise. Believe what you want here. I’ve found it sounds the same as any other app.
If we look at Audirvana and another Android UPnP app, they act as a middleman UPnP server themselves to perform buffering (and resampling if enabled in Audirvana). I don’t know what JPlay does or does not do.
If JPlay does not act as UPnP server, its login and API usage will still be different from Lumin native Tidal Qobuz.
Thanks. How does the middleman UPnP perform the task of requesting more buffer size? Is that at the transmit end, receive end or both?
I’m vaguely familiar with Linux command “ethtool -g eth0” …One could perhaps write some code that finds out the buffer size (typically NIC’s have a buffer memory of 2-16MB where incoming packets are stored before DMA transfers to next stage) and request deeper buffer, but apart from obvious playback stuttering if buffer sized too small, it’s not obvious to me how the data itself might be affected. Once it’s captured / clocked in a FIFO/ Ring buffer it’s in and that’s that.
What I do know to be true is that I hear a pretty significant difference, especially in the treble focus/harmonics/air category b/t Roon and Lumin native app (and now JPlay). I have not compared JPlay to Mconnect, which is also UPnP, but based on what I’m reading here even MConnect and JPlay could do things differently with the buffers and network transmission. Why THAT would contribute any difference in end result audio quality is a good question…but maybe it’s not that at all and perhaps it’s down to Roon’s RAAT implementation where it’s processing and repacking data packets in it’s own proprietary manner- that gives rise to sonic differences.
The endpoint software in a RAAT scenario has to unpack and deliver the data differently than a lighter-weight UPnP process with less processing of the original data from the Tidal servers.
Please correct me where I’m wrong. I am deeply out of my depth here and would like to learn more about the steps involved in the transmission of a network FLAC file that is ultimately processed by a USB connected DAC.
I don’t like that there are differences , bits are bits right 
but after years of playing with Roon and various streaming protocols I (and many others) have come to the conclusion they are certainly real.
I realize decoding FLAC files to PCM is quite nuanced and since it’s an OPEN codec, subject to individual developer implementation. Perhaps this is why there is a difference b/t Roon and native Lumin/Other UPnP streaming apps…apologies for the long and winding stream of consciousness!!