Another plead.... Strip the all-in-one streamers

Posted by: JYOW on 11 January 2010

Strip the all-in-one streamers

I remember being very excited about the HDX when it first came out. Only to find out that Naim had invested in unnecessary but noisy components like touch screen, CD drive and 2 hard drives, all these noisy components cost a lot to isolate. So I passed on the HDX.

Then came the Uniti, a dream machine for a starter system. But the cost included an even longer list components that are not needed, like CD drive, FM tuner, DAB tuner, DAC in, pre/power section. …. etc. So again not for anyone looking for a pure streamer.

Now the UniQute, which is so cute, so much like the old Naits that I want to hug it. But again, it is not a pure streamer, the only thing stripped out is the CD drive.

Dear Naim,

I understand that the all-in-one streamers fit the iPod crowds. But why not a pure streamer similar to the Linn DS? I am sure that it is EASIER to strip everything and develop a clean, low noise streamer.

Please understand that a pure streamer is a proven business model, Linn is investing its entire company into it, Slim Devices has done it for years with the Transporter. I know a few Transporter users who are also die hard Naimees, myself included, who cannot wait to switch to naim the minute streamer with a Naim logo comes out.

It probably cost less to build a high end streamer, and like everything with high-end written on it it will get much better margin. (e.g. Linn Klimax)

Meanwhile I am getting used to streaming my Macbook Pro to my Weiss DAC. But it doesn’t have to be that way.

Thanks for listening…..

Posted on: 21 January 2010 by Aleg

quote:
Originally posted by gary1 (US):
The problem however looking at the Linn DS Series, is that there are different prices points for the different ds boxes and different quality of playback.

Therefore, if/when Naim do produce a streamer unless it is at the "upper end" then it is not going to appeal to everyone who is now clamoring for a streamer. If the Unitiqute is "stripped down" and the price is say $2-2.5K is won't sound as good if Naim build a $5-6K streamer or at $15k streamer.

Don't forget the Linn DS all contain a DAC in the box. So they are not pure streamers, but "Streamer + DAC"-boxes. I guess this also explains the differences in sound quality.

That is not required with Naim since they already have a very good DAC and only require an additional streamer/mediaplayer which only needs to have digital output.

My guess that would avoid the major part of the costs and I would expect such a streamer to be of a significantly lower RRP.

-
aleg

Posted on: 21 January 2010 by JYOW

quote:
Originally posted by Aleg:
quote:
Originally posted by gary1 (US):
The problem however looking at the Linn DS Series, is that there are different prices points for the different ds boxes and different quality of playback.

Therefore, if/when Naim do produce a streamer unless it is at the "upper end" then it is not going to appeal to everyone who is now clamoring for a streamer. If the Unitiqute is "stripped down" and the price is say $2-2.5K is won't sound as good if Naim build a $5-6K streamer or at $15k streamer.

Don't forget the Linn DS all contain a DAC in the box. So they are not pure streamers, but "Streamer + DAC"-boxes. I guess this also explains the differences in sound quality.

That is not required with Naim since they already have a very good DAC and only require an additional streamer/mediaplayer which only needs to have digital output.

My guess that would avoid the major part of the costs and I would expect such a streamer to be of a significantly lower RRP.

-
aleg

Hah? And Squeezeboxes/Transporters have no DAC in the box?

I am really confused about all your "theories" seemingly withoutunderstanding or experiencing all your so called "streamers" out there.

Posted on: 21 January 2010 by JYOW

Guess what the acronym "DS" stands for?

Posted on: 21 January 2010 by bhaagensen

Hi Aleg,

quote:
Originally posted by Aleg:

By push I mean that the mediaserver is sending out packages directed at a player with some IP-address-portnumber. By pull I mean the player retrieving the required file using network-filesystem commands.

I go along with some of your comments about disadvantages of letting go of the pure client-server model. The model I have in mind is somewhat like the one used by mpd. Where a lightweight daemon runs on the player side and which accesses the audio files on a central file server by means of ordinary file system commands. It is controled by remote control points like an iPod or any network attached computer, but could easily be controled by a local client on the player.

For proper and efficient tag-processing it would require a tag-"database" which could be a centralised or decentralised storage. It needn't be a true database, e.g. mpd uses a simple flatfile with label-value pairs and this is small in size and performs very well indeed (I use one with >1800 albums and >30.000 tracks and just over 10 MB in size).

I don't worry too much about processing power of players. With the selection of proper dedicated media playing chipsets, which could als have a Linux embedded for example, there would be enough power on-board to perform the most complex conversions and hi-res processing required for audio playback and which wouldn't require any HDD-storage. Small SD or SDD would be sufficient for persistent storage.

I'm more in favour of a distributed processing model where clients do more processing then a pure client-server model with centralised processing just to off-load clients.

aleg

I think we're in agreement more than not. I do however think that as far as mpd goes it is rather similar to the squeezebox-server software (Squeezeboxserver) as far as architecture goes. As far as communication goes remote clients communicates with the daemon only. The communication is via a custom TCP-protocol. File-system access is in this case always via the daemon. As for Squeezeboxserver, mpd can even transcode between formats before sending the file to the clients. Direct file-system access is only possible for (machine)-local clients. Or so I understand it?

Details closer to the implementation such as choice of central "database"-format can always be discussed and is to an extent an orthogonal issue IMO. As is the choice of feature set. mpd has one input-api which relies on http. Squeezeboxserver is more complicated in this respect as they provide full control towards servces such as Last.fm, Rhapsody, etc. I agree that processing power may no longer be a central issue, but there are other reasons for having some notion of server.

Bjørn

Posted on: 21 January 2010 by Aleg

quote:
Originally posted by JYOW:
Hah? And Squeezeboxes/Transporters have no DAC in the box?

I am really confused about all your "theories" seemingly without understanding or experiencing all your so called "streamers" out there.

They are not so much theories, the only thing is I'm not just jumping on bandwagons, without looking at what these devices really are.

I have never said that SB/Linn DS/Transporter and the like, don't have DAC's inside, of course they have. And I understand quite well what they are and how they work, thank you. I said that a Naim streamer doesn't need an inbuilt DAC because Naim already has a separate stand-alone DAC.

For me a pure streamer/mediaplayer is just a mediaplayer that outputs a digital audio signal in spdif protocol and can use different types (internet streams, local storage, network attached storage, UPnP streams if you have to have it) and formats (wav, flac, mp3, whatever) of digital input / storage.

If you have the capability to apply some logic, to bring structure into things and can look clearly at the functions of all these components you can see that with an Naim external DAC, you don't need an inbuilt DAC in a streamer product.

I don't think I'm suggesting any university-level thoughts around here, its just looking clearly at a possible total architecture of Naim separate components and not just "wanting the same thing that everybody else is making" but then made by Naim.

-
aleg

Posted on: 21 January 2010 by Aleg

quote:
Originally posted by bhaagensen:
Hi Aleg,

I think we're in agreement more than not.

I hope so

quote:

I do however think that as far as mpd goes it is rather similar to the squeezebox-server software (Squeezeboxserver) as far as architecture goes. As far as communication goes remote clients communicates with the daemon only. The communication is via a custom TCP-protocol. File-system access is in this case always via the daemon. As for Squeezeboxserver, mpd can even transcode between formats before sending the file to the clients. Direct file-system access is only possible for (machine)-local clients. Or so I understand it?

I think you are close to what I mean. What I mean is that the mpd-deamon is running on the client, i.e. the mediaplayer, itself and not on a central server. It (the mpd daemon) gets the audio file from the central server (by means of having a mount in the local file system), processes it and outputs it to the mediaprocessing chip or soundcard device drivers, depending on the hardware architecture.

Mpd, as it comes, can stream output to a client-device (http-streaming or shoutcast) and as such could be used on the server side of things, but that's not how I would like see it.

quote:
mpd has one input-api which relies on http. Squeezeboxserver is more complicated in this respect as they provide full control towards servces such as Last.fm, Rhapsody, etc. I agree that processing power may no longer be a central issue, but there are other reasons for having some notion of server.

Bjørn

That is true and I was using mpd just as an example how it would be possible to have a lightweight player, capable of playing many digital sources just from the player, without the necessity of having to have a streaming Mediaserver. I admit I'm not up-to-grabs with Last.fm, Rhapsody and the like so am not able to judge if those sources could be connected to without using a Mediaserver concept.

-
aleg

Posted on: 21 January 2010 by JYOW

quote:
For me a pure streamer/mediaplayer is just a mediaplayer that outputs a digital audio signal in spdif protocol and can use different types (internet streams, local storage, network attached storage, UPnP streams if you have to have it) and formats (wav, flac, mp3, whatever) of digital input / storage.

There are probably customers who want a pure media “transports”, just like there are CD transports. But would everyone need or want to buy a separate DAC? What if one just wants to buy a CD player, or a media-player?

quote:
If you have the capability to apply some logic, to bring structure into things and can look clearly at the functions of all these components you can see that with an Naim external DAC, you don't need an inbuilt DAC in a streamer product.

The Logic is, not everyone wants, needs or affords a Naim DAC PLUS a media player plus all the power supply options.

quote:
I don't think I'm suggesting any university-level thoughts around here

No disrespect, but you seem to apply many “universal logic” that need verification, e.g. Computer file level playback is better than streaming; Inbuilt DAC is not desirable;

quote:
Its just looking clearly at a possible total architecture of Naim separate components and not just "wanting the same thing that everybody else is making" but then made by Naim.

I agree with the last statement. We Naim aficionados tend to worship anything with Naim logos on it. I remember people showing disappointment about Naim not putting a reference level case on the DAC and be chargedmore money for more air inside.

Like the Naim DAC, I eagerly anticipate Naim coming out with a box with functions that I could use, but I reserve judgment until I have seen/heard it.