FYI. I've been corresponding with Roger from Devialet, and have asked him the following questions:
"Why don't you create a debugging version of AIR with error/trace logging to a text file, say, every 500 ms? That should be easy enough, and could help determine the cause of the white noise. There are users who can recreate this issue at will, and would be willing to run the debugging version of AIR.
Also, I'd like to ask you several questions:
1) Can a 6-7 meter ACTIVE USB cable be used for streaming, without harm to the sound quality?
2) You have a flawless USB solution (no one has ever observed white noise over USB). Can a similar solution be used with Ethernet (that is, optionally bypassing AIR)?
3) Have you ever considered using ASIO instead of WASAPI, on the Windows platform? Some consider ASIO superior to WASAPI."
I'll keep you posted regarding his reply.
(01-Nov-2014, 09:30)Riddo Wrote: [ -> ]I put ethernet setting to maximum 5000ms and restarted Jriver and Air, and started a new 24-96 track and miraculously it played through until the following (16-44) random song where it spat out another continuous stream of spitting music and noise.
This is an interesting post, because for me, if I set the buffer to 5000ms and try to play a 24/192 file, AIR then shuts down in about 3 seconds. Although with 24/48 or 24/96 the 5000ms buffer still works.
Just to add my 2 cents since 2.1.3 I have had no problems at all, Ran for 13 hours the other day as we had a listening session to try out Magico S1.
Running Win 8.1, Air 2.1.3 WASAPI on and 24/192.
I did have problems with 2.1.2 and switched to using USB which was fine.
I think this is the reason for the long fix as it is such an intermittent problem ( anyone in IT knows how much of a pain they are)
Short of sending someone to each users home for a month not sure there will be a quick fix.
Nick
Alex - an interesting post. I'm not an IT guy, but all this does remind me of some peoples approach to problems with cars, that is you have a misfiring car, someone says, "oh, change the ECU", you do this, no different. Someone else says, "it's the ignition coil", you change this, no different. After spending a huge amount of time and money replacing perfectly good components, then maybe you actually find the issue by chance. If you could diagnose the issue accurately in the first place, then much time and money would be saved. However, I think Devialet may have got your point, today they have asked me to provide a screenshot on the PC's activity monitor, such that they can review which processes are running when white noise occurs. Sounds like a good idea to me.
Well, there are plenty of us with the problem, so it shouldn't be too difficult for Devialet to reproduce. I think they have an innovative way of creating what is a soundcard working over IP, but when you get into that layer of software, you are working with Windows interfaces in a way not many have done before.
I used to use a uPnP server with a streamer pre-Devialet and once I had moved to a wired network the number of dropouts and other nasties just went to zero.
I think Devialet would be better served giving us a uPnP interface as a priority, higher priority than working on the DSD interface.
I did do some tests yesterday - using 2.1.3 I successfully streamed 24/96 files for 2.5 hours without any white noise, then on moving to 24/192 it went to white noise within the hour. There are some weird entries in the windows error log, but it's hard to tell if they are related.
(04-Nov-2014, 03:18)AlexS Wrote: [ -> ]Can a 6-7 meter ACTIVE USB cable be used for streaming, without harm to the sound quality?
I believe the USB standards stipulate a maximum length of 5M. In my experience anything over a couple of metres can cause issues. From a SQ perspective I'd always try and keep the lengths of cables as short as possible, unless going balanced of course (which you obviously can't with USB).
(04-Nov-2014, 03:18)AlexS Wrote: [ -> ]Can a similar solution be used with Ethernet (that is, optionally bypassing AIR)?
I'm pretty sure you'd need UPnP for that! The Devialet is still not a network streamer...
Guillaume
(04-Nov-2014, 12:01)GuillaumeB Wrote: [ -> ]I believe the USB standards stipulate a maximum length of 5M. In my experience anything over a couple of metres can cause issues. From a SQ perspective I'd always try and keep the lengths of cables as short as possible, unless going balanced of course (which you obviously can't with USB).
Having said that, Transparent make USB cables in lengths of up to 30 feet.
"Large gauge conductors allow for accurate signal transfer up to 30 feet compared with computer USB cables that are limited to a few meters."
So perhaps worth checking this out.
http://www.transparentcable.com/products...D=3&modCAT=
Guillaume
The regular 5m USB cable length limit can be circumvented by using either an active USB cable that boosts the signals or by using a optical converter like Adnaco offers or the optical USB cables that Corning makes.. (note that these cables still have copper conductors inside to power the optical plugs, so no full isolation of dirty computer power/ground planes) or of course a cable that is specified and tested to be reliable over longer lengths.
I agree with Guillaume though, I'd also use the highest quality and shortest USB cable possible or if that's not feasable a very high quality optical converter like the Adnaco S3B. It's very important that the Devialet receives the cleanest USB signal+power/ground as possible, it matters a lot for sound quality. The XMOS receiver inside the Devialet needs the USB ground conection active. Active USB cables can wreak havoc on the power/signal quality and optical converters can add a lot of jitter and/or dirty the signal/ground plane as well.
(04-Nov-2014, 11:12)smokejumper Wrote: [ -> ]I think Devialet would be better served giving us a uPnP interface as a priority, higher priority than working on the DSD interface.
I'm actually not sure it's a good idea. Devialet is not a full fledged computer, nor, in my opinion, should it be one. I'd rather my computer (the player) handle all the different music formats, and just send the WAVE input to Devialet. For instance, Foobar handles more input formats than uPnP renderers. And I can always install additional components to suit my needs. The same flexibility won't be possible with Devialet as a player.
Thank you Antoine and Guillaume! This is good info regarding the USB options. I think, if the white noise remains an issue for me with 2.1.3, I'd be better off buying a light weight MAC, using JRiver, and still streaming my files over AIR and Ethernet.
(04-Nov-2014, 17:09)AlexS Wrote: [ -> ] (04-Nov-2014, 11:12)smokejumper Wrote: [ -> ]I think Devialet would be better served giving us a uPnP interface as a priority, higher priority than working on the DSD interface.
I'm actually not sure it's a good idea. Devialet is not a full fledged computer, nor, in my opinion, should it be one. I'd rather my computer (the player) handle all the different music formats, and just send the WAVE input to Devialet. For instance, Foobar handles more input formats than uPnP renderers. And I can always install additional components to suit my needs. The same flexibility won't be possible with Devialet as a player.
Thank you Antoine and Guillaume! This is good info regarding the USB options. I think, if the white noise remains an issue for me with 2.1.3, I'd be better off buying a light weight MAC, using JRiver, and still streaming my files over AIR and Ethernet.
Alex, My meaning was not that the Devialet become a server of music, just that it should be a client capable of talking to a uPnP server on a computer. Many available streamers, bluray players and even TVs do this. You could still use eg JRiver, but you would see the Devialet as a device you could select to play on. This approach uses a well-defined interface which many devices already use, rather than the proprietary and lower level virtual soundcard approach. My fear is that if there is a bug in Windows at the root of all this white noise issue, MS might not see the weight of numbers of other users to bump it up to high priority.