Squeezebox Touch/DAC vs Transporter/ DAC vs Memory Stick/DAC

I did all of them many times.

Transporter produces the best results overall. Memory stick is the second one. SB Touch is obviously worse than both memory stick and TP and the iPod comes even more vague.

The difference is quite subtle and many will not feel it justifies the price difference between, say, SBTouch (300 $) and TP (2,000 $).

OTOH many other people around here pay K$ for the smaller difference between CD players.

I'm actualy trying some adjustments into the settings of my SB Touch to optimize its performance.

The server's default settings are set for multiple client stations, minimizing network bandwidth usage and saving the hosting computer's system ressources by transfering most of the music files rendering/decoding job to the client stations (SB Touch or any other compatible stations).

So I went into "file types" into the advanced settings of the server console, and set the only output option to be the PCM on all the file types when it was available, and disabled all other possibilities of rendering/decoding.

By doing so, I'm forcing the server to do the rendering/decoding of the music files, and send the resulting data to the SB Touch into the form of PCM signal. So about the only task remaing for the SB Touch is to convert PCM into SPDIF (which is a light work load).

Also, I was astonished to learn that about half of the supported music files of the SB Touch are converted to FLAC by the server before being sent to client stations. Believe it or not, WAV and Apple Lossless are in the batch!  So you're also saving non necessary file conversions by doing this tweak.

I would advise not to modify any of those advanced settings if you're using multiple SB stations, mainly because you'll probably get your home network bandwidth satured by the extra data required by streaming PCM signal instead of FLAC, especialy if you're using WiFi.

NB: Those settings are included into the software supplied with the SB Touch. So what I'm talking about above is totaly supported by the manufacturer.

Bye.

But, suppose you were sending FLAC at the usual compression level of -5, by making the server do the transcoding you will have doubled the network traffic your squeezebox has to cope with and doubled the work it has to do decrypting, so why do you assume it is working less hard when you have made it manage twice the amount of data? Have you measured any difference? Maybe there is a good reason why, by default, squeezecenter transcodes WAV to FLAC.

The only reason I see is to minize network traffic, so you could have more than one Squeezebox running at the same time on the network.

Those changes in settings made an audible difference. Is it significant? I think so, and for the better.

I'm running out of lunch time, I'll be back late tonight on this.

Bye.

On a side note, I did a little research about what's inside the SB Touch, I was looking specificly for system ressource and CPU. It's basicaly a Freescale i.MX35 board with a 533 MHz ARM11 CPU and 128MB DDR2 RAM and 128MB NAND Flash EEPROM.

Source: http://wiki.slimdevices.com/in.../Hardware_comparison

In simple terms, it's a high performance microcontroler that you could find into multiple devices around you, including smartphones, state of the art printers, photocopiers, etc... Naim is using one based on the ARM9 CPU into the NDX, mainly for running UPnP features and tasks.

@Likesmusic: Now to answer your question about the increase on the data flow, it's impossible for me to test how it's affecting the EMI, IC temperature, CPU usage, memory buffer behavior and other parameters like this. But one thing I know is that modulating PCM to be carried by SPDIF (at CD resolution) is a task carried quite successfully by about every CD players with a digital output made those last 25 years. It's a task carried on the fly by very simple logic circuits (that could introduce a lot of jiter, I know. I took the Naim 101 crash course about it a long time ago ), so the SB Touch role is almost reduced to a data relay when you're sending PCM signal to it. It no longer have to decode FLAC files that will eventualy inflate at the end of the process to the same size as PCM anyway. It will leave the SB Touch more system ressources to drive that beautiful clock screensaver (with more accuracy, I hope ).

So if you want to test out a SB Touch against a Naim UPnP server or client. I would suggest you to try  setting up the SB server software the way I did. IMO, it sounds better this way.

Bye.