Phantoms delivered this afternoon

[Jwg1749]

Spark is a very new bit of software. It may have years to go before it is as good as some of the old debugged programmes.
My Dialog smells v-e-r-y hot. I unplug it when I am not using it. I am concerned for its durability.

I really hope you're wrong -- though I don't doubt what you say.
 
How hard is it to design a piece of networking kit that doesn't overheat? And how come Devialet, with their financial backing, can't produce a decent control point GUI, when Sonos managed to get it right 10 years ago?

[GuillaumeB]

How hard is it to design a piece of networking kit that doesn't overheat? And how come Devialet, with their financial backing, can't produce a decent control point GUI, when Sonos managed to get it right 10 years ago?

I can't really speak for the Dialog, who knows what might be going on quite frankly. It might just be an early production anomaly.

Regarding control point GUIs these seem to give audio companies the biggest headaches and more often than not they just don't work well. I think Sonos is the glaring exception here, having used the system myself I have to say none of the others come remotely (haha) close. Well Linn are getting there with Kazoo but look what a nightmare they have had with it, and Linn have been in the UPnP streaming game since 2007. They even created the OpenHome specification which many other companies are now using. 

To expect a company to dream up a brand new CP in months is just fanciful IMHO. Frank's right, it could take years. I hope not of course and no doubt Devialet will throw some serious resources behind it if they want to shift 150k Phantoms a year. But just throwing more developers at the problem doesn't necessarily resolve things either. 

Guillaume

[cthroughblue]

Well i received my phantom today. first thing to say is that sparks as an app is very very buggy. It looks stylish enough but works when it wants to really. for an expensive bit of kit and a high end company i would expect it to work seamlessly. it such and important part of the experience that its a big let down. i know they will work on it but it really should be perfect to start with. my dad uses sonos and it works a+ from day one and every time.

my original setup is a 120 and sonus faber olympics 1s . pure power 1050 power regenerator. entreq tellus grounding box connected to the 120, nordst power block and the apple airport. The 120 is also still pointed.

The phantom i have is a single white one. when i first listened to it i was not overly impressed, The bass is very nice, but i felt the rest of the music sounded a bit stuck in the speaker to me. i have listened to it for about an hour now and i think it is just very neutral with all aspects of the music balanced nicely. I was originally worried the bass might be a bit over powering but it is not at all and very controlled.

i set up so i could play the original system and the phantom to compare. At first the original system sounded sooooo much better for example instruments having more timber and sounding more real. The only problem is of course the original system is stereo and the phantom is mono. so i unplugged one of the olympics and compared it that way. listening to it this way the phantom sounds clearer and not to far off the original system at all.

Can anyone with a stereo pair of phantoms comment on how good the stereo imaging is. I bought the one phantom to see if it was worth getting a pair and selling my original system. if the stereo imagining is good then i really don't think the sound will be to far off my original system and at a lot less cost and without the itch to try and tinker with it in the never-ending cable swapping game etc.....

I did put the still points under the phantom and although i probably haven't listened to it enough to say for sure but seems to have the same affect on the phantoms as any other component. shame there is nowhere to plug in the entreq grounding box.... or maybe its better that there isn't.

i worry that deviate will take a while to sort out the reported problems with the dialog and having a stereo pair as music should be for me a relaxing thing not a frustrating one Smile

[f1eng]

Spark is a very new bit of software. It may have years to go before it is as good as some of the old debugged programmes.
My Dialog smells v-e-r-y hot. I unplug it when I am not using it. I am concerned for its durability.

I really hope you're wrong -- though I don't doubt what you say.
 
How hard is it to design a piece of networking kit that doesn't overheat? And how come Devialet, with their financial backing, can't produce a decent control point GUI, when Sonos managed to get it right 10 years ago?

Having hardware that doesn't overheat should indeed be straightforward and mine may be just a newness smell.

Software is very, very difficult and people hugely underestimate how difficult, long winded and expensive it is, particularly since it is often available "free" or nicked off the internet.
The first piece of CAD software I used in 1985 was pitiful by modern standards but already had more than 1000 man-years of software development.
AIR is a good example to quote. Originally the specification was Mac only using iTunes as a front end. This was still probably a huge task but before it was completely finished customer pressure got it changed to multi-platform, multi front end. This probably increased the complexity and likelihood of debugging it 100 fold, maybe more. Pound to a pinch of poo the manager authorising it had no idea what he was committing to. It still doesn't work as well as the original IMO and it may be a very long time before it does.
Sonos is a good example of something written many years ago to a relatively simple and un-changing specification. After many years of development it is market leading.
Hoping a new piece of software which customers expect to have massively more flexibility in terms of platform and file type compatibility to be anywhere near it from the outset is naive in the extreme. It could take hundreds of thousands of pounds and probably many years to get Spark to the level Sonos has achieved after many years. IMHO.

[thumb5]

Spark is a very new bit of software. It may have years to go before it is as good as some of the old debugged programmes.
My Dialog smells v-e-r-y hot. I unplug it when I am not using it. I am concerned for its durability.

I really hope you're wrong -- though I don't doubt what you say.
 
How hard is it to design a piece of networking kit that doesn't overheat? And how come Devialet, with their financial backing, can't produce a decent control point GUI, when Sonos managed to get it right 10 years ago?

Having hardware that doesn't overheat should indeed be straightforward and mine may be just a newness smell.

Software is very, very difficult and people hugely underestimate how difficult, long winded and expensive it is, particularly since it is often available "free" or nicked off the internet.
The first piece of CAD software I used in 1985 was pitiful by modern standards but already had more than 1000 man-years of software development.
AIR is a good example to quote. Originally the specification was Mac only using iTunes as a front end. This was still probably a huge task but before it was completely finished customer pressure got it changed to multi-platform, multi front end. This probably increased the complexity and likelihood of debugging it 100 fold, maybe more. Pound to a pinch of poo the manager authorising it had no idea what he was committing to. It still doesn't work as well as the original IMO and it may be a very long time before it does.
Sonos is a good example of something written many years ago to a relatively simple and un-changing specification. After many years of development it is market leading.
Hoping a new piece of software which customers expect to have massively more flexibility in terms of platform and file type compatibility to be anywhere near it from the outset is naive in the extreme. It could take hundreds of thousands of pounds and probably many years to get Spark to the level Sonos has achieved after many years. IMHO.

Speaking as an embedded software developer, I can only say: hear, hear!

Maybe just to pick on one point: I wouldn't necessarily agree entirely with your comment about the simplicity of Sonos's software.  The software is continually updated and increases in scope each time -- for example to support new capabilities and services.  The core software has had the benefit of running on entirely proprietary, purpose-designed hardware which has only changed fairly infrequently, and I'm sure that contributes enormously to its stability.

Where Sonos have taken some flak recently is for the control software running on generic phones and tablets, as distinct from the dedicated controllers.  My impression (without concrete evidence, but in line with industry practice) is that this is written by a different type of developer to those writing the embedded software that runs on the Sonos proprietary hardware.

[davidadamson]

My Dialog is also very very very Hot, cannot be good for the components

[Jwg1749]

Speaking as an embedded software developer, I can only say: hear, hear!


Maybe just to pick on one point: I wouldn't necessarily agree entirely with your comment about the simplicity of Sonos's software.  The software is continually updated and increases in scope each time -- for example to support new capabilities and services.  The core software has had the benefit of running on entirely proprietary, purpose-designed hardware which has only changed fairly infrequently, and I'm sure that contributes enormously to its stability.

Where Sonos have taken some flak recently is for the control software running on generic phones and tablets, as distinct from the dedicated controllers.  My impression (without concrete evidence, but in line with industry practice) is that this is written by a different type of developer to those writing the embedded software that runs on the Sonos proprietary hardware.

The point of my reference to Sonos was that on release it worked. It's true that it's been updated since, but the Sonos user experience today is really not much different from how it was when I first used it 10 years ago. In all that time I think Sonos have only messed up once: the 2nd generation touchscreen controllers were very unreliable. Otherwise it's been consistently excellent. 

Is it really the case that designing robust music server software is much more difficult today than it was back then?

[f1eng]

Speaking as an embedded software developer, I can only say: hear, hear!


Maybe just to pick on one point: I wouldn't necessarily agree entirely with your comment about the simplicity of Sonos's software.  The software is continually updated and increases in scope each time -- for example to support new capabilities and services.  The core software has had the benefit of running on entirely proprietary, purpose-designed hardware which has only changed fairly infrequently, and I'm sure that contributes enormously to its stability.

Where Sonos have taken some flak recently is for the control software running on generic phones and tablets, as distinct from the dedicated controllers.  My impression (without concrete evidence, but in line with industry practice) is that this is written by a different type of developer to those writing the embedded software that runs on the Sonos proprietary hardware.

The point of my reference to Sonos was that on release it worked. It's true that it's been updated since, but the Sonos user experience today is really not much different from how it was when I first used it 10 years ago. In all that time I think Sonos have only messed up once: the 2nd generation touchscreen controllers were very unreliable. Otherwise it's been consistently excellent. 

Is it really the case that designing robust music server software is much more difficult today than it was back then?

I think the key is that the Sonos system was relatively simple and well defined, both in the hardware it used and the file types it worked with.
Writing software which can deal with more different bits of hardware and more file types is much more complex, yes.

[thumb5]

The point of my reference to Sonos was that on release it worked. It's true that it's been updated since, but the Sonos user experience today is really not much different from how it was when I first used it 10 years ago. In all that time I think Sonos have only messed up once: the 2nd generation touchscreen controllers were very unreliable. Otherwise it's been consistently excellent. 

Completely agreed.  As I understand it, the recent batch of complaints about the phone/tablet controller software is mostly to do with UI design, rather than reliability.  I pretty much always use the old-fashioned first-generation dedicated controllers, which are rock solid, so it's not something that's bothered me at all.

Is it really the case that designing robust music server software is much more difficult today than it was back then?

I can't see any reason why it should be.  If anything it should be easier to build software to meet a given set of requirements now than it was ten years ago (or whenever) because the tools are better and the hardware is so much more powerful.  But first of all you have to have a well-defined and stable set of requirements.  Given that Devialet didn't seem to know exactly what Spark was going to support until such a short time before it was released, that rang a big alarm bell for me.  Also, it still takes time to properly test and debug device software, and it looks as though that was done rather hurriedly in order to meet shipping dates.  (In common with lots of other software for devices that are field-upgradeable, I might add.)

[GuillaumeB]

The point of my reference to Sonos was that on release it worked. It's true that it's been updated since, but the Sonos user experience today is really not much different from how it was when I first used it 10 years ago. In all that time I think Sonos have only messed up once: the 2nd generation touchscreen controllers were very unreliable. Otherwise it's been consistently excellent. 

Is it really the case that designing robust music server software is much more difficult today than it was back then?

I think it's almost as important to look at the founders of the company and their background. John McFarlane (CEO) and the other 3 co-founders had made a ton of money from the sale of Software.com at the height of the dot com boom in 2000. Their background was in selling messaging systems to telcos, so I think it's fair to say their background was in software. As others have mentioned they also had a very clear vision of what they wanted to do and the money to achieve it too. Being near Silicon Valley also probably helped in getting access to the best programming minds around.

What Sonos have achieved is pretty amazing really. They are looking as though they will hit 1 billion USD in sales soon.

http://www.bloomberg.com/bw/articles/201...ming-music

Guillaume