I would have to disagree on the simplicity of this statement. It’s true a server can be a hard drive and computer but the software inside that computer is critical and anything but simple. Further, a server is also its user interface, a fact many people tend to overlook. I can tell you that after two long years of intense work on hardware, software and user interface, a server’s a lot more than something simple like Qnap. Though, technically your correct.
I’d just hate for people to think it’s actually that simple - at least what we’re trying to pull off.
To give you a quick example, one of the features of the hardware we’ve been laboring over is true galvanic isolation within the box - which is critical for sound quality. Our chief engineer, Bob Stadtherr, invented a new technology we’ll be calling an Air Gap Audio Interface. It’s stunning what this does.
I bought the QNAP some years ago as a business server, although I did briefly use it for music. Some of the first music servers used modified versions of Windows Media Server - a truly horrible application. The Naim server software (now replaced) was built by a couple of freelance techies and had a fatal SQL flaw. QNAP software is spectacularly complex, it does millions of things for systems from one standalone unit to thousands linked around the world. It has been developed by hundreds of engineers for millions of users over 20 years.
Many people use QNAP and Synology units as music servers, although with SSD rather than SATA drives. (My business unit has standard WD Red SATA.) There is discussion online about using galvanic isolators in the usb path, but the device I use (SSD inside an Aries Mini running Lightning Server) streams wirelessly. The Aries server runs off an external linear power supply fed from a PSA regenerator.
For computer sources, a very popular device over here, made in Germany, is the Mutec MC-3+ Smart Clock USB. There are a lot of cheap inline devices that many seem to think are generally useless.
Melco ran a “Streaming Masterclass” at my audio dealer last week. Maybe I should have gone.
I appreciate that computers introduce a whole range of issues with electrical noise at audio frequencies, which is why I’ve kept non-audio computers and electronics out of my system.
You’re doing fine and understand more than many. It’s a complex subject and much for many to learn. Most of the commercially based servers like Qnap (one of the best) use what is called UPnP/DLNA to communicate. This can be quite robust as a communication network and it’s what we started out with years ago. We have since moved to a more powerful language of communication because we realized some time ago that the power of a music server is held in the music management app that controls it.
Right. There will and there won’t. The standalone Octave streamer will be its own piece of hardware connecting to DACs through all the likely suspects: I2S, USB, coax and AES/EBU. There will likely be at least two standalone streamers, but for now, only the one with its built in SSD.
The new Bridge III will be a new hardware piece with the Octave operating system and will be available for existing DS DAC owners as a plug in like the existing Bridge II. You will be able to connect to a network share or NAS, or stream anything you want. Of course, it will not have a built in SSD.
Paul, it makes a lot of sense to have a standalone unit and an updated bridge.
The Aries Mini arrangement with the ability to slot an SSD drive in is brilliant. The more expensive unit requires it to be connected by USB. There may be reasons why, one may be is that it is a plastic case without a fan and runs very hot. That then requires a usb cable and another power supply for the hard drive …
Auralic probably also have an advantage in that they probably have a shed full of programmers in deepest South Korea. Their software is superb and regularly updated, but for various technical reasons they cannot get it to work Android, so it only runs on iOS.
I know of two well known companies that both spent at least 3 or 4 years working on streaming software and gave up!
@Paul Are you considering M.2 SSD format for Octave? This memory format offers far better performance compared to SATA SSD “drives” and use less power. They are common in laptops and also extreme gaming machines due to their speedy 4GB per second data transfer rate compared to 600MB (SATA SSD).
“Another language” is perhaps misleading in that it implies we’re rewriting computer language when we’re not. Better said would be that we’re building a complete closed loop system rather than an open source like UPnP. The difference is important because with our own system in place we can control every aspect of the user experience from how it sounds to how it feels to interact with the music. That’s something we’ve never had the ability to do and all we’ve ever done in the Bridge is use someone else’s protocols and metadata within our own loop. The loop was our own hardware which enabled us to produce great sound, but everything else (as in how you interact with it) was by a third party pasted together as best we could.
I made the decision some time ago to start from scratch and write our own system. It is running on Linux, which is an open source OS used by more computers around the world than Mac and Windows combined, but not so much on home machines (I am sure you’ve heard of it). With the freedom to do what we want and how we want, Octave is 100% under our control. That’s the part about our “language” that maybe wasn’t so clear.
Yes, thanks Steven. It is not easy to build something robust like Octave as the others who have thrown in the towel have seen. We’ve been down this road before with an older product called eLyric that we had to abandon because it turned into a money pit and something too difficult to pull off. But, we learn from our mistakes and this time around we knew what we didn’t want to do and how to pull off what we did want to do.
Octave will run on both Android and IOS tablets without a problem because we built the UI on a platform that easily adapts to both. Again, this was learned long ago through a great deal of pain and expense.
I don’t think it really matters which way we go with the SSD because the access speed isn’t a concern. Everything we do is loaded into RAM before we do it.
The key to Octave’s not caring about processor power or SSD speed is found in the hardware’s ability to decouple from the internal computer. Here we have invented a technology called AGAI which stands for Air Gap Audio Interface and physically disconnects all the noisy computer parts from the quiet output stage.
Yes - eLyric - I never got that to work. I always go for v2 and it’s good to survive the financial pain of v1, as some don’t.
The first proper unit I had was this: http://www.ava-media.com/zara.html
I still use it for occasional rips. It was made by a company that specialises in fanless servers, hence they could make the solid aluminium cases cheaply on their own CNC machines. It had 2 internal 2.5" drives acting as data and back-up drives, and the software also did differential back-ups to my QNAP at 4am daily. So the design was exactly as you would expect for someone designing a failsafe server.
There was no problem using SATA drives, even with 24/192 files. The main issues are of course write speeds for importing files, heat and drive reliability. Given the punishment a WD Red SATA takes (built for servers and recommended by QNAP), I wouldn’t worry about them in a music server.
The Zara unit is only 54mm high - about 2 inches. God bless.
From the above, I’m inferring that standard UPnP control point apps will not be able to control Octave (or eventually Bridge III) as the protocol controlling Octave will only be understandable to the new controller you are building for iOS and Android. Will Octave also be controllable via a browser similar to the sample web site (http://52.35.59.170/) which was referenced at the beginning of this topic?
I’d imagine whatever protocol you do devise (based on UDP?) would to be similar to the UPnP standards since session setup/teardown, browsing files, selecting a file or a streamer source, volume up/down etc., are standard actions you’d need to implement. However, with a brownfield approach you can augment/replace any protocol element wherever you think it makes sense to do so. Is this more or less correct?