Has anyone heard the Devialet D-Premier Integrated Amp/DAC

Hi Orb. None of that matters . Answer is still very much the same.

I mentioned the TCP bit as a clarification to your answer, not in the sense of a proof point that networ jitter is not material. UDP has an advantage over TCP when we stream A/V data over the Internet in that it doesn't have forced retransmissions as TCP does. On a LAN at home, it is not going to matter due to very low latency and much higher reliability (relative to the Internet). So this distinction is not material to anything we are talking about.

The key thing here is that your music player has *no* error mitigation. So it has no mechanism to change the sound as VOIP would. If it runs out of data, it simply stops playing. In other words, your data is either 100% there or not. Lots may happen on your network but to the extent the player buffer has data to fill, it will be drained using its high-precision clock oscillator, not the network arrival time. What happens on the network side simply decided whether you will run out of data or not and hence glitch. It cannot impact audio fidelity directly.

We call the above pseudo-real-time. The process of playing audio is indeed real-time. Our network however by definition is not real-time. So buffering is used to decouple network glitches -- drop out, jitter, or whatever -- from the real-time end of the pipe.

I have to run but happy to explain more when I get more time.

I am not sure Amir, especially if following the links on RPC
I guess one could argue all their jitter buffers,etc relate to VoiP, however in different sentences those link then goes on to streaming solutions.
The point is, udp as pointed out in one of those links is used as a fire and forget to improve speed/latency/etc.
I do not understand how you can say there is no mechanism and no error mitigation, even Ciscos Digital Media Player makes reference to this,jitter, and buffering to assist - this is an audio-visual streaming product for dnla solutions.
Regarding codecs not sure what you mean Amir, as both VoIP and streaming must utilise codecs.
I am not how that distinction is made Amir about real-time apart from just as a technicality for VoIP but not actual from a technological solution, both types (VoIP and streaming) require synchronisation; yes it has greater flexibility than VoIP but it still conforms to streaming principles, not remote reading-downloading of a file that is then processed locally.
If someone stops talking there is no data but the session stream is continual, the same goes with an audio stream in that if someone stops singing it is still streamed, both still must maintain synch and use timestamps.

Anyway, it seems to me maybe we are approaching this from a technical semantic perspective, but I stand by those RPC links I provided and prefer not discuss differentiation on terms relating to real-time and streaming, as both use UDP and both showing similar design principles and considerations.
But Cisco clearly comments on their player supporting error mitigation as you say, consider IPTV that is same as audio streaming in the context of solutions such as Airplay and other unicast-multicast solutions.
To quote RTP that is used:

RTP is designed for end-to-end, real-time, transfer of stream data. The protocol provides facility for jitter compensation and detection of out of sequence arrival in data, that are common during transmissions on an IP network.

Click to expand...

The following link explicitely shows the types of RTP payload; codec-clock-standard-description.
This shows both classical voice telephony and also streaming technology such as what would be used by Airplay and other solutions.
http://en.wikipedia.org/wiki/RTP_audio_video_profile
Real-Time Transport Protocol is applicable to both VoIP type and streaming technologies and solutions, which is why trying to differentiate this on the real-time term is IMO not advisable, it comes back to the timestamp-sync-clocks-codec as can be seen in that link and is applicable to both.
Thats my take on it anyway, and as a typical forum poster... I stand by it!!!! hehehe
OK I appreciate the reality may be between both of us.

But, for an audiophile.
If someone already owns a quality solution around Int202-firewire-MAC, unless cabling is an issue (which hopefully should not be with remote control IPAD) it still IMO is not advisable to replace a high end quality solution with something else that can work but at some point end up with contention-interference from other frequency band related products, which cannot be guaranteed, and possibly also consideration of the complete and complex end-to-end architecture of a streaming solution (the benefit of Airplay makes this simpler but if problems do occur it may - needs to be emphasised - require reasonable understanding or assistance).
Still, I feel most will never want to know or should need to know the underlying technology and architecture for streaming audio; they just want to play the music but in the context of what we have been discussing it is a potential consideration for complex issues.

Cheers
Orb

Orb said:

I am not sure Amir...

Click to expand...

I feel like reciting part of my resume as to have you have more faith in my explanations . I landed at Microsoft in 1997 because we sold our start-up which was a pioneer in video streaming on the web when a 28kbps modem was the fastest way to get on the web! Needless to say, being able to do video at such rates where you could not do audio with high fidelity was quite a challenge. So we built a streaming server which deployed RTP plus a ton of secret sauce on how to optimize traffic such at that it would get to the other side of that narrow pipe.

That technology later become part of Microsoft's streaming solution which by now has served up hundreds of millions of streams.

In addition, my compression team built codecs and signal processing models (e.g. acoustic echo cancellation, error concealment, etc.) for our real-time collaboration group at Microsoft (audio/video conferencing).

Net, net, this is a topic near and dear to my heart .

Let's talk terminology a bit. The kind of jitter we worry about in digital audio is the DAC clock signal varying in an attempt to track the source. These variations are measured in pico and nanoseconds basis and occur pretty fast. That modulation of clock frequency is necessary as the source is the master in our audio systems and the DAC, the slave. Connections such as S/PDIF do not allow the downstream device to signal anything upstream. Data comes its way and it must play them or else.

Network jitter is the notion of packets of data arriving at different rates than the real-time device consuming them at the other end. Imagine a worst case scenario of us having no extra buffering and only playing one packet at a time. Our player DAC would retire data at a certain rate and if the next packet arrived too late, we would run dry and cause a glitch.

The solution to above is twofold:
1. More advanced networking schemes to reduce impact of jitter. There are countless papers on this topic including those you hit on such as using UDP as to better manage what goes on the network. For these people, network jitter is a big deal and one that has to be dealt with.

2. Hiding the fact that the receiver is out of data. Since in conferencing applications we only care about intelligibility and not fidelity, different tricks can be used to interpolate or synthesize what is lost. This is special piece of signal processing that helps with reconstruction of speech when we have pieces missing.

In our music streaming application, the first factor simply is not there. Our home networks are far faster than what we are trying to play. When it falls behind due to connection drop, it can catch up very quickly. We can do this because at the extreme, we can read the entire 3 minute piece of music as the rest of the data is just sitting there on the remote server. Not so with conferencing. We cannot get faster than real-time and encode the future audio/video frames. Some amount of buffering does exist even in conferencing application but is nowhere near what we have in music streaming.

Since running out of data is a rare thing in music streaming, there is no signal processing to mitigate running dry and out of data to play. If this happens, we simply stop playing. Yes, the networking subsystem may be smart (usually isn't though) and try to deal with maximizing the throughput over the local network but at the end of the day, all it is accomplishing is us glitching less often.

Importantly, in music streaming, the DAC has a constant frequency clock. In no case does it attempt to adjust its clock based on incoming data rate over the network. So jitter over the LAN connection never translates into jitter of the DAC clock -- the distinction I have been trying to make relative to local playback.

So what the network subsystem does or doesn't never has any fidelity impact on the receiver. It can cause glitches, increase or decrease start-up and recovery time from packet losses, but it does not impact your audio fidelity. In contrast with more real-time applications such as conferencing, we do not attempt to mess with the receiving end to make up for deficiencies on the network.

If someone stops talking there is no data but the session stream is continual, the same goes with an audio stream in that if someone stops singing it is still streamed, both still must maintain synch and use timestamps.

Click to expand...

Timestamps and such are used for synchronization of audio/video. It is a complex beast but outside of the scope of what we are talking about here. Again the key thing here is that we do not change the DAC clock in response to network traffic. We couldn't anyway as DAC clock control is not programmable under software that way.

But Cisco clearly comments on their player supporting error mitigation as you say, consider IPTV that is same as audio streaming in the context of solutions such as Airplay and other unicast-multicast solutions.

Click to expand...

IPTV constraints are far more extreme than music streaming. People do not want high delay and at any rate, for live TV, you can't get ahead of the programming as you can when you are streaming local files from a remote server.

I understand your background Amir and also mine is engineering involving protocols-network architecture (not talking about basic network designs but specific protocol-architecture developments) in the distant past.
However I am using those links as they are independant, I am not sure what we are actually discussing here now but potential semantics and very narrow-explicit situations with their definitions
I think we can put to bed the aspect of real-time-VoIP, technically not asynchronous, and streaming comparisons that rely upon building the clock sampled data from the packets (technically very similar as seen in the reliable links), so it seems to me this has become a discussion-debate more on jitter from a technical standpoint and comparing network orientated to classical noise and signal related periodic jitter as seen in traditional products.
So it seems to me we are moving away from the point of why someone with an Int202 as I suggested should stay with his existing product; cannot guarantee reliability and for audio quality can be compromised (however I appreciate you want to define and validated as it can only be compromised by glitch-interruptions and seems this is where the discussion is now going).

I still cannot see why you continue differentiating between video conferencing and streaming; as I have shown with the various links they use the identical protocol implementation and solution for audio and video data- RTP, with both technically real-time in terms of buffering and time constraints once the end device starts playing.
I understand the suggestion that you can send megabytes of data at a time but the receiver must be able to reconstruct this in the same way as dealing with say video conferencing, but again this is limited to the receiver device and both its processing power-network application-protocol architecture, and memory, in end devices this is quite finite.
However the key point is that once the end device starts to reconstruct and play the music, it is then reliant on timing constraint just like VoIP, as you say the crux is when it starts to play, buffer size and end device capability in terms of managing and processing this.
One important difference is latency,delay is more important to VoIP I agree.

I think we may also be coming at this from slightly different persepectives and context.
I have been discussing this from the perspective of a service that must work with a potential issue on Wifi, and importantly with a limited end device-receiver (such as that possible by the Devialet, Airport Express-TV,imbedded Digital Media Player,etc) that are not PC-Macs-Ipad-etc.
From this perspective the greatest functionality and resources is on the streamer (sender) that will be a PC or Mac, where the issues will not arise.
So the scenario I am discussing from is not going to be same as a traditional Web server to PC running a full OS-architecture on a wired connection without wifi issues as discussed earlier.

Any retransmits, loss of a few packets, out of sequence packets,delay can have a detrimental effect once the end device starts playing.
Again IPTV is a valid comparison, it is an audio-video streaming solution and technology in the same way you are talking audio, that also utilises buffering and is traditionally built upon the same protocols that being RTP or those similar to it.
If in any doubt about its validity in such discussions, consider Airstream and Apple that supports both, again the protocol and architecture is nearly same for both.
Both will require some kind of buffering, both can suffer jitter, however this discussion is now getting hung up on one very specific aspect, which really should go to a different thread because we could take pages with technical whitepapers debating this
BTW I am not disputing the audio glitch buffer underun you explain as jitter, just that there is more to the end device than this type of problem and that there is error concealment inbuilt to these streaming clients, that is applicable to other associated problems along with the buffer underun that could be subtle or large audio interruption.

I could post many more relevant whitepapers,articles that will continue to iterate what I am saying, however I am not disagreeing with the one point you are focusing on with jitter, but the discussion and scope involved in audio quality is much more than that one definition and does comes back to some of my very original points that did also involve VoIP and audio quality, and all the links are valid to this discussion as a whole (meaning not ignoring them because focusing on one narrow scenario and definition at the expense of everything else).

This discussion is starting to feel like ones I have had with JJ where it is basically pointless as both parties are correct technically, while everyone else switches off pages ago
I think we have just shafted this thread Amir, of course I blame you
Joking both of us are to blame, but I am going to stop now otherwise it will really ruin this thread and I get the feeling most do not care what we are discussing and debating.
Thanks for providing an interesting discussion though (well I found it enjoyable and thought provoking anyway )
Orb

Orb said:

I still cannot see why you continue differentiating between video conferencing and streaming;

Click to expand...

Because they absolutely work different even though on surface they all send audio/video to the other end points. The application requirements dictate system performance and operation.

as I have shown with the various links they use the identical protocol implementation and solution for audio and video data- RTP, with both technically real-time in terms of buffering and time constraints once the end device starts playing.

Click to expand...

As I noted, much of streaming in a LAN is not done with RTP. It is simply done on top of TCP transport. But even if RTP were used, it is not material to the performance point at hand: that DAC click jitter is not determined by any choice made there.

I understand the suggestion that you can send megabytes of data at a time but the receiver must be able to reconstruct this in the same way as dealing with say video conferencing, but again this is limited to the receiver device and both its processing power-network application-protocol architecture, and memory, in end devices this is quite finite.

Click to expand...

There is no reconstruction in music streaming. You get get the data and you play it. If it doesn't arrive, you do nothing and pause the audio.

Video and audio conferencing can also work that way, or have the error mitigations I explained.

However the key point is that once the end device starts to reconstruct and play the music, it is then reliant on timing constraint just like VoIP, as you say the crux is when it starts to play, buffer size and end device capability in terms of managing and processing this. One important difference is latency,delay is more important to VoIP I agree.

Click to expand...

No disagreement. There is buffering in all. It is the constraints which are wildly different in one application where I could read ahead 1 minute of a music file from a server, whereas in the conferencing application I better not get ahead of 0.1 seconds or the interactive delay becomes unacceptable. This lower latency requirement makes the job much harder in that your network now better track your playback rate much closer. If I buffered 1 minute, and you turned on your microwave for 30 seconds and my wifi link stopped producing any data, I am still OK. Do that with VOIP and you won't hear the other site for many seconds.

I have been discussing this from the perspective of a service that must work with a potential issue on Wifi, and importantly with a limited end device-receiver (such as that possible by the Devialet, Airport Express-TV,imbedded Digital Media Player,etc) that are not PC-Macs-Ipad-etc.
From this perspective the greatest functionality and resources is on the streamer (sender) that will be a PC or Mac, where the issues will not arise. So the scenario I am discussing from is not going to be same as a traditional Web server to PC running a full OS-architecture on a wired connection without wifi issues as discussed earlier.

Click to expand...

This is not a real consideration in practice. Most of these devices run full blown operating systems such as Linux and as such, act like a PC receiving the data. Indeed, this higher horsepower end point is the reason you might have higher levels of jitter as I mentioned earlier -- not because of the network activity itself.

Sure, comparatively, these devices have far less horsepower than a modern PC but they don't have to do as much work either.

Any retransmits, loss of a few packets, out of sequence packets,delay can have a detrimental effect once the end device starts playing.

Click to expand...

They can. But as I explained, they only cause glitches in music streaming. They do not change the *fidelity.* Audio data is either there to play or not. It is only in VOIP and conferencing where we try to make up for missing or late data with new audio samples that can cause fidelity to change.

Again IPTV is a valid comparison, it is an audio-video streaming solution and technology in the same way you are talking audio, that also utilises buffering and is traditionally built upon the same protocols that being RTP or those similar to it.

Click to expand...

Again, the constraints are very different. With a live channel feeding an IPTV encoder, I cannot buffer for 30 seconds. If I did, you would change channels and wait 30 seconds to see anything. They have to match cable and satellite and start playing in a second or so. That makes them far more sensitive to network performance especially since they run over a wide area network and not your local, low-latency home network.

If in any doubt about its validity in such discussions, consider Airstream and Apple that supports both, again the protocol and architecture is nearly same for both. Both will require some kind of buffering, both can suffer jitter, however this discussion is now getting hung up on one very specific aspect, which really should go to a different thread because we could take pages with technical whitepapers debating this

Click to expand...

Again, a key point is that network jitter <> DAC jitter. Try to find a report that says either one of those devices change the clock frequency of the DAC in response to network "jitter." You won't find one reference. So yes, network jitter exists and is a fact of life. It means that packets of data arrive when they do and they do not match the rate that is being used to play them. There are countless papers discussing how to make network delivery smoother over unreliable and slow links. None of that however, is an audiophile concern because at the end of the day, it is a reliability of the system, not fidelity.

This discussion is starting to feel like ones I have had with JJ where it is basically pointless as both parties are correct technically, while everyone else switches off pages ago

Click to expand...

I am hoping this is nothing like discussions with JJ in matters of audiophile topics . You know that the strong position I take in eliminating jitter from audio systems. So if there was any reason to worry about "network jitter" also raising DAC jitter, I would be first in line to make that claim . But there really is not. The DAC clock in a streaming system is the *master* clock. It gets set to the rate that it needs to run at and then the network system has to slave to it and feed it data or else, you stop playback. It is as simple as that. It doesn't require understanding anything in the networking stack. That subsystem's job is to deliver bits and if it doesn't, you will just stop playback in music streaming.

In hardwired connections like S/PDIF, the source is the master, not the DAC. That is why we have issues of jitter getting inserted into the DAC. The source jitter pollutes the DAC clock. As I have mentioned a number of times, this simply cannot and will not happen with network delivery.

The down side is the increased activity in the player which may cause increased jitter on its own. So you trade off source induced jitter for locally induced jitter. That's why for now, I like async USB because it is asynchronous by design yet much simpler to implement in the DAC.

I think we have just shafted this thread Amir, of course I blame you Joking both of us are to blame, but I am going to stop now otherwise it will really ruin this thread and I get the feeling most do not care what we are discussing and debating. Thanks for providing an interesting discussion though (well I found it enjoyable and thought provoking anyway )
Orb

Click to expand...

Given the network interface on this device and the choice of using it vs not, it is very apt discussion I believe. The complexity here is rather high but I am hoping the simple conclusion is not.

Orb said:

I am not sure Amir, especially if following the links on RPC
I
But, for an audiophile.
If someone already owns a quality solution around Int202-firewire-MAC, unless cabling is an issue (which hopefully should not be with remote control IPAD) it still IMO is not advisable to replace a high end quality solution with something else that can work but at some point end up with contention-interference from other frequency band related products, which cannot be guaranteed, and possibly also consideration of the complete and complex end-to-end architecture of a streaming solution (the benefit of Airplay makes this simpler but if problems do occur it may - needs to be emphasised - require reasonable understanding or assistance).

Click to expand...

Being an engineer myself (originally mechanical now in software) I can't deny that I am interested in technology (and my interest for the D-Premier started there) but listening to music is meant as a relaxation and the - be it remote - possibility of having to trouble shoot my wifi network instead of listening to my favourite Anouar Brahem rip tires me already.

Based on my limited knowledge of the stratospheric parts of high end audio, I find my system to sound amazingly good, that is before applying 5.3 to the D-Premier and with my old B&W 804s speakers. I'd be amazed if wifi could be much better than the Weiss over firewire. I'll probably give it a try but am very unlikely to keep using it.

Perhaps I don't deserve to post here.

Cheers,
Bernard

Bernard of course you deserve to post here, its me and Amir that need to go into the sinbin for 5 mins
Amir, I meant the JJ comment more in a humour-positive way, have quite a bit of respect for his technical posting skills (not necessarily the ones where he flips out at audiophiles ) where he can argue and yet reading the details carefully it does not disagree from the other poster.

Bernard, let us know how you get on with 5.3 , Amir may even be interested in the product again with that soft-firmware

Cheers
Orb

Another nice review, this time by Soundstage and Doug Schneider, measurements again impressive.
http://www.soundstagehifi.com/index...ier-dac&catid=55:full-length-reviews&Itemid=4

Cheers
Orb

Just back from the Devialet day at Oxford Audio Consultants in the UK - hosted by Jon from OAC and with representatives there from Devialet and Absolute Sounds.

It was a 300 mile round trip for me but worth it as it was easy to spend 6 hours listening to the music and hearing about the device and future plans.

One room was a single Devialet with Audio Research CD8 CD Player and SF Cremona speakers; the other room used two Devialets in dual mono configuration with either Metronome One CD Player or SME 20/3 turntable and Wilson Audio Sasha W/P speakers. In addition that room was used to demonstrate the use of a Mac Book Pro as the music source.

The current software release 5.3, just out, paves the way for the configurator (a web-based interface allowing the owner to make personal input and output settings and names, amongst doing other things) and the wifi facility - due in a few months' time.

The reviews from HiFi News, HiFi+ and HiFi Choice in the UK, and even from the Financial Times, plus English language overseas reviews from Tone Audio and from Soundstage, say much about not only the sound quality but also the remarkable technology and the beauty of the kit. Most, if not all, of these reviews are on the Devialet website.

Once the wifi arrives, for those who want this route, one can now get exceptional sound quality from the Devialet, a Mac Book Pro and an iPad (and loudspeakers and a turntable if you have one) - and replace 6 power cables with 2, 6 signal cables with 1, and perhaps 5 cubic feet of kit with less than 0.5!

An expensive unit - yes - and one with only four or five UK dealers - but if you are in the UK even if you are 150 miles away from OAC, as I am, well worth the journey if you have serious interests and serious money.

Thanks IanG,
yeah it can be a pain to hear due to the restricted dealership (I do like how Absolute Sound manage-support product deployment instead of just flooding products to any dealer).
As an early adopter I used one of their dealers who are happy to visit your home with products so they can be heard with ones speakers (saved travelling down to Devon way), that said it may had been possible for me as they travel to London pretty often.
If I remember the Metronome One does not or did not support digital XLR and surprised they used that for demo, from a buying perspective a strong contender IMO for "high end" transport would be the CD5 instead of the CD8, much cheaper while still having all the important connections (including digital BNC), wish I thought of it before going all expensive with a Metronome transport - looks lovely I agree but possibly no need for it and CD5 makes much more sense.
Just in case those in the UK did not know, you can order Audio Research gear without the handles, which I prefer the look of I must say.

Cheers
Orb

Hi Orb
I guess you got yours from Pinewood?
For me, Pedro from Absolute Sounds was happy to bring the Devialet to Yorkshire twice - once to demonstrate and once to deliver - because Jon from Oxford Audio Consultants was away on holiday. Excellent service.
I'm using the Devialet currently with an Audio Synthesis Transcend transport which has SPDIF, Toslink and AES/EBU (XLR) outputs - I mainly use the latter. In due course I will try the Mac Book Pro either with the Firewire connection or the (soon to be released) wifi facility. This will be great, operationally, if the sound is good - operating everything from one's listening position with an iPad.
I believe the online configurator is out at the end of this month and the wifi at the end of September.
IanG

Yeah I did, really nice people.
But glad there are more dealers spread out now, and great service-support as you say with Absolute Sound
For me, I found the digital XLR to be subtly better than SPDIF using cable from the same company.
Cheers
Orb

5.3

Hi Orb and Devialet owners,

Fyi, I have finally had my early D-Premier upgraded to firmware 5.3.

It is obviously difficult to do comparisons since you cannot easily go back, but 5.3 for sure appears to sound significantly better still, which is pretty impressive considering how good it sounded before the upgrade.

I have a hard time wording the difference, but it seems even faster and more controlled accross the range.

I have also completed the replacement of my old Esoteric X03-SE by a Nuforce/Oppo BDP-93NXE bluray universal player which pretty much ends this 6 months period of intense system modifications.

The one and only remaining open question is speakers but that is another story all together.

Cheers,
Bernard

Maybe there is a firmware upgrade for the speaker too!

Sorry, could not resist.

amirm said:

Maybe there is a firmware upgrade for the speaker too!

Sorry, could not resist.

Click to expand...

I'd love that to be true!

To be fair for B&W, I would never have imagined that the 804s could sound so good when I was using them with my previous pair of Nuforce Ref9 V3SE and Esoteric SACD players, themselves considered to be pretty decent components.

Considering that the 804s are roughly a 10 years old design and that speakers have probably progressed more in that period than in the 30 years before, I am really excited about how good the whole thing could be with the current best offerings in the same of slightly higher range.

On the other hand, the 804s's tweeter is extremely good already, the problem is more with the overall coherence of the delivery and with bass control.

Exciting times and you've got to love the freedom of being totally free of any brand loyalty, sorry B&W, I'll probably go see somewhere else next.

Cheers,
Bernard

Configurator now available

For those interested, it is now possible to do full config of the D-Premier thanks to their online app:

The outcome is a file that needs to be stored on the SD card controling the unit.

http://www.devialet.com/configurator/

As part of this, both dual amp and dual mono modes can also be set up for the lucky ones owning 2 D-Premier.

Cheers,
Bernard

Thanks for the headsup Bernard,
I wonder how many of us are going to tinker away in moments of boredom
Cheers
Orb

Yep, indeed.

On the other hand, I recommend an AV amp for the really bored people. The potential for tuning (and for messing things up so bad that no sounds comes out anymore) is yet another order of magnitude over the D-Premier.

My former AVP-A1HD pre-amp from Denon required 2 PhDs to fully tap into its potential...

Cheers,
Bernard

Just had a look at the config tool and it looks good, crossover for sub is limited to 5hz increments but looks like has a choice of filter order used, and other options look handy for other aspects of the Devialet.
Overall looks pretty easy to create the config file from it and tinker if one wants to.
Key if some have not been following is that it relies upon 5.3 firmware.
Here is the webpage to define the configuration one wants:
http://www.devialet.com/configurator/

Seems it may be some kind of scripting language-parameters, may be possible for the techno savvy to do the configuration without the tool, but I cannot see the point in trying IMO

Cheers
Orb

Has anyone heard the Devialet monoblocked? i now have...quite impressive. I will say that once i dropped the sound volume to low levels, the balance got thrown off, and i lost a lot of detail...which does not happen on my system on the same track at home. That was disappointing. However, at moderate to fairly loud levels, the sound was quite impressive and much fuller than a single Devialet. Cranking the volume again led to some bite that felt like the beginnings of distortion. Of course, i was comparing to Krell monos, so that's a totally unfair comparison given that the Devialet is DAC, pre and amp in one. That said, for 25K, it probably would be fair to compare the Devialet mono'd to an ARC DAC7, ARC REf 3 and a pair of Belles, Hovland, Musical Fidelity or Bryston amps...or ARC DAC + Dartzeel integrated?