Ran

@Danny Kaey Thanks for the review. While my impression of streaming audio may be different than yours, streaming technologies will gain popularity as time goes by. Like the DACs of yesteryear, where reviewers mention that type of chip used (Sabre, AKM, TI, Burr-Brown, etc..) I find it appropriate to include information about the streaming module itself. It is obviously not a big issue but for some readers, this information is valuable.

Just for the record, I am not complaining... I stream redbook from my nas / qobuz 95 percent of the time. I don't care so much for all the specs but I do wish to get some transparency from the companies that make streamers. How many times did I see things like "we built our own Linux OS" or "We optimized the OS to our needs" or "We built the streamer from the ground up" only to find out that it is far from the truth.

Depends what you mean by services. I have a Pi3 that runs PCM audio up to 32bit / 384kHz, DSD x 4. It runs mpd / upmpdcli in the background and can run Roon as well as Spotify connect if I want to. It does all these via Ethernet.

Raspberry Pi does it without an issue. TI offers many boards that do that as well.

This is a classic case where a company just integrates a 3rd party module into their product. For $28.5k I would expect them to get a better board that does not have any restrictions compared to the USB input. Companies should be transparent about it by just saying "we built a great device but the streaming board was made by someone else."

UPnP / DLNA? OpenHome? This is a streamer as well, right?

Is there a stock reply I can use to complain about this? Did anyone send a compliant to a label before?

Decca Records drank the kool-aid. Now with MQA CDs: https://shop.decca.com/British-Jazz-Explosion/*/The-Complete-Fontana-Albums-1961-1969/66FO00000Y7

The issue it raises for me is that not one reviewer was able to detect the issue with gapless playback. It took less than 2 minutes to figure it out. Imagine a reviewer noting in his review that a product lacks some functionality... It would have caused the manufacturer to act upon it. Most of the issues are found by consumers after products are released. It should not be the case.

Hi All, I was a bit disappointed to find out that the H590 does not support gapless playback via DLNA. A product in this class (and price range) should not have left this feature out. Please help get the message to the Hegel team ([email protected]) and ask them to fix this in the next firmware release. Thanks!

When Bob says the "analog sound in the air" you know he is about to sell you something.

You have the explanation in your first post. But in general, MPD will read the data from a buffer. The buffer provides a predictable data set to work with. This happens when you stream via ethernet or access the audio via the file system, like USB. The buffer will always be faster than the audio sources as it is local to MPD (running in memory). Things to consider: 1. Is your external drive SSD or magnetic? 2. Do you get this issues when streaming form the net or a NAS? 3. Is your external drive powered by the SMS-200 or by an external power supply? If you know the answer to these three points you should experiment around them to see if the problem goes away.

OK, If you do not know what SSH means, trying to parse MPD logs will be way to much to handle. Try contacting May Park for help. You can also try using Roon / HQ Player instead of MPD to see if the problem disappears. These options are avaialble from the web based menu of the SMS-200. http://docs.sotm-audio.com/doku.php?id=en:eunhasu:start#services

You will need to get the user / pass from SoTM. Then, ssh into the SMS-200. You can get all the details from SoTM.

The buffers in MPD have got nothing to do with bit depth and sampling rate. Log into your SoTM device and view the log when the issue happens.