It’s working again now…..a mystery
I hear what you hear, Paul! Keep going. It’s blissful. Your energy and passion are a gift.
Thanks, Philip! Trying my best. I was right in the middle of writing a post about this so let me copy and paste.
I get that everyone has their core beliefs and when someone comes along with a new idea that violates or questions those beliefs it can be very hard.
And we’re all different in the way we process those challenges to our core beliefs.
Crazy people like me want to rip those beliefs and “must be this ways” apart and see how much rings true and what we might be able to uncover. Others need solid proof. It’s all good.
It has always driven me crazy that different forms of digital audio storage and delivery sound different: same bits, different sound. That just doesn’t fly with me. If you think back so many years ago when Bob Stadtherr and I dreamed up and built the original Digital Lens. It was because it drove us crazy that CD player/transports sounded different. Yikes!
Then John Atkinson showed two different transports sounding way different, captured the bits and proved they were 100% identical. But sounded as from Venus and Mars.
There are two ways to deal with that evidence: deny the difference exists and chalk it up to listener bias, or figure out what’s going on. I choose the latter, and that’s how we figured out identical bits are one aspect—their timing and delivery quite another. Like comparing two photographs of identical crowds of people: they ARE identical in the final image, but you ignored the process of getting them through the queue and into the waiting room.
It takes crazy people and sane people to make everything work.
There is one additional point I’d like to add to my earlier response.
You describe Maestro’s design philosophy as “getting out of the way: the shortest, most inspectable path we can build between the file and the converter.” That’s a statement I find difficult to reconcile with the architecture you describe.
As you’ve described it, Maestro requires a computer or other device on the local network to terminate the incoming stream before forwarding it to the streamer. By definition, that introduces another component into the delivery path. With Qobuz Connect -and with many UPnP-based playback setups- the streamer retrieves the stream directly from the source without an additional playback engine in between. With Maestro, an intermediary is inserted.
Calling that the “shortest path” is inconsistent with your design philosophy. I prefer to keep the playback chain as simple and direct as possible. My streamer is already capable of receiving and reproducing a source bit-perfect stream, and I’d rather avoid introducing another computer into the signal path unless there is compelling evidence that doing so produces a meaningful improvement.
The hypothesis is that offloading network and decryption tasks from the streamer can improve analogue performance. However, that is quite different from “getting out of the way”. Architecturally, Maestro does the opposite: it places another machine between the music source and the playback device. Whether that trade-off yields an audible benefit is a separate discussion, but it is, by definition, not the most direct path.
If I implied a computer is required in the mix, let me correct that and apologize: there is no need for a computer for Maestro to play.
But the question underneath deserves a real answer, because it goes to the heart of what Maestro is — so let me lay out the whole picture, since “we get out of the way” is accurate.
First: there is no such thing as streaming without computers. The “direct” path from any service to your streamer runs through racks of servers, CDN edge nodes, your ISP, and your router before it ever touches your rack — the cloud is simply computers in someone else’s building. So the question is never “computer or no computer.” It’s two questions: what does each machine in the path do to the music, and how hard is your audio device working at the moment it converts bits to sound? Those are the two things that can reach your ears. Counting boxes measures neither.
On the first question, Maestro’s rule is absolute and we test it on every release: nothing in our path touches the samples. The bytes that leave the source are the bytes that arrive at your device — capture both ends of any link we add and compare them; that verification is part of how we ship.
On the second question — the delivery — Maestro runs whichever way suits your system:
No computer at all. Out of the box, Maestro hands your streamer a signed, direct line to the source and the streamer pulls the stream itself, running its own secure internet connection and decoding internally — the same delivery model as Qobuz Connect, on equal footing with it. The app on your phone is a remote control standing outside the audio path; if it fell over mid-album, the music would keep playing. If your streamer handles all of that beautifully, wonderful. The next mode is the one Connect has no answer to — and it’s where I believe we do better at.
A local node, by choice. Every streamer is really two machines in one box: an audio device, and a small network computer feeding it. Streaming directly — Maestro’s direct mode or Connect, same story — keeps that network computer busy: negotiating encrypted HTTPS sessions, running the decryption math on every packet, fetching in irregular bursts from servers a continent away, managing its buffers around an unpredictable internet. And it does every bit of this on a board that shares a power supply and a ground plane with your converter, inches from the clock that times your music.
The Maestro node takes that entire job away. It holds the encrypted internet session itself — certificate negotiation, decryption, long-haul fetching, all of it happens on a machine across the room — and re-serves the identical bytes to your streamer as plain, unencrypted, steady delivery across a few feet of your own network, with the next track already warmed and waiting. We verify the bytes are untouched on every release.
So why does it sound better? Here’s my best guess: cryptography, radio-frequency network churn, and bursty buffer activity next to a master clock and analog stages is exactly the kind of activity that has always separated a busy digital source from a quiet one. Maestro didn’t change the music. Maestro changed how hard the machine holding it works at the moment it matters. Think of isolating a turntable: nothing removed from the arm — the vibration moved away from the stylus. That’s the design, that’s the hypothesis, and the listening — mine and many of yours — is why I built it this way.
So “we get out of the way” was never about hop counts — by that measure a CD player beats everyone. It’s two commitments: no machine in our path alters the music, ever, and the device doing the converting does as little unrelated work as we can arrange. We don’t add anything to the music. We remove everything else. Your ears get the final vote — and both roads are open to you, which is rather the point.
As said, moving network processing away from an endpoint could plausibly have an effect in some designs. The question is whether that effect is large enough to be audible on modern, well-engineered streamers, and whether it is general enough to support your broader claim that Maestro sounds better than other delivery mechanisms.
Again, your explanation provides a plausible mechanism, but it still does not establish a general advantage. That distinction requires evidence showing that the effect is measurable and repeatable across representative playback systems.
I understand that “getting out of the way” refers to not altering the audio data. However, the local-node approach is not a simpler signal path; it is a more managed one that deliberately introduces another active component in order to change where processing occurs.
The turntable analogy is not quite equivalent. Mechanical vibration has a direct and measurable coupling path into a cartridge. The proposed path from network workload to audible analogue differences is much more indirect and depends heavily on the design of the endpoint.
Component count alone is not a meaningful measure of audio quality, a CD player is not automatically superior simply because it has fewer network elements. My point is not about the number of boxes, but about the distinction between removing processing from the endpoint and relocating that processing to another device. The local-node approach may be beneficial, but it is a deliberate architectural trade-off rather than simply “getting out of the way.”
The strongest defensible position is not that Maestro universally sounds better than other delivery mechanisms, but that it provides an alternative architecture that may offer benefits in some systems.
I think we have reached the point where we can agree to disagree and move forward.
Enjoy the project!
Thanks. I am and so too are many folks who, for whatever reason you choose to believe, are enjoying much better performance than what they previously had and, at the end of the day, that’s what matters and that’s what keeps me smiling.
Thanks for the challenging questions. Fun!
That makes good sense. Also, being willing and able to try for yourself at some point despite not knowing/understanding all the technical answers is what makes this an adventure.
It takes much less typing to try Maestro.
ahh you are a wise man … made me laugh
Given that the server/control point has no control over timing (clock), it’s only the delivery that Maestro can influence.
None of which applies to local content (which is all unencrypted), so the possible SQ benefits are limited to Qobuz.
Steady or bursty?
I haven’t tried with Qobuz yet, but local content is certainly bursty (delivering 82MB file in under half a second):
2026/08/07 07:44:10,669: UL01677: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,669: UL01678: T01e1c: TGHttp: Read one byte to determine file size.
2026/08/07 07:44:10,670: UL01679: T01e1c: TGHttp: HTTP Get : Begin: 0 End: 1 -1 Size: 1
2026/08/07 07:44:10,670: UL01680: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,670: UL01681: T01e1c: TGHttp: File size is: 85227216 bytes
2026/08/07 07:44:10,672: UL01682: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,672: UL01683: T01e1c: TGHttp: File size is already determined: 85227216 bytes
2026/08/07 07:44:10,672: UL01684: T01e1c: TGHttp: HTTP Get : Begin: 0 End: 1048576 -1 Size: 1048576
2026/08/07 07:44:10,674: UL01686: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,675: UL01687: T01e1c: TGHttp: HTTP Get : Begin: 1048576 End: 2097152 -1 Size: 1048576
2026/08/07 07:44:10,675: UL01688: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,677: UL01689: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,678: UL01690: T01e1c: TGHttp: HTTP Get : Begin: 2097152 End: 3145728 -1 Size: 1048576
2026/08/07 07:44:10,678: UL01691: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,680: UL01695: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,680: UL01696: T01e1c: TGHttp: HTTP Get : Begin: 3145728 End: 4194304 -1 Size: 1048576
2026/08/07 07:44:10,680: UL01697: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,682: UL01700: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,683: UL01701: T01e1c: TGHttp: HTTP Get : Begin: 4194304 End: 5242880 -1 Size: 1048576
2026/08/07 07:44:10,683: UL01702: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,685: UL01703: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,685: UL01704: T01e1c: TGHttp: HTTP Get : Begin: 5242880 End: 6291456 -1 Size: 1048576
2026/08/07 07:44:10,685: UL01705: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,688: UL01706: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,689: UL01707: T01e1c: TGHttp: HTTP Get : Begin: 6291456 End: 7340032 -1 Size: 1048576
2026/08/07 07:44:10,689: UL01708: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,691: UL01709: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
...
2026/08/07 07:44:10,902: UL01935: T01e1c: TGHttp: HTTP Get : Begin: 83886080 End: 84934656 -1 Size: 1048576
2026/08/07 07:44:10,902: UL01936: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,904: UL01937: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,905: UL01938: T01e1c: TGHttp: HTTP Get : Begin: 84934656 End: 85227216 -1 Size: 292560
2026/08/07 07:44:10,905: UL01939: T01e1c: TGHttp: HTTP Connect : [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,907: UL01940: T01e1c: TGHttp: HTTP Disconnect: [http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850]
2026/08/07 07:44:10,907: UL01942: T01e1c: Loading file done : http://192.168.999.999:8888/stream/951662a5-ae5d-4e09-a36a-0d5d72f1fe3f/d1b9d8139319258fd06287d89fa0e4ae9845a1bac902c1c7b24d33f841bf63bb/1786113850 (339 MB/sec)
2026/08/07 07:44:10,918: UL01943: T01afc: All loading finished.
2026/08/07 07:44:10,919: UL01947: T01afc: Loading 82 MB completed: 321 MB/sec
Though you imply that could be a negative:
Whilst the server could, to some extent (speed), control the delivery of the audio file to the streamer I doubt it’s advisable to force the streamer outside its design parameters.
I think you should just drop the bogus SQ claims as it’s more likely to alienate potential customers than convert them.
I wonder if you’d advise AirLens customers to use Maestro to improve SQ.
Sigh
I know. 
Best for me just to be quiet.
Unless I’m wrong?
Rise above the JPlay nonsense and sell the product for what it is, as there’s certainly a need for a decent control point on iOS and desktops too.
Oh no, why? This is another opportunity to substantiate your claim!
Have you taken the time to actually listen?
Look, I am going to stop trying to explain the differences because there are, as you correctly point out, too many holes in that explanation. I have been down this road far too many times.
Maestro began for a couple of reasons but chief among them was my unhappiness with Roon’s sound. And there’s a clear reason why Roon (and others) have that sound, which is the processing and reprocessing they do before throwing it back out onto the LAN for playback.
So, my hope is to build an easy to use, smart UI that eliminates the SQ issues I have and hopefully makes it easier to find and play fresh new music from the one source of streaming I find the best, Qobuz.
So, yes, I will stop trying to explain what I believe to be the differences.
The only real way to substantiate any claim of better sound is to actually listen and compare. Which is why there’s a one month free trial to see. Compare the sound to that of Roon, or Audirvana or JRiver. And if you notice the difference, if you appreciate what you hear, then it’s a win! If not, no harm, no foul, you’ve not invested a nickel and maybe you had fun.
I’ve compared it to MinimServer and there is no difference, nor can there be, as in both scenarios the renderer has the full - bit-identical to the original - track in under half a second, so how could Maestro continue to influence the sound quality?
Are these systems (Roon, Audirvana and Jriver) the basis for the SQ claims?
To be clear I’m only comparing Maestro (in ‘direct to device’ mode) to a normal UPnP server (e.g. MinimServer without transcoding) where there really aren’t any differences, unless you do down the JPlay route and claim that polling intervals can influence sound quality.
And it looks gorgeous! There are many issues with the local indexing, but if it ultimately delivers on its visual promise then I’m sure you’ll sell loads.
Thanks, appreciate it.
No, if you’re comparing to Minimserver on local files I would suspect you’d hear any differences unless you’re on Roon and then, as I said, there’s a decent improvement.
Thanks for taking the time to play with it!
I have been a long-term Roon user and purchased a lifetime subscription shortly after the product was launched.
I have always been very satisfied with Roon’s user interface and library management capabilities. In terms of sound quality, I consider it “No Bad” although in my experience it does not perform at the same level as some other playback software. This is one reason why many users choose to add HQPlayer to their Roon setup.
Do different software applications produce audible differences in sound quality? Opinions on this topic remain divided. Some listeners believe they do, while others believe they do not.
In Hong Kong, a listening session was held to compare Roon and JPLAY, with more than thirty participants attending. The results were almost evenly split, which suggests that perceived differences can be highly subjective.The listening test was conducted under blind conditions, and interestingly, fewer than 10% of the participants reported that they could hear no difference.”
Is Maestro better sounding than Roon? In my own listening, I “LIKE” Maestro, and that is why I have been willing to spend a considerable amount of time testing it. I know many other users here share a similar interest.
Are we biased because of Paul McGowan or PS Audio products? Speaking personally, the only PS Audio product I own are the AirLens & P20.
My view is straightforward: if someone cannot hear a difference, that is perfectly reasonable, and there is no need for them to subscribe to the software. If someone does hear a difference or, more accurately, has a different preference, then subscribing may be worthwhile for that individual.
This discussion is not limited to software. Many people also believe that network switches, cables, CD transports, Ground Boxes, Fuses and streamers do not make an audible difference, and such products are often described as “snake oil.”
Others, however, report different listening experiences. Ultimately, audio evaluation involves both measurable performance and personal preference, and reasonable listeners may arrive at different conclusions.