Don't expect Tidal Max anytime soon

It doesn’t look like we’re going to see a firmware update for Tidal Max anytime soon. I’ve been in contact with Naim Tech Support since they received source material from Tidal late last year and on Jan 2nd Naim Tech Support said they have what they needed for updating out firmware but the 3 times since then when i enquired on the progress of the new firmware they always say
they’ve had “further delays in waiting for some of the source materials from TIDAL to be delivered”??
I guess that’s they’re brush off line lol, anyway yesterday’s email from Alex at Naim Tech Support said “. We are hoping these delays will not extend on too much longer however at present we do not have any ETA on this firmware update”. So it’s safe to say don’t expect it anytime soon… :disappointed:


Eversolo is in my future?

I don’t wish to be banned. Not at all, but it seems like companies like Eversolo are doing this to Naim:

I am rooting for Naim. Come on, help us help you Naim!

StreamUnlimited (manufacturer of the NP800 board in naim streamers) released their updated software SDK supporting Tidal Max (Connect) on 12th March.

So add a typical development cycle with betas on to that for full support of Tidal Max in both naim app and via Connect.

Not anytime soon sums it up.

P.S. on the new naim website the naim app is rather grandly described like this:
This application is a breakthrough in terms of sound quality and user experience


Most people who want to fully experience what Tidal offers are likely now using apps like mConnect anyway. Those have no problem sending High Res Tidal streams to NDX2 etc.

May I ask how mConnect works and how it is able to play 24/96?

Me too please, can some kind soul explain just how it does function, I use it to stream Qobuz to my NDX, sounds good to me.

I was only pointed toward mConnect the other day in the long Tidal Max thread. It works really well, much better than similar apps I’ve failed to get on with in the past.

I’m reasonably familiar with the technology it uses: DNLA (think streaming, built on UPnP, which is networking). The app acts as a ‘Controller’, only lightly managing a direct connection between the ‘Server’ (Tidal) and the ‘Renderer’ (your streamer).

Basically the app tells the streamer to play a remote file. So while the app doesn’t handle any streaming data, it’s constantly required to manage the connection and provide the urls of the files. Which is where it differs to a “connect” type approach, where the streamer does all of that autonomously.

Thanks for this. So this means that the streamer can play 24/96?

DNLA doesn’t support every audio format. But I’m pretty sure it can handle FLAC up to whatever quality your steamer can render FLAC at.

For example the spec on my ND5 XS 2 for FLAC is: 24 Bit / 384 kHz. But the highest Tidal delivers is 24/192.

1 Like

I can stream 24/192 from Tidal on my ND5 XS2 using a combination of bubblesoft server and bubblesoft player so workarounds are available with very little effort

Thanks for that, it’s worked reliably here for some time now!


Roon support Tidal Max already so that can also be an option in the meantime.

Indeed but DLNA is a limited profile device subset developed by Sony of UPnP that aimed for better interoperability between mass produced products by reducing features like codecs etc and conforming to specific device capabilities. UPnP is more about a set of SOAP networking protocols for media playout and discovery rather than limiting device capabilities to conform to a profile.

As far as I am aware Naim does not limit itself to DLNA and supports the more open and flexible UPnP to meet its product and ecosystem requirements and I don’t believe has any limitation on codecs and bandwidths other than it needs to use defined MIME types that the server and endpoint support.
The dBPoweramp server that is popular with Naim streamers is UPnP, but will also support more limited DLNA end points even if you tell it to transcode certain codecs for certain restricted end points.

1 Like

So a Gen 1 streamer would still be streaming from a remote server? In that case, isn’t the small buffer still a problem for streaming hires flac?

The issue with the gen 1 streamers was latency management and slow TCP stack performance as well as limited TCP session buffer memory (not be confused with sample data buffer memory. So for cloud streaming over the internet where latency is greater than on your home network network, it could struggle with greater higher throughputs such as 44.1/16/2 FLAC from Tidal compared to Vorbis as used by Spotify and the stack could could get over loaded and throws a whole lot of unconfirmed data away and try and recover… this could result in a dropout or glitch.
However on a home network where latency is typically a lot less this wasn’t an issue.

Hi Simon, so does that mean that the data goes through two buffers, one after the other?

Oh yes… there are network transport and session layer buffers, and then application or sample data buffers outside of the network stack.