NVA 'TFS': 'The Future Statement' lands at Marco Towers...

[Welder]

I'm not trying to pick this product apart, I'm just curious as to the choices that have been made.
Windows is very difficult to work inside. Generally one has to lever something else into the OS to make major system changes.

Same interest in the choice of JRiver. While I think it sounds okay on Win7 with the supplied asio drivers for example, imo it doesn't sound as good as ALSA or even OSS drivers with a Linux player.
Also considering the starting point for Windows is have everything running just in case and Linux is having nothing running and let the feckers work out how to get anything to run, having the least running would seem the most sensible and most of the servers I've heard that I thought sounded good ran on Linux.
Then of course there is the cost; both Win and JRiver cost money.
Same with the audio card.
Generally audio enthusiasts would seem to prefer a separate Dac; it gives greater flexibility.
I can see the attraction and commercial sense in providing a complete music centre and if it can put a digital smile on Marco's face it's got all my thumbs vertical.
Does such a configuration give the best sound though and may some be paying for features they really don't need.
I appreciate this is an early product and changes may be coming later. I'm just curious.

[Lodgesound]

I have to say that overall the price of this unit seems entirely reasonable.

True one can build a PC for around 2 or 300 pounds which will process all the data you need and more - both image and audio.

The problem comes when taking the signal out of the computer and into the outside world. In the professional and archiving world we use high end audio interface units made by the likes of MOTU or Prism costing around £700 - £2200.

I have two production computers which I built myself to these kind of specs - including the interface and operating systems coupled with half decent production software they were around £2500 each (around one tenth the cost of a high end analogue tape recorder in 1987).

I would be intrigued to hear it - are you bringing it to Scalford Marco?

[Mark Grant]

It's good to see Marco has a computer in his system at last

Have you got Spotify on it yet Marco ?
You might be surprised how good it can sound.

[Marco]

Sadly not, Stewart, as we don't have a room of our own this year, and the system we're putting some bits into (John's) already has a computer audio source in it.

However, I'll be bringing my Techy, Croft preamp and Tube Distinctions power amp, so if you're interested in hearing any of those, pop along to Syndicate 15, on the first floor

Marco.

[Figlet108]

... So, should you wish to include some DSP, or even a basic room correction application having just one core dealing with audio and the other or others dealing with system processes may be of some benefit.

Ok, I now see where you are coming from.
So, the question of optimal process and thread scheduling on multi-processor, multi-core and multi-threaded systems is both very interesting and very complicated. When I was doing my computer science PhD at Manchester Uni back in the 90s there was loads of research into this and it continues unabated.
I also ran a project for my employer in 2008-2010 for optimising enterprise systems' workloads dynamically and automatically by using processor and memory affinity algorithms.

Without getting too off-topic, the current wisdom and state of the art is to let the processor and the OS figure out between them how to best load balance a workload across all the available threads/cores/processors since they do this dynamically using real-time data and can make the best possible decision.

If you or the programmer force affinity you will almost certainly be running your system less efficiently, as the optimal affinity characteristics of any workload change constantly due to many complicated interactions that is impossible for the programmer or you to possibly know ahead of time.

It also turns out that Windows 7 already does a very good job of thread scheduling on Intel processors, and Intel and Microsoft always work very closely together to get the best out of a system - they have to as they depend on each other.

In your particular example you might be starving the audio playing processes of needed processing power by restricting them to just one core when they really wanted 1.5 cores worth of work and you end up with the audio stuttering and 3/4 of the other core sitting idle because the system is sitting there with not much to do.

My strong recommendation to you is to not waste time with that line of investigation and not only because of what I say above.

Consider also this. Most good audio playing software will buffer the audio data to reduce the likelihood of mis-timing. In the case of JRiver there is an option to load the entire track into memory before starting to play. Even with room correction the load on the processor is pretty minimal. Try it and see what load % you get with the ps command on linux.

Regarding Data and OS on same drive. If anything is going to feck up its going to be the OS and that could easily mean losing all those tunes you've spent so long ripping assuming one cant rescue the system.

Well all disks can and will die at some point - they have a limited life span. So all important data needs to be backed up whether it's on the same disk as the OS or not.
If your point is that the OS may somehow get corrupted and become unbootable, well that doesn't affect the data on it. Just put the disk in an enclosure and copy the data off it. Although as I said above, you should be backing up your data wherever it's stored.

[Tim]

Well I don't intend to get too embroiled in the complexities of this thread, but I have read the posts over the last 2 days with great interest. I was rather surprised by some persistently negative comments, but very pleased with the response from your good-self Marco. Hats off for embracing it and giving positive reviews to what is undoubtedly a good product.... in fact the specs provided by Jason earlier make it very nearly a dead ringer for my current system (apart from the PSU and DAC end) and I know how good mine sounds

I feel rather pleased that file based audio is marching on from strength to strength. I do have to add a small comment about the digs on price by some..... yes some of us can probably build the same or similar for less, but that's a component price..... I'm not sure what price I would put on how many hours of blood sweat and tears I have spent getting to where I am now, how much is that worth? But much more importantly, the number of people that are capable of doing such a thing is very small, even on this forum. My best mate has been hugely impressed by my server, but wouldn't have a clue how to build one and would happily pay the asking price of the TFS. A fully developed and marketed product is never going to be anything near how much 'you can buy the bits for'. It's just ridiculous to compare the two IMO and then the producers also need to make a profit, or what's the point in doing it?

Anyway, I'm chuffed you like it Marco and chuffed that NVA seem to have produced a great product that I think is realistically priced for it's place amongst similar products..... (I do think the case is fugly though )

Nice one

[Figlet108]

I certainly wouldn't want to be running Windows on a music sever.

You know John I have to smile at that -

Over the past 20 years I've heard every religious war there is regarding all the infinite choices humans have to achieve the same thing.

That statement is just another one of those.

The truth is that Windows, Mac and Linux are all perfectly capable of producing exceptional audio depending on how the entire hardware and software stack are put together. There are pros and cons using each and where one is better or easier than the other in one respect it's worse in another...

[Alex_UK]

Amen to all that, Tim.

[Figlet108]

John.

Core optimisation ? Well as I understand it it's the other way round. This is a software issue. Basicaly programmes have to be written in a certain way to utilise multicore processors. Earlier programmes for instance will not benefit as they will use a single core. Try thinking from that angle.

Paul.

Paul it's actually much more complicated than that. For example a processor that contains an out of order processing architecture (as many modern ones do) can schedule a single thread of instructions to multiple execution units on multiple cores.
In other words the 'multi-threading' is done at the architectural level not the programming level.

[Figlet108]

Windows is very difficult to work inside. Generally one has to lever something else into the OS to make major system changes.

John, nothing needs to be done to the OS. You are worrying about a problem that doesn't exist. The audio processes bypass the OS entirely and work directly with the audio hardware - it's really that simple.

Same interest in the choice of JRiver. While I think it sounds okay on Win7 with the supplied asio drivers for example, imo it doesn't sound as good as ALSA or even OSS drivers with a Linux player.

Another religious argument. I'm genuinely pleased for you that you have put lots of effort in setting up a Linux based server and that it makes you happy.
For me Linux wasn't the right tool for the job.

Also considering the starting point for Windows is have everything running just in case and Linux is having nothing running and let the feckers work out how to get anything to run, having the least running would seem the most sensible.

In general, for the reasons I've already stated this is a red herring and not based in any fact that I have been able to measure.

Same with the audio card.
Generally audio enthusiasts would seem to prefer a separate Dac; it gives greater flexibility.

Well I guess you are missing the point of this particular product. It's specifically designed to be used as an all in one. The product that is designed to be used with a DAC is the one I'm working on now - the transport-only version. Some audio enthusiasts want an all in one with a built in DAC and some don't. They are 2 separate products.

... may some be paying for features they really don't need.

Well not really, as the person that buys the TFS knows they are getting an all in one solution. If someone specifically just wants a transport to plug their existing DAC into then the TFS is a poor choice. Better to wait for the transport-only version.