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: 13 January 2010 by fixedwheel
quote:
Originally posted by David Dever:
If you cross UPnP off your list, there goes the Linn DS units as well, and (at their core) Sonos and Logitech devices.
With regard to the Logitech devices at least, (I haven't used the others), how do you make that out?
As I have been running a SB3 for nearly three years, it has always required SlimServer / SqueezeCenter / SqueezeboxServer running somewhere on my network. UPnP has never been required.
There again, I'm probably not the only one to think that gapless playback is essential, and not just for classical.
John
Posted on: 13 January 2010 by Aleg
quote:
Originally posted by likesmusic:
No I didn't intend to set you up at all - I agree with a lot of what you say about the silliness of upnp servers, I just think it follows from what you say about simplicity that the place for your proposed mediaplayer is inside the DAC (just as upnp media-renderers have a DAC incorporated). By all means have s/pdif inputs too for sources like legacy cd transports that need them. Add a volume control and you would have a magnificent digital pre-amp! Once you make the DAC separate then you get involved with all the rubbish about s/pdif cables, bnc/toslink which, judging by other posts on this forum from the esteemed golden-eared introduce sound-quality issues. There's just no need for this if your data is on the network, anymore than the DAC needs to apply RIAA pre-emphasis so that it can be fed into your phono-inputs.
Perhaps the closest thing to what I am suggesting is the Logitech Transporter. It can access music data files across a network (albeit with its own proprietary server, but at least it does gapless playback) and also has two s/pdif inputs and a volume control.
Think of it another way. Inside your proposed media streamer is some memory, into which data gets put. Inside the NAIM DAC is some memory from which you want the same data to be read into the D-A itself. Who in their right mind would use s/pdif to transfer data between two lumps of RAM?
I can follow you and see the logic. Albeit the input of the "player" section is not bit-for-bit equal to the input of the DAC-section. There is some conversion in between, but that would only be a RAM-to-RAM conversion/movement as well.
So maybe if Naim had developed a mediaplayer cum DAC before they released the stand-alone DAC I would have jumped on that as well.
Now being the case that the stand-alone Naim DAC is there (and for me also on order), I still would want a Naim "pure" networked mediaplayer to accompany the DAC, so without built-in DAC, amps, tuner, etc. and with the capability to access files stored on the network, without having to resort to upnp-streaming servers, Twonkys, SqueezeCentres, etc.
Thanks for the discussion, enjoyed that.
-
aleg
Posted on: 13 January 2010 by likesmusic
Cheers aleg. Hope you get your DAC soon. How are you going to get music into it?
Posted on: 13 January 2010 by Asenna04
quote:
Originally posted by JYOW:
quote:
Originally posted by Aleg:
quote:
Originally posted by David Dever:
quote:
Originally posted by Aleg:
Probably not eh, since it is still UpnP, which is an architecture they should ditch alltogether, because it is a useless addition to local network filesystems.
I'll just wait and see.
One thing for sure, I'll not be buying a UniQute either. I don't want to pay for all the useless parts that come with a one-box-for-everyting solution.
So I'll just wait and see....
-
aleg
If you cross UPnP off your list, there goes the Linn DS units as well, and (at their core) Sonos and Logitech devices.
Right, I am indeed not interested in those solutions either.
The streaming concept was developed to deliver audio/video over the internet with small pieces a time not needing to download the whole file first and at the same time preventing the listener/viewer can get his hands on the complete source files. It is a broadcasting model for the broadcasting industry.
UpnP-devices are nice devices to connect to these internet broadcasts, if that interests you. But there is no audiophile level of broadcasting yet (if ever), it all is still some level of lossy audio.
Within a local area network, with local (NAS) storage of preferably lossless audio files, these arguments don't stick. Within a local network there is no need to put in a streaming server (Twonky e.g.) and start broadcasting audio around your local area network. A networked media player can just access the file on the fileserver directly, it need not be streamed. There is no delay of access, bandwidth in a local area network is more then sufficient for all audio or video playback. Playback can be gappless. Adding a streaming server is IMO again a useless addition within a local area network.
A Naim mediaplayer/streamer, on my part, doesn't have to be a UpnP streamer (I'm not particularly interested in internet radio broadcasts). For playback from my local area network NAS it just needs to be capable to access at least NFS-exports and/or support the SMB/CIFS-protocol for file access and be capable of playing a few popular lossless audio codecs.
The files are directly available on the local network, so just
get them and don't start streaming them first.
-
aleg
Is this dislike of "streaming" based on actual listening of other network "streamers" or based on the OP's association of "streaming" with low res Internet radio?
Network streamers like Squeezebox/ Transporter/ Linn DS/Meridian Sooloos buffer lossless audio up to 24/192-Khz over the network beautifully. In fact, similar to the Naim DAC, the buffering of audio data an help to ensure audio date is “clocked into the memory at the incoming inconsistently-timed rate.”
Incidentally, Linn is so confident about "streaming" over the network that they are literally betting their farm on streaming audio by announcement the termination of their CD players range in favor of the Linn DS architecture.
Completely agree.
ASenna04
Posted on: 13 January 2010 by Asenna04
quote:
Originally posted by Aleg:
quote:
Originally posted by JYOW:
Is this dislike of "streaming" based on actual listening of other network "streamers" or based on the OP's association of "streaming" with low res Internet radio?
....
No, it is not based on listening.
It is based on my experience of having a networked mediaplayer that doesn't require a streaming server.
It is also based on my experience of being an ICT-architect and from there on the principle that best solutions are usualy clear and simple.
And looking at it from that perspective, if a file is available in a local area network, why put in an extra piece of software that will stream it across the network, instead of just get it by accessing the filesystem where it is stored. Esp. since the streaming technology was not intended to be used in a local network, where there is no need for it.
That doesn't mean it doesn't work, but it is an unnecessary and complicating factor.
Further the UpnP specs appear not to support gapless playback, so additional functionality needs to be developed , which then again are not part of the specs. It requires extra software on the server that needs to be developed, maintained, can contain errors, puts extra management efforts onto the user to manage this TWONKY thing.
And all this while it is not necessary for playing audio from a local network.
For me it is the same as e.g. (just to give a stupid example) modulating the output of a CD-player onto an FM-radio signal and playing that using a tuner, because we have tuners that can receive and play FM-signals. Just forgetting that FM radio signals are a broadcast technology and are not required for playback of CD's.
-
aleg
Aleg,
You make a good point about keeping it simple. But for any digitally stored music, there is the benefit of being able to analyse your music based on Meta Data tags e.g. search for all tracks with a certain word in the track name. This will require system processing power for quick feedback. In my view, this is best done on the server/NAS side rather then the streamer. The streamer sits next to the sensitive HiFi equipment and should be kept simple without too much processing power. The processing can be done on the server that can sit in a remote location and is connected to the streamer either by ethernet or wifi.
ASenna04
Posted on: 13 January 2010 by Aleg
quote:
Originally posted by Asenna04:
quote:
Originally posted by Aleg:
quote:
Originally posted by JYOW:
Is this dislike of "streaming" based on actual listening of other network "streamers" or based on the OP's association of "streaming" with low res Internet radio?
....
No, it is not based on listening.
It is based on my experience of having a networked mediaplayer that doesn't require a streaming server.
It is also based on my experience of being an ICT-architect and from there on the principle that best solutions are usualy clear and simple.
And looking at it from that perspective, if a file is available in a local area network, why put in an extra piece of software that will stream it across the network, instead of just get it by accessing the filesystem where it is stored. Esp. since the streaming technology was not intended to be used in a local network, where there is no need for it.
That doesn't mean it doesn't work, but it is an unnecessary and complicating factor.
Further the UpnP specs appear not to support gapless playback, so additional functionality needs to be developed , which then again are not part of the specs. It requires extra software on the server that needs to be developed, maintained, can contain errors, puts extra management efforts onto the user to manage this TWONKY thing.
And all this while it is not necessary for playing audio from a local network.
For me it is the same as e.g. (just to give a stupid example) modulating the output of a CD-player onto an FM-radio signal and playing that using a tuner, because we have tuners that can receive and play FM-signals. Just forgetting that FM radio signals are a broadcast technology and are not required for playback of CD's.
-
aleg
Aleg,
You make a good point about keeping it simple. But for any digitally stored music, there is the benefit of being able to analyse your music based on Meta Data tags e.g. search for all tracks with a certain word in the track name. This will require system processing power for quick feedback. In my view, this is best done on the server/NAS side rather then the streamer. The streamer sits next to the sensitive HiFi equipment and should be kept simple without too much processing power. The processing can be done on the server that can sit in a remote location and is connected to the streamer either by ethernet or wifi.
ASenna04
Hi ASenna04
You may have a point there, but I'm not capable of judging the effect of processor and/or memory processing on nearby HiFi equipment.
I can imagine it is no different than in an HDX, so I would guess that Naim has solved that problem already.
The mediaplayer I use now has a small audio-tag-library file (10 MB for 325.000 lines, 1800 albums) which gets updated by adding files to the library. It is stored locally on SDD or HDD. I can imagine that by adding e.g. a small SD-card to a streamer one could have local persistent storage without disk interference.
So, you may have a point, but I guess it has already been resolved or may easily be.
-
aleg
Posted on: 13 January 2010 by JYOW
>> No, it is not based on listening.
Mine is based on owing both solution. The streaming solution is through the SlimServer/Transporter platform, the other through Macbook Pro/iTunes/QNAP NAS/Weiss DAC. Both very successfully. I believe iTunes just play the networked files without streaming, but the Weiss DAC does buffer the audio data.
>> It is based on my experience of having a networked mediaplayer that doesn't require a streaming server.
Which networked media player did you use?
>> It is also based on my experience of being an ICT-architect and from there on the principle that best solutions are usualy clear and simple.
That is a rather general statement.
>> And looking at it from that perspective, if a file is available in a local area network, why put in an extra piece of software that will stream it across the network, instead of just get it by accessing the filesystem where it is stored. Esp. since the streaming technology was not intended to be used in a local network, where there is no need for it.
Well streaming is actually not the main feature of a networked based music server software. They usually help to organize and index the music files, which if like most of us you have tens of thousands of tracks, is indispensable. It is near impossible to access your music without some sort of music organizer.
>> Further the UpnP specs appear not to support gapless playback, so additional functionality needs to be developed , which then again are not part of the specs. It requires extra software on the server that needs to be developed, maintained, can contain errors, puts extra management efforts onto the user to manage this TWONKY thing.
No argument there. UPNP is buggy and basically hit or miss. But media server like the Slimserver has always had gapless playback and all sorts of features that can be turned on or off.
>> And all this while it is not necessary for playing audio from a local network.
I thought you mentioned earlier that you are using a networked media player.
>> For me it is the same as e.g. (just to give a stupid example) modulating the output of a CD-player onto an FM-radio signal and playing that using a tuner, because we have tuners that can receive and play FM-signals. Just forgetting that FM radio signals are a broadcast technology and are not required for playback of CD's.
That is not a stupid example, just plain wrong. Every solution we mentioned so far are bit perfect.
Posted on: 13 January 2010 by Aleg
quote:
Originally posted by JYOW:
>> No, it is not based on listening.
Mine is based on owing both solution. The streaming solution is through the SlimServer/Transporter platform, the other through Macbook Pro/iTunes/QNAP NAS/Weiss DAC. Both very successfully. I believe iTunes just play the networked files without streaming, but the Weiss DAC does buffer the audio data.
>> It is based on my experience of having a networked mediaplayer that doesn't require a streaming server.
Which networked media player did you use?
>> It is also based on my experience of being an ICT-architect and from there on the principle that best solutions are usualy clear and simple.
That is a rather general statement.
>> And looking at it from that perspective, if a file is available in a local area network, why put in an extra piece of software that will stream it across the network, instead of just get it by accessing the filesystem where it is stored. Esp. since the streaming technology was not intended to be used in a local network, where there is no need for it.
Well streaming is actually not the main feature of a networked based music server software. They usually help to organize and index the music files, which if like most of us you have tens of thousands of tracks, is indispensable. It is near impossible to access your music without some sort of music organizer.
>> Further the UpnP specs appear not to support gapless playback, so additional functionality needs to be developed , which then again are not part of the specs. It requires extra software on the server that needs to be developed, maintained, can contain errors, puts extra management efforts onto the user to manage this TWONKY thing.
No argument there. UPNP is buggy and basically hit or miss. But media server like the Slimserver has always had gapless playback and all sorts of features that can be turned on or off.
>> And all this while it is not necessary for playing audio from a local network.
I thought you mentioned earlier that you are using a networked media player.
>> For me it is the same as e.g. (just to give a stupid example) modulating the output of a CD-player onto an FM-radio signal and playing that using a tuner, because we have tuners that can receive and play FM-signals. Just forgetting that FM radio signals are a broadcast technology and are not required for playback of CD's.
That is not a stupid example, just plain wrong. Every solution we mentioned so far are bit perfect.
Hi JYOW
I get the impression you are missing the essence of my reply.
The mediaplayer I use is a PopcornHour with mpd (music player daemon). PopcornHour is based on a specialised media-playing processor chip with embedded linux, which can access filesystems directly over NFS or SMB/CIFS or can act as a UPnP client or server.
I would like to be able to replace it with a Naim mediaplayer based on a similar concept.
quote:
Well streaming is actually not the main feature of a networked based music server software. They usually help to organize and index the music files, which if like most of us you have tens of thousands of tracks, is indispensable. It is near impossible to access your music without some sort of music organizer.
It is a bit strange to start streaming audio data over a network when you only want a music library.
The mpd I use is controled using an mpd-client which can run on any computer in the network or on iPod or many other mobile devices. It has a music library based on tags of the audio files and plays audio files by using direct access to the audio files stored on a networked file system. So there is no need to have server based streaming software or network based music server software to play audio of a network storage. I now have over 1800 of my albums (> 30.000 songs) in there and can't complain about performance or anything. It does its job wonderfully.
quote:
>> It is also based on my experience of being an ICT-architect and from there on the principle that best solutions are usualy clear and simple.
That is a rather general statement.
Yes it is general, but also true from my personal experience.
quote:
That is not a stupid example, just plain wrong.
My example was not meant to be correct
, but just an example to convey my feeling of how I feel about using a streaming solution in a local netwerk, i.e. a solution that has been made overcomplicated for a simple task for which simple means are available.
-
aleg
Posted on: 13 January 2010 by JYOW
I am not familiar with Popcorn hour but I thought it is a video player first and foremost. Are you implying that it would sound better than streamers like the Linn DS, HDX when played over the network and the Transporter, amongst other streamers?
Just to make sure we re in sync, what is your definition of a streamer? My impression is most of the high end network players out there buffers and stream music over the network.
As we speak I am playing my music over a network NAS off iTunes and a Weiss DAC. DO you consider that a streamer?
Posted on: 13 January 2010 by Aleg
quote:
Originally posted by JYOW:
I am not familiar with Popcorn hour but I thought it is a video player first and foremost. Are you implying that it would sound better than streamers like the Linn DS, HDX when played over the network and the Transporter, amongst other streamers?
I don't know if it is a match for those other players, I can't check that.
It is indeed foremost a videoplayer, but plays 96/24 (and AFAIK up to 192/24, but haven't been able to check since my current DAC is only up to 96/24) audio as well.
quote:
Just to make sure we re in sync, what is your definition of a streamer? My impression is most of the high end network players out there buffers and stream music over the network.
As we speak I am playing my music over a network NAS off iTunes and a Weiss DAC. DO you consider that a streamer?
What I mean by streamer solution is a setup whereby music server on the NAS is required to be able to access your audio files, e.g. the Twonky Mediaserver or the SB & SqueezeCentre setups. What I prefer is a setup that can just access files using NFS and not requiring a MediaServer in between. The UPnP-solution pushes audio out over a HTTP to a streamer client. I prefer the mediaplayer to pull the audio using NFS or SMB/CIFS.
NAS--(NFS/SMB)-->iTunes-->DAC is not streaming for me, that is just a "PC"-based music player.
Replace iTunes with Naim mediaplayer, like this NAS--(NFS/SMB)-->Naim mediaplayer-->DAC and I'm a happy man.
But if it is NAS + MediaServer--(HTTP)-->Streamer client-->DAC, then I don't like the "MediaServer --(HTTP)--> Streamer client"-part if it is mandatory.
The "MediaServer --(HTTP)-->" is unnecesarily complicated if "NAS--(NFS/SMB)-->" is also available in a local network.
-
aleg
Posted on: 13 January 2010 by rich46
quote:
Originally posted by Asenna04:
quote:
Originally posted by JYOW:
quote:
Originally posted by Aleg:
quote:
Originally posted by David Dever:
quote:
Originally posted by Aleg:
Probably not eh, since it is still UpnP, which is an architecture they should ditch alltogether, because it is a useless addition to local network filesystems.
I'll just wait and see.
One thing for sure, I'll not be buying a UniQute either. I don't want to pay for all the useless parts that come with a one-box-for-everyting solution.
So I'll just wait and see....
-
aleg
If you cross UPnP off your list, there goes the Linn DS units as well, and (at their core) Sonos and Logitech devices.
Right, I am indeed not interested in those solutions either.
The streaming concept was developed to deliver audio/video over the internet with small pieces a time not needing to download the whole file first and at the same time preventing the listener/viewer can get his hands on the complete source files. It is a broadcasting model for the broadcasting industry.
UpnP-devices are nice devices to connect to these internet broadcasts, if that interests you. But there is no audiophile level of broadcasting yet (if ever), it all is still some level of lossy audio.
Within a local area network, with local (NAS) storage of preferably lossless audio files, these arguments don't stick. Within a local network there is no need to put in a streaming server (Twonky e.g.) and start broadcasting audio around your local area network. A networked media player can just access the file on the fileserver directly, it need not be streamed. There is no delay of access, bandwidth in a local area network is more then sufficient for all audio or video playback. Playback can be gappless. Adding a streaming server is IMO again a useless addition within a local area network.
A Naim mediaplayer/streamer, on my part, doesn't have to be a UpnP streamer (I'm not particularly interested in internet radio broadcasts). For playback from my local area network NAS it just needs to be capable to access at least NFS-exports and/or support the SMB/CIFS-protocol for file access and be capable of playing a few popular lossless audio codecs.
The files are directly available on the local network, so just
get them and don't start streaming them first.
-
aleg
Is this dislike of "streaming" based on actual listening of other network "streamers" or based on the OP's association of "streaming" with low res Internet radio?
Network streamers like Squeezebox/ Transporter/ Linn DS/Meridian Sooloos buffer lossless audio up to 24/192-Khz over the network beautifully. In fact, similar to the Naim DAC, the buffering of audio data an help to ensure audio date is “clocked into the memory at the incoming inconsistently-timed rate.”
Incidentally, Linn is so confident about "streaming" over the network that they are literally betting their farm on streaming audio by announcement the termination of their CD players range in favor of the Linn DS architecture.
Completely agree.
ASenna04
streaming i guess is both streaming via the net, streaming from a nas, for convience of listen to all my collection 2000 plus ,ive ripped them and use sonos and the naimdac with great results. yes linn have gone that way. guess no one wanted their cd players anymore
Posted on: 13 January 2010 by Aleg
quote:
Originally posted by Aleg:
I don't know if it is a match for those other players, I can't check that.
It is indeed foremost a videoplayer, but plays 96/24 (and AFAIK up to 192/24, but haven't been able to check since my current DAC is only up to 96/24) audio as well.
-
aleg
Just a small addition to the PopcornHour information from my previous post:
The chip in the (new) Popcorn C200/A200 supports DTS-HD MA and Dolby True HD audio specs, which allow 192/24 in 2 channels or 96/24 in 8 channels. I don't know if it indeed fully supports all the allowed bandwidth/channel combinations, the documentation isn't that specific.
-
aleg
Posted on: 13 January 2010 by JYOW
>> What I mean by streamer solution is a setup
>> whereby music server on the NAS is required
>> to be able to access your audio files, e.g. the
>> Twonky Mediaserver or the SB & SqueezeCentre
>> setups.
The way I understand it, Squeezeboxes already have all the intelligence build in to play audio files. In fact, the new Squeezebox Touch can play tracks from USB memory sticks directly. Buffering is also built in to the Squeezebox memory.
The main reason for the server is to organize the music files, which I think is an essential feature. This leaves the playback device more CPU cycles.
>> What I prefer is a setup that can just
>> access files using NFS and not requiring
>> a MediaServer in between. The UPnP-solution
>> pushes audio out over a HTTP to a streamer client.
>. I prefer the mediaplayer to pull the audio using NFS
>> or SMB/CIFS.
As mentioned above, the main purpose of the server is not to stream the music. I am not technical enough to know if the server is in fact serving music in streaming mode, or simply just point the player to the right files.
>> NAS--(NFS/SMB)-->iTunes-->DAC is not streaming
>> for me, that is just a "PC"-based music player.
>> Replace iTunes with Naim mediaplayer, like this NAS—
>. (NFS/SMB)-->Naim mediaplayer-->DAC and I'm a happy man.
I thought the same way about not wanting a PC. But after using a Macbook and a ASync Firewire Weiss DAC. I find that both the media client and PC solution can work out very nicely.
>> But if it is NAS + MediaServer--(HTTP)-->Streamer
>> client-->DAC, then I don't like the "MediaServer –
>> (HTTP)--> Streamer client"-part if it is mandatory.
I think it would not hurt for you to at least audition the other options. Theory is important, and you seem very well versed in the *computer* domain. But what I find after all these years is the devil is in the implementation. There is no hard and fast rule that one technology is always better than another.
>> The "MediaServer --(HTTP)-->" is unnecesarily
>> complicated if "NAS--(NFS/SMB)-->" is also
>> available in a local network
Again, it is difficult to comment unless one knows how the different servers operate. Simply saying HTTP sucks is too general.
I am sure if you post a similar post to the Silm Devices forum, someone like Sean Adams will step up to explain how their server architecture works.
Posted on: 13 January 2010 by Aleg
quote:
Originally posted by JYOW:
...
>> complicated if "NAS--(NFS/SMB)-->" is also
>> available in a local network
Again, it is difficult to comment unless one knows how the different servers operate. Simply saying HTTP sucks is too general.
...
Hi JYOW
Thank you for your reply.
I don't think that in general streaming over HTTP sucks, it probably works or eventually will work well. Everybody seems to jump onto the UPnP-bandwagon.
My only point in "resisting" the http-streaming mediaserver solution, is that it is unnecessary complicated technology for just playing audio in a local network.
This http-streaming was developed for playing media over the internet with all its limitations and not for playing media in-home on local networks where those limitations are not present.
thanks for the discussion and I think we can close it here. I will see if I can get myself onto the Silm Devices forum.
-
aleg
Posted on: 14 January 2010 by goldfinch
Optimised transmision protocols for AV streaming are currently under development, I think we can take for granted that in a few years time current UPnP apparel will become obsolete.
What I wonder is if UPnP technology can compromise SQ of music streamers in some way. Firewire, Async USB are alternative methods for streaming from computers, do they offer more SQ potential over UPnP streaming?
Posted on: 14 January 2010 by Eloise
Well aleg's solution exists if you have a bit of computer knowledge...
Buy a Mini ITX Intel Atom motherboard (make sure it has a PCI slot and is fanless), add a case, 4GB memory, a small SSD and either ESI Juli@ (cheep) or RME 9632 (more expensive) card for digital output. Install Linux and MPd and point it to your NAS - perfect solution.
Or buy a Auraliti player which is the same pre-built / configured.
Posted on: 14 January 2010 by Richard Dane
This thread was almost ruined by a couple of forum members who broke the cardinal forum rule: No For Sale or Wanted ads
I have cleaned it up. In future, please be more considerate as it can sometimes mean an entire thread gets deleted, which is a shame. It also means that time is spent cleaning up when it might be better spent helping somebody out on the forum.
Thank you.
Posted on: 14 January 2010 by Aleg
quote:
Originally posted by Eloise:
Well aleg's solution exists if you have a bit of computer knowledge...
Buy a Mini ITX Intel Atom motherboard (make sure it has a PCI slot and is fanless), add a case, 4GB memory, a small SSD and either ESI Juli@ (cheep) or RME 9632 (more expensive) card for digital output. Install Linux and MPd and point it to your NAS - perfect solution.
Or buy a Auraliti player which is the same pre-built / configured.
Eloise
One could indeed easily build such a device like you say.
The only point
I have is that is uses all general purpose components, and one would miss out on the expertise of Naim in component selection, design of circuit boards and shielding against interference which makes IMO a Naim truely a Naim.
But maybe I might give it a try onetime. It would certainly resolve the only HiRes issue I have now with my PopcornHour in combination with mpd: the playback via mpd of 24-bit audio. The Sigma Design chip in the PopcornHour wants to receive 24-bit audio in a DVD-packed 24-bit LPCM format and mpd doesn't offer that conversion. So I now play 24-bit audio using the Popcorn-native Mono-player and 16-bit audio using mpd, which is not convenient, because you would have to know if the audio is 16-bit or 24-bit in order to select the proper player. Using a general purpose soundcard with proper Linux drivers, one could use the ALSA output with mpd and have 24-bit playback.
I still hope Naim will do something along these lines.
-
aleg
Posted on: 14 January 2010 by Graham Russell
Has anyone built a silent system and compared MPD on Linux with something like CMP/cPlay on Windows?
I've just built a silent system with a Juli@ PCI outputcard and have an ideal system to experiment with the options. It would be good to learn from experience of others in this area. I have a hunch that Linux will be a better OS for delivering real-time music streaming.
I'm running stripped out XP at the moment, but I think I will partition the disk (SSD) and install a Linux environment too.
Posted on: 14 January 2010 by Aleg
quote:
Originally posted by Graham Russell:
Has anyone built a silent system and compared MPD on Linux with something like CMP/cPlay on Windows?
I've just built a silent system with a Juli@ PCI outputcard and have an ideal system to experiment with the options. It would be good to learn from experience of others in this area. I have a hunch that Linux will be a better OS for delivering real-time music streaming.
I'm running stripped out XP at the moment, but I think I will partition the disk (SSD) and install a Linux environment too.
I read on the ALSA support page and also on the ESI Juli@ forum that using juli@ with ALSA for S/PDIF output might be a bit of a problem.
Juli@ is not a recommended soundcard for ALSA acoording to
this here.
aleg
Posted on: 15 January 2010 by Eloise
quote:
Originally posted by Aleg:
quote:
Originally posted by Graham Russell:
Has anyone built a silent system and compared MPD on Linux with something like CMP/cPlay on Windows?
I've just built a silent system with a Juli@ PCI outputcard and have an ideal system to experiment with the options. It would be good to learn from experience of others in this area. I have a hunch that Linux will be a better OS for delivering real-time music streaming.
I'm running stripped out XP at the moment, but I think I will partition the disk (SSD) and install a Linux environment too.
I read on the ALSA support page and also on the ESI Juli@ forum that using juli@ with ALSA for S/PDIF output might be a bit of a problem.
Juli@ is not a recommended soundcard for ALSA acoording to
this here.
aleg
I would say from reading that link that the results can be variable with the Juli@ but that generally it works - especially if you are just wanting SPDIF I/O ... the main problems seams to be with Midi.
Other places I've read suggest the Juli@ as a good card for Linux and ALSA.
According to ESI website it's Linux ALSA compatible too.
Eloise
Posted on: 20 January 2010 by bhaagensen
quote:
Originally posted by JYOW:
The way I understand it, Squeezeboxes already have all the intelligence build in to play audio files. In fact, the new Squeezebox Touch can play tracks from USB memory sticks directly. Buffering is also built in to the Squeezebox memory.
The main reason for the server is to organize the music files, which I think is an essential feature. This leaves the playback device more CPU cycles.
It is correct that the Touch can play files directly off memory sticks. However it is still based on a client-server architecture - the server, which is simply a downscaled version of the standard server, runs on the Touch and serves files to the Touch (and any other connected devices). Much like on Unix where X11 is a display server for local clients - if that helps.
Without intending to split words, in case of the Squeezebox family, the server is *not* intended for organising files/music. In fact it has, by design, read-only access to the underlying file-system. The server is essentially responsible for two tasks: 1) Serving files to the clients, i.e. Transporter, SB3 etc. 2) Providing "views" such that one can view the content of ones library. 3) Act as a control-mediator. I.e. ask the server to play a given file on a given device. The server then issues a play-command and the file itself to the given device.
Posted on: 20 January 2010 by bhaagensen
quote:
Originally posted by Aleg:
What I prefer is a setup that can just access files using NFS and not requiring a MediaServer in between. The UPnP-solution pushes audio out over a HTTP to a streamer client. I prefer the mediaplayer to pull the audio using NFS or SMB/CIFS.
-
aleg
Not sure what you mean by push and pull. But completely eliminating the notion of a central server has many possibly negative implications. In a way it falls back to the notion of a network of equal peers, i.e. peer-to-peer. Now this means that whereas in the case of a client/server architecture where one can distribute significant portions of the required logic on the server and rely on rather simple clients, all peers will need to be able to handle more of that logic. In simple terms, more computing power is needed at each node. This is obviously inefficient for many reasons.
However it is necessary with such logic, because NFS/SMB/CIFS are really nothing but rather low-level abstractions of the file-system (an abstraction tailored towards network-accessibliity). Without any layer on top of that, there is no way (for generic file-systems) to handle things such as tagging. Moreover filesystem performance scales far to poorly for even simple operations such searching (e.g. find album X by artist Y, or find all rock-albums). For this to work other data-structure abstractions are needed , a prime example being databases.
Not to mention more advanced features such as remote controllability (over the network), synchronisation, etc. which would essentially be impossible to achieve without some notion of server.
Posted on: 20 January 2010 by Aleg
quote:
Originally posted by bhaagensen:
quote:
Originally posted by Aleg:
What I prefer is a setup that can just access files using NFS and not requiring a MediaServer in between. The UPnP-solution pushes audio out over a HTTP to a streamer client. I prefer the mediaplayer to pull the audio using NFS or SMB/CIFS.
-
aleg
Not sure what you mean by push and pull. But completely eliminating the notion of a central server has many possibly negative implications. In a way it falls back to the notion of a network of equal peers, i.e. peer-to-peer. Now this means that whereas in the case of a client/server architecture where one can distribute significant portions of the required logic on the server and rely on rather simple clients, all peers will need to be able to handle more of that logic. In simple terms, more computing power is needed at each node. This is obviously inefficient for many reasons.
However it is necessary with such logic, because NFS/SMB/CIFS are really nothing but rather low-level abstractions of the file-system (an abstraction tailored towards network-accessibliity). Without any layer on top of that, there is no way (for generic file-systems) to handle things such as tagging. Moreover filesystem performance scales far to poorly for even simple operations such searching (e.g. find album X by artist Y, or find all rock-albums). For this to work other data-structure abstractions are needed , a prime example being databases.
Not to mention more advanced features such as remote controllability (over the network), synchronisation, etc. which would essentially be impossible to achieve without some notion of server.
Hi Bjørn
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
Posted on: 21 January 2010 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.
