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

[Orb]

Addressing Frank's point, we have commercial 3-phase power. I know that power conditioning does improve amplification sound in that setting as we temporarily tested our Mark Levinson 532H that way. We did not however use that in this comparison. And of course, the other gear is performing as it did in the comparison without any help.

I do not know if you feel the same Amir, but for me it should be excellent without the requirement of power conditioning, which may be best excluded when evaluating products as it should perform as stock without assistance (for me this means not using exotic power cables for the audition).

Thanks
Orb

 

[bernardl]

I do not know if you feel the same Amir, but for me it should be excellent without the requirement of power conditioning, which may be best excluded when evaluating products as it should perform as stock without assistance (for me this means not using exotic power cables for the audition).

Thanks
Orb

I did for sure notice a clear improvement when I replaced the stock power cable of my D-Premier by an Esoteric 7N-PC7100.

Cheers,
Bernard

 

[mep]

I did for sure notice a clear improvement when I replaced the stock power cable of my D-Premier by an Esoteric 7N-PC7100.

Cheers,
Bernard

Did you try having your power cord cryogenically treated? Cryogenically treating metals makes them sound so much better. It improves the molecular stability of the sub-atomic particles which allows the electrons to flow much easier as they travel through the crystalline lattice structure of the wire. The differences in sound quality between something that has been cryogenically treated and something that has not been treated are profound.

However, it should be noted that in order to hear the benefits of a cryogenically treated power cord to their full-effect, you must use cable elevators with the power cord. Failure to use cable elevators and letting your cryogenically treated power cord to come in contact with the floor will introduce random molecular chaos caused by the capacitive force field generated from static discharges as the floor varies between an insulated and charged state. This can result in Frank Zappa sounding like Jennifer Warnes.

 

[bernardl]

However, it should be noted that in order to hear the benefits of a cryogenically treated power cord to their full-effect, you must use cable elevators with the power cord.

I have not tried cable elevators, but I did try elevator cables and was not too impressed.

Cheers,
Bernard

 

[bernardl]

D-Premier gets Blue Moon award

For those who haven't read this yet:

http://www.6moons.com/audioreviews/devialet2/1.html

Cheers,
Bernard

 

[Orb]

Thanks Bernard,
great review with the technical aspects.
BTW you installed that new firmware 5.3 they mention?

Thanks
Orb

 

[bernardl]

Thanks Bernard,
great review with the technical aspects.
BTW you installed that new firmware 5.3 they mention?

Thanks
Orb

hi Orb,

Not yet. I have a very early version of the D-Premier and my dealer needs to change a logical board to enable the update.

I hope it can be done next week or so. Not sure whether he will already have the wireless board, but I currently do not intend to use it.

Cheers,
Bernard

 

[microstrip]

Nice review, but unhappily there is not a real picture in the reviewer's system of the unit in the proper position - suspended in a wall like a painting!

BTW, I am now wanting to re-listen to the unit - my previous critcism was addressed:
>Prior power delivery had been somewhat conservative. With the new version a more generous supply improved LF response. The slightly bright top was subtly rounder to eliminate the edge. - from the 6 moons review.

 

[Orb]

Bah maybe I should contact Absolute Sounds here in UK and get my early one refitted, thanks for the headsup Bernard (and Microstrip for picking out that line I missed in the review) as I did not know what was involved.
I do wonder though if they improved the power output done by the Class A amp into the high frequencies comparable to the the LF response - maybe some software protection was being enabled due to the low output spec of it.
Ah well and would tie in with what Amir was possibly picking up as the Class A and the Class D are independant when it comes to the FR and power they can provide.

Hehe I knew I would probably end up having to do the same as you Bernard for buying very early on with the Devialet
Cheers
Orb

 

[Orb]

Contacted AbsoluteSounds distributor here in the UK and the good news is they will also be doing the upgrades in the very near future (will be able to start the process hopefully 2-3 weeks from now) for these early models.

Cheers
Orb

 

[bernardl]

Contacted AbsoluteSounds distributor here in the UK and the good news is they will also be doing the upgrades in the very near future (will be able to start the process hopefully 2-3 weeks from now) for these early models.

Glad to read that Orb.

I should get mine installed this Friday.

The wireless card is planned for delivery in September I hear. I am still unclear whether I would actually use it or not, but I'll for sure have it installed.

My concerns would be:
- stability of the wifi connection. My current set up based on Int202 is totally idiot proof with zero issues I could hear in 6 months of usage, I don't want to go back to have to worry about possible dropouts with wireless,
- mac side interaction between iTunes, Puremusic and the Devialet wireless driver. I am not sure how it works and right now Puremusic is needed for various reasons.

Cheers,
Bernard

 

[Orb]

Stick with what you have I say
WLAN can have a lot of unknowns for a user such as the transmit power settings, fall back speeds when bad signal quality-strength, too many devices same channel bandwidth,etc.
Conflicts can and do still happen and while it may not be an issue, it is pretty difficult to tell without running some tests or using a wlan analyser.
Would be fine though if one did not have a solution already.

Cheers
Orb

 

[Kalahaan]

Stick with what you have I say
WLAN can have a lot of unknowns for a user such as the transmit power settings, fall back speeds when bad signal quality-strength, too many devices same channel bandwidth,etc.
Conflicts can and do still happen and while it may not be an issue, it is pretty difficult to tell without running some tests or using a wlan analyser.
Would be fine though if one did not have a solution already.

Cheers
Orb

The wifi is totally Immune to electric interferences from the computer in cabled mode, not to mention the possible influence of the digital cable...
Therefore the asynchronous wifi connection by Devialet is probably the best option available today !

 

[Orb]

But it is not immune to interference of everything else in the same frequency transmission range, which includes many items on sale such as Bluetooth and other wireless technology including doorbells,etc.
Furthermore other problems include that the transmission strength suffers from building materials and reflections, compounded by other WLAN Access Points that may be on the same channel.
Even if the signal is rotating conflict will still happen as it will hit set frequency-channels used by other devices.
Regarding to signal strength and quality, this compounds issues relating to thresholds managing the transmission speed, and may find that the speed is reduced while also suffering drop in transmission performance due to other WLAN devices.
Other considerations are that some products in near proximity have way too much transmit power due to not being managed correctly or having the available tools to do so.

For basic wireless controls and general audio this is not much of a problem, but if you want to guarantee no problems combined with the very best quality you have a lot of variables in the mix.
In many cases it should not be a problem as the bandwidth required is between 1.4mbits to 4.6mbits (if just going up to 96khz/24bits), WLAN has an overhead similar to ethernet meaning you do not get the full bandwidth of the wlan; I cannot remember but it is around 30% loss as a general figure before any problems.

This paper is slightly out of date, but is pretty similar in the findings of work I have seen done investigating this from an engineering-manufacturer's perspective:
http://home.cogeco.ca/~rmhay/Wp_WlanCapyV2.pdf

Without the right tools or transmission conflict test processes, it can be very difficult to see what is happening, and of course it is possible that everything will be fine but as we are talking of a very open transmission frequency range and how popular the very diverese wireless world is, it needs to be a consideration for anyone who wants reliable and utmost quality at the same time.

The link'd document does a good job explaining it though, better than I am here anyway
Edit:
Another relevant link:
Cisco; 20 Myths of Wi-Fi Interference:
http://www.cisco.com/en/US/prod/col...9_ns736_Networking_Solutions_White_Paper.html
Thanks
Orb

 

[amirm]

On note about Wifi: if the audio is not glitching, then there is no "quality" issues. As Kalahaan mentions, the data transfer is asynchronous and hence, immune to timing jitter over a wired digital audio interface.

Unfortunately, there is potential for another form of jitter: the complex wifi system polluting the local oscillator and causing jitter that way. We have digital circuits, RF transmitters, etc, etc. Things that you don't want to have around your delicate clock. Would be great to see measurements of the WiFi relative to wired input.

 

[Orb]

Heya Amir,
although my point was about quality that is much more than one factor.
Anyway you aware of jitter with VoIP packets and it is noted for all network types even when de-jitter is used?
While jitter removal is done it still can affect the quality of voice, but I appreciate I am coming from a VoIP background here.
Can you explain what part of the solution is asynchronous please and maybe a product example, just in case we are getting wires in a muddle boom boom

Going to link this but possibly nothing to do with what your suggesting, even though VOIP is packet orientated, and I expect most streaming solutions to be connectionless udp, still worth a read for those who like skype,etc.
http://www.cnri.dit.ie/research.voip.html - Bit further down in link shows de-jitter solutions in networking and a WLAN scenario.

The below link touches more in general with network delay-jitter description, where I am coming from in this discussion specifically on jitter and audio effect (earlier post was more in general on audio quality and issues):
http://www.eetimes.com/design/signa...ues-part-2-Jitter-delay-and-echo?pageNumber=0

Thanks
Orb

 

[Orb]

Just quoting from a Cisco solutions white paper:

Voice Packet Handling by the Access Points

Enterprise-quality voice communications are dependent on predictable low-latency packet delivery and not necessarily on the total bandwidth available on the network. Voice services consume bandwidth on the order of kilobits per second (Kbps) as opposed to megabits per second (Mbps), and therefore are not very bandwidth-intensive. However, voice is highly sensitive to delay, which can result from digital transmission errors. When voice is transmitted, a specific compression/decompression (codec) scheme is used to digitize and compress the traffic, which is reconstructed on the opposite end of the transmission by a matching codec. During transmissions, variable network delays and retransmissions can increase the jitter, and together with signal loss and packet loss, cause poor voice quality.
Voice packets require fundamentally different handling by the 802.11 MAC layer than best-effort data packets. If they are delivered too late to a receiver's playout buffer, which briefly stores packets before the voice decoder converts the packet to audio, the packet is considered lost. Because of this, if packets suffer too much jitter or delay while traversing the WLAN, they can significantly impact VoIP audio quality.
To facilitate delivery of voice packets over the WLAN with low latency, jitter, and packet loss, the following intelligence has been incorporated into the access points of the Cisco Unified Wireless Network:
• An innovative, low-latency, rate-shifting algorithm that minimizes retries for a faster delivery of relatively short voice packets, and thus results in fewer delays.

• A MAC algorithm that allows different number of retries for voice and data services. This means that transmission reliability to data clients is maintained and delay-sensitive packets destined for voice clients will not be overly retried. This results in a more efficient use of the wireless medium based on the nature of the traffic transported.

• Packet-discard algorithms capable of head-of-queue packet discard when voice packets have been in a queue too long. This avoids using the WLAN to transmit voice packets that are known to be delayed too long, improving efficiency in handling voice traffic.

With the efficiency of the access points' MAC optimized for real-time VoIP packets, quality problems caused by latency and jitter are greatly reduced, and service quality for end users improves.

Its late and rushing, so I appreciate I may had missed your points by a very big margin
Thanks
Orb

 

[amirm]

Anyway you aware of jitter with VoIP packets and it is noted for all network types even when de-jitter is used?

VOIP is a real-time system so packet delay can be rather problematic. Not so when a device is just reading a file remotely. It can buffer substantial amount of data -- as much as it wants and has memory -- so that timing jitter becomes completely immaterial.

While jitter removal is done it still can affect the quality of voice, but I appreciate I am coming from a VoIP background here.

That is because of error concealment in the VOIP voice codec. When it runs out of data, it attempts to fill in the gaps and hence the audible distortion.

Can you explain what part of the solution is asynchronous please and maybe a product example, just in case we are getting wires in a muddle boom boom

Let's walk through the design:

You hit play on a song. The player then sends requests to the server to read a chunk of data. The device can choose to buffer any amount it wants. Since the Wifi Link is faster than our audio data rate (if it is not, you will get glitches), the buffer can be filled way ahead of the consumption rate by the DAC.

The above is asynchronous since the network reads are arbitrary in amount and timing. They simply aim to keep the buffer full above certain amount (below which they will cause a pause in playback until the buffer is filled enough).

Going to link this but possibly nothing to do with what your suggesting, even though VOIP is packet orientated, and I expect most streaming solutions to be connectionless udp, still worth a read for those who like skype,etc.

Actually no. DLNA streaming for example uses HTTP which as you know, sits on top of TCP. So the connection is 100% is stateful. File sharing as in Windows SMB is also done over TCP. So if this device works over that protocol, then it is still stateful and connection oriented.

http://www.cnri.dit.ie/research.voip.html - Bit further down in link shows de-jitter solutions in networking and a WLAN scenario. The below link touches more in general with network delay-jitter description, where I am coming from in this discussion specifically on jitter and audio effect (earlier post was more in general on audio quality and issues):
http://www.eetimes.com/design/signa...ues-part-2-Jitter-delay-and-echo?pageNumber=0

Thanks
Orb

Again, none of that is applicable here. In telephony and video conferencing applications we must keep end to end delay small or people get frustrated at either end. Ideal delay is measured in tens of milliseconds. This means that even a small bandwidth glitch causes us to run out of buffer and either stop playing audio or try to interpolate and fill the gaps. In the case of music streaming here, we can buffer many seconds. Start up can happen after say, 0.5 seconds but the buffer can keep filling as we play so that even catastrophic, multi-second bandwidth drops can be completely tolerated.

Further, there is no error mitigation in music playback systems. They will simply mute or glitch. VOIP systems resort to interleaving and various clever techniques to avoid complete drop offs. That complexity is required there but not here. Hence my comment that if the music plays, you are all set.

 

[Kalahaan]

Huh... can't wait conferencing on Skype through the Devialet D-Premier

 

[Orb]

Thank you Kalahaan
Amir just in response.
If using wireless and as an example Apple Airplay (which I think is the most likely wireless implementation Devialet will use), the file is still read by the application on the PC-Ipad-etc and then streamed to the receiver, so in this scenario it is still comparable to VoIP as the client is the PC-Ipad and it must stream the file to the far end, so it is not reading the file remotely.
http://support.apple.com/kb/HT4437
I think Airplay is a good example because they approach the issues in a way similar to DNLA but provide probably the best end-to-end architecture, also Airplay is good example to use because it employs RTSP that is specific to streaming audio-video.
In further detail it seems Airplay uses a combination of both TCP and UDP, although to be sure what it is someone needs to be bothered to capture how 554 RTSP is used (does not matter if udp or tcp as this is port is used to establish and control sessions normally) and importantly ports 16384-16403 are used that are UDP and for Audio RTP and Video RTP streaming delivery.
However if it is doing actual streaming, then what is outlined as challenges for VoIP is also applicable to D-Premier/Airplay/etc.
http://support.apple.com/kb/TS1629
Again RTP is associated with streaming and also VoIP, so the use by me is correct generally, but depends upon specific implementation where as I mention we are all making assumptions.
http://en.wikipedia.org/wiki/RTSP
http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
And specific about use of both tcp for control and udp for streaming:
http://en.wikipedia.org/wiki/AirTunes
Note it mentions;

The AirPlay protocol was reverse-engineered by Jon Lech Johansen in 2004.[6] It uses UDP for streaming and is based on RTSP.[7] The streams are encrypted with AES, requiring the receiver to have access to the appropriate private key to decrypt the streams.

But any solution needs to be comparable to the behaviour of RTCP and RTP, as a summary here is a basis summary from wiki.

The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications and web-based push-to-talk features.

RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. When both protocols are used in conjunction, RTP is originated and received on even port numbers and the associated RTCP communication uses the next higher odd port number.

It is one of the technical foundations of Voice over IP and in this context is often used in conjunction with a signaling protocol which assists in setting up connections across the network. RTP was developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) and first published in 1996 as RFC 1889, superseded by RFC 3550 in 2003.....
RTP was developed by the Audio/Video Transport working group of the IETF standards organization. RTP is used in conjunction with other protocols such as H.323 and RTSP.[1] The RTP standard defines a pair of protocols, RTP and RTCP. RTP is used for transfer of multimedia data, and the RTCP is used to periodically send control information and QoS parameters.[2]

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. RTP supports data transfer to multiple destinations through multicast.[3] RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.[1]

Real-time multimedia streaming applications require timely delivery of information and can tolerate some packet loss to achieve this goal. For example, loss of a packet in audio application may result in loss of a fraction of a second of audio data, which can be made unnoticeable with suitable error concealment algorithms.[4] The Transmission Control Protocol (TCP), although standardized for RTP use,[5] is not normally used in RTP application because TCP favors reliability over timeliness. Instead the majority of the RTP implementations are built on the User Datagram Protocol (UDP).[4] Other transport protocols specifically designed for multimedia sessions are SCTP and DCCP, although, as of 2010[update], they are not in widespread use.

So by definition sending high quality audio is real-time in same way as VoIP,both use tcp for establishing and managing sessions, while tcp can be used for streaming delivery I know from experience it usually is not but cannot comment for Airplay so the specific port would need to be monitored, however if previous quote is correct then it is udp anyway for Airplay.

I think DNLA is pretty comparable where the HTTP is used for establishing and controlling-managing, as I know the Digital Media Players must use UDP for streamed MPEGs/H.264/etc.
Also it seems that Upnp uses HTTP over UDP for some aspects.
Need to log for now unfortunately but hopefully enough there for chatting.
Thanks
Orb