Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Streaming Any sign of Meridian announcing MQA options for existing equipment yet?

I believe that M is developing another card that will be added to the 861v8 card base that will pass MQA over SL, as the card now used does not have the capability to go with more than 96/24 hopefully it can be done with software but...

Something else to consider is that M is not doing the new codecs so that may be being included also, so it is a wait and see.

I am not upgrading my center channel to SE for the time being because there is no path yet shown for multi-channel MQA as I mentioned above. If the other M series processors can't be software upgraded to MQA this could be very frustrating for some.

Just my thoughts.

One thought.
The actual hardware for decoding can't be that expensive. After all, it's included in an Explorer 2.
So how about a cutdown Explorer, with a stereo coaxial connection that could be pulled in via an MHR connection on an appropriate processor (e.g. 861, G68, 568.2mm)?

My assumption is that anything that outputs in the digital domain has to be encypted.
I haven't noticed any competitor product yet that provides full MQA support with a digital output.

Clearly one of the components that MQA "profiles" in the audio chain is the final DAC in the system, however in our Meridian digital input loudspeaker environment the DACs are within.

This would suggest either M will need to add the code to existing speaker f/w of which there are many, and a lot of owners would likely end up disappointed, or M will rely on MHR encyption which seems highly plausible. This though requires that the digital processor must know exactly which speaker is downstream in order to decode this optimally, I am not aware that the firmware does this currently. The config program knows this but I expect this is mainly for comms and I am not aware the processor actually knows whilst running which speaker it is connected to and has the ability to choose a "map" to match it.
If this were the case then all sorts of pre-eq/processing could be done, even the likes of EBA?!

To the original point, I say again that I think it should be possible by now for M to make some broad statements such as xxx equipment will be supported in due course (eg 818, Explorer but what happenened to the promised support for the C15?), yyy equipment may be supported but further work is required to clarify this, it will not be possilbe to support zzz products. for those owners with legacy unsupported or not yet supported products, M plan to release a new separate MQA processor support all M systems by end of 2016.

As things stand M owners who have invested likely far more than me are sitting back watching competitor DACs being released with MQA goodness, though with no real interest in adding a DAC to our M digital systems, but with no news from M as to when, if or how MQA might be enjoyed on our systems.

Don't know whether/how it uses the information, but the 818v3 at least does seem to "know" what DSPs are connected to it (if you have used the config programme to set it up).

That is, if you do a "fetch" from the 818 into the config programme, then the info uploaded includes the speaker details. So it could do speaker-specific processing. Whether it does are not is another matter... does anyone know?

Steve

We have been told that the processor can do "DAC Management" through SpeakerLink. I'm pretty sure an 818v3 and all SE speakers work like that, but what other combinations do is unclear.

What about a 'plain' Sooloos endpoint with an MQA analog output, for those of us not using Meridian active speakers?

It's rather galling to see numerous MQA DAC products from various sources before Meridian Sooloos customers (with a considerable investment in hardware) have an opportunity to get MQA over Sooloos.

Whether this is as an upgrade or new hardware it would still be welcomed, although the 'Ultimate DAC' sounds very good it's not exactly affordable.

A firmware within each loudspeaker could 'potentially' depending on hardware, decode an encrypted stream or at least handshake to confirm it can accept a decoded stream over the comms before the processor will allow it to be sent.

T