I’ve just upgraded my NAS from an old single core device to a device with a much more recent 4 core CPU and with double the clock speed (it’s a Synology DS218Play) because I wanted to run some other applications on it. Well that worked fine, it’s also more responsive and it scans it’s disk a lot faster.
However, what I didn’t expect was an improvement in SQ from the 272.
OK, it’s not night and day and the blackness isn’t dramatically more inky; but the sound is definitely a little ‘cleaner’, with less background smearing of details.
I don’t know for certain why this should be, but there’s a possibility that with the four cores available it’s able to give significantly more even response times to the 272’s requests for more data, thus giving a smoother feed to the streamer. I know that S-i-S found that a more even flow of data packets to the streamer sounded better, so this possibility fits.
I’m curious about this as well. I have had a 272 since March and have been disapointed with the streaming section. I wonder if my QNAP TS 231P is holding back performance. It’s routed by a Cisco 2960 with AQ Forest to the QNAP and AQ Cinnamon to the 272.
I’ve recently converted all my FLAC files to WAV rather than transcoding on the fly as is the norm. Obviously I had done some testing first and the differences were significant, too much to ignore.
My QNAP is an ARM 4 core and had enough power to run ffmpeg with ease. My Raspi performed similar to the QNAP with ffmpeg using less than 10% CPU.
Congrats on the new Synology Xanthe, how did you transfer the files ?? two new HDD’s & copy over. Dare I ask about RAID?
I was pondering a change from my DS214 to get 4K video, looking at the same 218Play & the 218+ or moving over to QNAP.
Re the SQ change, a mate found the same when he moved his audio from an old 4 bay QNAP (also his business files) to a top end 2 bay QNAP.
I went from a synology ds213j to a synology ds218play about a year ago and found it gave a noticable lift in sound quality, infact quite a noticable lift. Im using minimserver rather than the synology media server as I also found this gave a positive result too.
OMG, let’s hope this doesn’t start a rush on people buying new NAS machines and an outbreak of NIC (Nas inferiority complex). Will the Synology become this year’s Cisco 2960 8TC-L… Who will be the first to say ‘my new Synology kicks the Melco into the weeds’ or ‘my Synology makes my old Qnap sound broken’? Aarrrrgh…
Hi Mike, simple, back up to an external drive and restore to the new drive.
Not going RAID (the MTBF of the Segate Iron Wolf drives is greater than the MBTF of the NAS hardware, so little point in RAID1); instead I’ll use the 2nd drive as a target for an incremental backup.
The backup drive won’t be writable from the rest of the network, only writable from a specific user account on the NAS. This way if my PC were to get hit by a ransomware virus, the backup up until that date would stay clean. Also not being RAID, then, if the NAS hardware fails rather than the disk, it’s restorable on any Synology NAS, nor just one with a similar configuration and/or CPU.
Indeed. RAID is not a backup solution anyway so you’ve made the right decision. It’s a resiliency solution for ensuring uptime in event of failure while you replace a disk. That’s very different from backup.
Confusing the two burns no end of people when something like the RAID controller dies instead of a disk.
Hi FZ, funnily enough I was a professional systems designer, so I’ve also frequently been telling people that RAID is not backup (I have the master version four levels of backup - one offsite).
As an aside, this exchange suddenly made me curious what the I in RAID stood for these days. In my youth it was Redundant Array of Inexpensive Disks, but it’s been decades since RAID arrays were made up of banks of consumer drives, Wiki tells me it’s now also Independent.
Why?
It won’t necessarily work any better or worse in @nicnaim’s system.
For that matter why not try a variety of Cat5e and Cat6 patch cables - they’re just as likely to improve the sound as anything else from the AQ forest through to the Chord Music; when talking about Ethernet cables price, fancy materials and fancy cable construction has no bearing on the matter.
AQ forest is the worst Cat cable I have tested in many streaming systems with different makes. It is clinical and cold.
It was just a suggestion for improvement. Chord C-stream Ethernet cable is marginally more expensive than forest … but it sounds soooo much better.
Good luck.
I tried a few ethernet cables. First freebie cat 5e cables, then cat 6 belkin. Then meicord opal, audioquest cinnamon and audioquest vodka.
In my system the vodka sounded a good margin better than the rest. The cat 5 sounded harsh and muddled, the belkin became less harsh but the meicord gave more depth although it sounded a little too warm for my taste. The cinnamon was cooler sounding, almost a little clinical but I kind of prefered this compromise to the meicord compromise. Then I reluctantly tried the vodka, vowing that I would not buy an ethernet cable at this price. When I heard it I soon changed my mind. It had far more depth and soundstage, and the separation was by far the best I had heard.
Between the synology 218play, vodka ethernet cables and cisco 2960g switch I now feel I’m hearing my nds better than ever before. Its been a bit of a learning curve but I’m so pleased I took the time and effort experimenting.
It will depend on your electrical environment as well as the streamer and switch, If you tried enough Cat5e and Cat6 patch leads you’d come across one that sounds as good as the Vodka.
In my case (with the 272, Cisco 2960 and my electrical environment) all the screened cable I’ve tried have sounded substantially worse than all the UTP cables!
Hi Xanthe, I had noticed this before very early on with my experience with Naim streamers and I investigated why… and eventually shared my findings with Naim when they were developing the new streamers.
On the legacy streamers I found that the inter Ethernet frame timing consistency from the media server during media transfer bursts had a direct bearing on the SQ from the streamer. I found this timing consistency was not necessarily related to the power of the media server… but was more down to OS, drivers and Network Interface hardware and sometimes application.
Similarly I also found that burst media transfer using the zero window size semaphore approach (as often used when locally streaming via Ethernet) sounded better, than a more steady TCP transfer. This was one reason why I discovered using reverse proxy protocol breaks could transform services like Tidal to sound like local streaming.
