I’m running a RopieeeXL into a new SMSL M500. MQA unfolds happening as expected. Before every MQA track, there is an audible “pop-pop” - it’s not terribly loud, but it is clearly audible and does cut off the beginning of each track by a short bit. This happens whether I’m hitting the play button or if one track finishes and the next begins. It happens whether I set track delay to 100ms, 500, 1000 or 1500 (I haven’t gone higher). It doesn’t happen with the same DAC on 16/44 content.
On some rock albums it’s not that distracting, but on most jazz or classical it’s terribly distracting/ unpleasant. Albums like Martha Argerich’s 24 Chopin preludes (quiet, short tracks) are terrible.
I’m guessing based on reading the thread below (about Gato) that this is a DAC manufacturer firmware issue; can someone confirm if this is right, and best way to go about addressing / if others have? I’ve written a polite note to Kelly, but I’m wondering if others have any ideas. Thanks.
I own an SMSL M500 and ran a few tests using the Argerich Chopin Preludes album available on TIDAL. The SMSL is fed by USB from a Sonore ultrarendu.
1- With the MQA capabilities set to “Decoder Only” or “Decoder and Renderer” (through Roon device setup), the pop-pop sound is heard at the start of the first track played, after playback is paused/resumed, or after switching to another track of the album. No pop-pop from track to track if album is streamed without interruption.
2. Setting MQA capabilities to “Renderer Only”, the glitch is heard only when starting playback. No glitch when pausing/resuming playback. No glitch if switching to another track of the album, or streaming album without interuption.
3.When switching from an MQA track to a track of a non MQA album, the pop-pop is head just once at start. Restarting playback or switching to another non MQA track does not produce th glitch.
4.No issue if streaming to a different DAC under the same conditions.
5. Adjusting the track delay makes no difference in all tests.
The problem you describe is apparenly related to the SMSL firmware and the way it handles MQA decoding… However, in my case, it does not occur at the start of every MQA track when streaming from the same album without interruption.
Never listened to any classical music but I tried the album you listed on tidal with MQA and experienced no noise or pops of any kind. Have latest firmware on SMSL running roon on a dedicated intel NUC through a marantz av7703. DAC is being fed from a windows 10 PC, using windows or android interface to control system. Roon DAC setup as render only core decoder on. No DSP on.
Thanks all. I did remove DSP (had been using binaural), and changed SMSL to renderer only. Unfortunately, unlike @Andre_Gosselin I still get it within a single MQA recording - so for opera or something else gapless it’s kind of unlistenable.
Do you mind if I ask what version of firmware you are running @Dominick_Puccio and @Andre_Gosselin? Mine is listed as software 1.7 and HW 1.3. The only firmware update I can find on SMSL’s site is for the M400.
For what it’s worth, when I look at the signal path during a track change, under “authentication” the blue line that says “MQA Studio 192kHz” blinks out and then back on, and the time that it is out seems to correspond exactly to the time that the pops/clicks/cutout happen.
Also…
Updated the USB firmware to 000138a1 via Ropieee dash, no impact on pops/clicks
tried pausing and skipping. Pop/click happens at pause and end of track, not just beginning of play and when one track goes to the next. Current hypothesis is that every time authentication starts or stops is when I get a click
Well, I’ve gotten somewhere. I turned off the core decoder under advanced, and set it to be a decoder and renderer, and now I’ve gotten it to the point where I hear the pop/click only when a new MQA format starts or ends but it us gapless/silent between tracks in the same format. That’s a lot better, and while not perfect I can live with this for a while.
Except… that meant i was skipping the final unfold. So that’s NOT going to work. Back to the drawing board.
I got mine from an open box on eBay, so I don’t have any recourse. However, it seems like I’m not the only one with this issue:
Not that I’m a fan of ASR, but they sure know how to kick the butt of a piece of equipment. I thought i had something when I tried to relocate the USB port to a 2.0 from a 3.0… but nothing!
So interestingly, the cutouts/pops only occur when bitrate of mqa is above 96kHz. For instance, Back To Black (Amy Winehouse) in 48/24 MQA 96 sounds lovely with no pops or clicks. Blue by Joni Mitchell in 48/24/MQA192 has all the clicks between tracks.
Hi @spockfish I don’t think this is a Ropieee issue, but I thought I’d ask. Do you have any experience with Ropieee having issues keeping authentication open between Roon core and an MQA DAC (in this case the SMSL M500) for momentary dropouts - only at high sample rates on MQA? (I haven’t tried high sample rate DSD yet, though I can).
The SMSL will only play MQA over USB. It’s like a number of less expensive DACs in that regard. It sounds like a nice but fairly inexpensive (read: dry, resolving, occasionally but rarely congested) DAC when not in MQA mode. I’ve been very interested in the sound in MQA mode, and trying to figure out if I like it or not, but the clicks & dropouts make it incredibly hard to listen for very long. And I’d love to pass from my Pi2AES to the SMSL on some other format than USB, but then I won’t get MQA so the exercise becomes moot.
I love my Gungnir Miltibit/Mjolnir 2 via SPDIF/BNC but that transport link won’t achieve the goal I want here.
Next, I can get the M500 to have that signal chain if I set it up as “decoder and renderer” as you have. And when I do, I get no clocks or pops. But the “dot” next to “MQA” on the m500 display is then blue instead of magenta. And for some reason I thought the “goal” was for it to be magenta, where it is just doing the final unfold. I can get it to be blue (as you have) no problem. But is that the right state to be in? If so, I’m home free. I find the documentation super confusing on this.
Below is the signal path I have, and what I thought was the “correct” one with Roon core doing the first unfold.
The problem you described is familiar to me. I use a Mac computer in my (ROCK) network that is connected via USB to a S.M.S.L amplifier. On another forum I was advised to choose a different USB port on the Mac. After I chose a different port, the problem was solved.
I thought I read that if the DAC hardware supports it, let it do both Decoding and Rendering. The SMSL M500 supports both. Moving the decoding to the DAC takes a processing load off the core. Which also is positive.
Also, my understanding is the blue light you are looking for is at the track level not necessarily at the DAC stage in the signal path. Look at my last image. You will see a blue dot right after track. “Precludes (24) for piano, Op 28, CT 166-189” also see the blue dot next to the endpoint Ropiee Family Room. My M500 also displays MQA which verifies it is processing an MQA file.
If I play these files on another non MQA endpoint I get a purple dot next to the track and endpoint name. Hence not the full MQA experience.
Note, if you employ DSP you will not see the blue dot. I suggest thinking of the blue dot as verification of MQA not necessarily of the best sound. For some people using DSP has benefits. For example, overcoming speaker or room issues. But if that is done you will never get the blue dot at the track level.
FWIW, I’m handing room correction through my AVR. I have 2 different settings. One for Home Theater and the other for music listening.
Wow, that all feels very anticlimactic - many many thanks to all who helped. I had thought that I was “chasing the magenta light” (on the DAC, not in the signal path) but apparently that was where I went wrong!
