Squeezebox Touch -- Modifications

The battery sits behind a switch, plug and perhaps even a fuse.
These do impact the performance. You should verify this.

A quality low ESR cap array ( Epcos Sikorel/Rifa) IMO still performs better then a plain battery.

Hint: You might also try a Bybee in the line.

Cheers

I know that the wire, switches, etc have impedance values (usually low) BUT it is not frequency dependent as a capacitor is! I found that even using Sikorel that the sound slowed down & suffered in the dynamics department.

Please don't get into Quantum noise blah, blah with those Bybees - it's more than I can bear.
 
Soundcheck, first thanks for your mod and your work.

I want to apply your ethernet mod, but it`s impossible for me to connect without wlan. The only alternative would be to connect with devolo dlan products.

What do you think about this? I can imagine that internet via electricity produces a lot of noise.
Has anyone experience with dlan and hifi?

Cheers
 
modifications to the squeezebox touch

noted the software downloads, etc required to improve the performance of the touch. Unfortunately now running windows. Running Squeezebox Server on a NAS: Infrant / Netgear Ready Nas NV+.

Any ideas as to what files to install to improve the performance as described by you for a windows system? Instructions would be appreciated as well.

Thanks in advance.
 
Soundcheck, thanks for the tips on modifying the Touch.

I have noticed a huge improvement after getting rid of the WLAN and unplugging the front touch panel.

Previously I was running strictly off the USB hard drive but I am surprised by using the Server to output uncompressed PCM stream to the Touch made a noticeable difference in sound quality in terms of the dynamics.

I would highly recommend trying the soft mod out and also removing the front panel is truly worth the effort.

If it matters I was running Squeezecenter within the Touch using a super low power Solid State Drive off a linear power supply of course.

The next thing I would like to do is probably try the Battery :)


Cheers,
 
noted the software downloads, etc required to improve the performance of the touch. Unfortunately now running windows. Running Squeezebox Server on a NAS: Infrant / Netgear Ready Nas NV+.

Any ideas as to what files to install to improve the performance as described by you for a windows system? Instructions would be appreciated as well.

Thanks in advance.

Hi.

All my modifications can be applied from any OS. I described how to do it at the blog.
The main challenge is to get logged in into the Touch and to transfer a file to it.
In principle you just need an SSH application to transfer my config-files from Windows/OSX/Linux to the Touch-Linux.


Please, let me know if my instructions are unclear or faulty.

Cheers
 
Soundcheck, first thanks for your mod and your work.

I want to apply your ethernet mod, but it`s impossible for me to connect without wlan. The only alternative would be to connect with devolo dlan products.

What do you think about this? I can imagine that internet via electricity produces a lot of noise.
Has anyone experience with dlan and hifi?

Cheers

Hi.

I don't have any experience with powerlans.

This is what I think about it:

1. The mains-cabling is usually not shielded. You'll get a nice antenna
by running MHZ signals over it.
2. The powerlan adapters need to be on the same mains-phase or you need
to introduce a so called phase-coupler.
3. And yes -- you are right. We don't want more garbage on the mains and
ground then we already got.
4. The bandwidth of powerlan is still kind of low. I am sure that the data
will face a lot of "resistance" from point A to B. I am sure its bandwitdh will also vary a lot. This would make it not really the ideal solution for continuous media-streaming.

Though I think powerlan could still be better and stable then a WLAN connection in terms of bandwidth-variations - it's just the lesser of two evils.


Advise: You should consider that meanwhile TV-sets etc. also require ethernet connections. Sooner or later it is IMO a must to have at least GBIT-lan in the living room. Those IP networks need a lot of headroom to perfom best. I introduced CAT7/CAT6a wiring. Do it right, you'll do it once. ;)

Cheers
 
Where are the coupling caps for the audio output that need to be bypassed?
Do these caps need to be replaced externally?

thanks

ed

Just could just short-circuit the caps.

According to John Svensson - he is running the device that way - the Dac chip can be DC coupled.
No need for an extra cap. You might look up the DAC datasheet.

Don't blame me if you smoke that device!! It's on your own risk.

I havn't done that mod by myself.

Good luck.
 
Last edited:
Just give it a try. No further discussions from my side!

Why not trying to change something else, just pick anything randomly. It would be about the same.

This "tweak" has absolutely no logical and technical sense, unless the device is used for movie sound and the default latency is too large which I very doubt is the case. Well, increasing the latency to minimize risk of xruns and reduce CPU load would make sense to me, but reducing absolutely not.
 
Why not trying to change something else, just pick anything randomly. It would be about the same.

This "tweak" has absolutely no logical and technical sense, unless the device is used for movie sound and the default latency is too large which I very doubt is the case.

Please don't highjack this thread. We've had these kind is discussions a hundred times over at the Linux Audio thread.

Write your own blog about "your opinions".

I provide a script and instructions. Real stuff. Not just hot air statements. Everybody can try it. And remove it!

The new scripts let you even toggle the mods to do ABX testing more easily.

On purpose I don't even say what to expect.


I don't have to explain nor I have to sell anything here!!!!! Period.

I am putting quite some free-of-charge efforts into all that..I'd expect you to respect that!!

I'd appreciate constructive feedback. That's about it.
 
My feedback is - reducing alsa buffers will reduce latency, on the other hand increase the risk of dropouts and increase CPU load while bringing no audible improvement as there is absolutely no reason why it should. That is as constructive as it can be.

If you would have read my blog, you'd stepped over a remark about XRUNS on low buffer sizes I've been experiencing
by choosing lowest buffer values.

I'd assume that you neither read the blog, nor that you've tested the modification proposal.

Your feedback doesn't add any value and just follows a well known and a hundred times experienced purpose.
Again -- I'd appreciate if you would stay out of this thread with this kind of attitude!!!!

Constructive feedback I consider:

1. script improvement proposals (I am not a programmer)
2. blog improvement or correction proposals
3. new tweak ideas
4. tweak improvement proposals
5. experiences


THX
 
Last edited:
If you would have read my blog, you'd stepped over a remark about XRUNS on low buffer sizes I've been experiencing
by choosing lowest buffer values.

I'd assume that you neither read the blog, nor that you've tested the modification proposal.

Your feedback doesn't add any value and just follows a well known and a hundred times experienced purpose.
Again -- I'd appreciate if you would stay out of this thread with this kind of attitude!!!!

Constructive feedback I consider:

1. script improvement proposals (I am not a programmer)
2. blog improvement or correction proposals
3. new tweak ideas
4. tweak improvement proposals
5. experiences


THX

Soundcheck,

I have read your blog. I did not find any explanation why reducing the buffers should make
any difference, what is the intention behind the tweak your highly recommend.

IMO, if you want to reduce CPU noise, the ways are:

* maximizing buffers in the player and the DMA buffers (buffer_size of alsa)

* raising MTU of ethernet packets from the sound server to make the communication as rare as possible

* shutting down all unnecessary services - you have done that

* shutting down all unnecessary hardware - if the information how to do that is available

* running most calculations on the server

* reducing CPU clock, voltage (if possible)

Plus improving the PSU, feeding the audio part from separate PSU, improving the audio part clock, if it has a separate crystal (we could find out that), improving the analog part (not an easy hack though), and many other tweaks. All of this makes sense to me.

I will not buy the hardware as I do not need it.
 
What you state you'll find pretty much on the blog (as scripts that everybody can run -- this is not just talk!) and in the Linux Audio thread I started 4 years ago.

That's nothing new.

I am telling you. you are wrong about your theoretical buffer philosophy
in the case of SB Touch - at least when is comes to the listening experience!

Unfortunately you have to stay on a "philosophical side", since you
don't even own the product.
I said that already twice. This is the wrong place for you!
There comes absolutely no value with your postings.

Open up your own thread and fill it up with your own wisdom and measurements. I'm really getting tired of this bu..sh.. .


Thx