That's what makes it fail. Somehow I never managed to run a DSPed
stream as PCM stream down to the Touch.
I always had to convert the stream back to flac before sending it down.
@sinski, @soundcheck:
I have flac -> dsp -> pcm working, with brutefir/brutefirdrc as the dsp engine. I don't know what drc system you are using, so my code my not work with yours.
The basic strategy is to send pcm in the format expected by the SBTouch via the pipeline. For brutefir with flac output:
(flac) -> sox -> (format brutefir expects, 32-bit float, raw, sample rate XXXXX etc) ->brutefir -> (pcm) -> flac encoding (must know what sample rate to expect)
With the above, the config is restricted to one sample rate since brutefir filters are for a fixed sample rate. Toby Dickenson wrote a neat wrapper which provides support for different sample rates, plus other niceties.
sox -> brutefirwrapper -> (wav) -> flac
To use the wrapper for pcm, the wav output from brutefirwrapper should lose the wav header, either by a mod to the python wrapper, or replacing flac with a program that will strip 44 bytes off the beginning of a file (eg. dd).
Hope this is useful. The important thing to remember is that is seems SBTouch expects the pcm at the same sample rate and word format as original, so 96/24 flac should be sent as a 96/24 pcm, and 44/16 mpeg or flac should be sent as 44/16 pcm. In my case brutefir processes in 32 or 64-bit, and was configured to output in S24_LE, so 44/16 was an issue. I don't want to truncate back to 16-bits after dsp. The workaround was to re-rip my library to 24 bits irrespective. In space the cost is small as 24-bit flacs with 16-bit data use up just about the same space at 16-bit flacs (the compression is clever enough to know the 8 bits are not used).
I have flac -> dsp -> pcm working, with brutefir/brutefirdrc as the dsp engine. I don't know what drc system you are using, so my code my not work with yours.
The basic strategy is to send pcm in the format expected by the SBTouch via the pipeline. For brutefir with flac output:
(flac) -> sox -> (format brutefir expects, 32-bit float, raw, sample rate XXXXX etc) ->brutefir -> (pcm) -> flac encoding (must know what sample rate to expect)
With the above, the config is restricted to one sample rate since brutefir filters are for a fixed sample rate. Toby Dickenson wrote a neat wrapper which provides support for different sample rates, plus other niceties.
sox -> brutefirwrapper -> (wav) -> flac
To use the wrapper for pcm, the wav output from brutefirwrapper should lose the wav header, either by a mod to the python wrapper, or replacing flac with a program that will strip 44 bytes off the beginning of a file (eg. dd).
Hope this is useful. The important thing to remember is that is seems SBTouch expects the pcm at the same sample rate and word format as original, so 96/24 flac should be sent as a 96/24 pcm, and 44/16 mpeg or flac should be sent as 44/16 pcm. In my case brutefir processes in 32 or 64-bit, and was configured to output in S24_LE, so 44/16 was an issue. I don't want to truncate back to 16-bits after dsp. The workaround was to re-rip my library to 24 bits irrespective. In space the cost is small as 24-bit flacs with 16-bit data use up just about the same space at 16-bit flacs (the compression is clever enough to know the 8 bits are not used).
Double speed radio
After enjoying the SBT mods for several weeks, I discovered a strange phenomenon: some internet radio stations play-back at double speed !!
I have no idea which stations do so and which don't, but an example is "Radio Apintie", one of my doughter's favourites. Whenever I play that station on the modded SBT, it plays at one octave higher pitch and at double speed. After fiddling with some mod settings, I could trace the problem to one setting: "tttout".
Selecting "ttout -a" for analog out only, shows the problem.
Reverting to "ttout -n" activating all output devices, makes the problem disappear.
Has anyone encountered this same phenomenon and maybe found a cause and a solution?
After enjoying the SBT mods for several weeks, I discovered a strange phenomenon: some internet radio stations play-back at double speed !!
I have no idea which stations do so and which don't, but an example is "Radio Apintie", one of my doughter's favourites. Whenever I play that station on the modded SBT, it plays at one octave higher pitch and at double speed. After fiddling with some mod settings, I could trace the problem to one setting: "tttout".
Selecting "ttout -a" for analog out only, shows the problem.
Reverting to "ttout -n" activating all output devices, makes the problem disappear.
Has anyone encountered this same phenomenon and maybe found a cause and a solution?
In fact - you need to deactivate the output mod.
Those radio stations need the "plug" (=plugin) output device of Linux, which is part of the Logitech default output configuration.
That "plug" output sounds inferior to the "hw" output mode.
Somebody at the Logitech forum reported that the affected radio stations seem to run rates below 44.1/16. I havn't digged into it any further.
For sure you won't need the output mod to listen to those stations.
Cheers
Hello Klaus,
some days ago I upgraded to 7.5.3, both on Squeezebox Server and on Squeezebox Touch.
After that I tried to reinstall the mods again, but got some problems.
It seems that at least the ttbuffer script is not running correctly, as I can not set the buffersize to 4000 anymore.
See my output
# ttinit
________________________________________________________________
soundcheck's SB Touch Toolbox 2.00: Initialization
________________________________________________________________
Touch toolbox has been already initialised!
#
# ttstat
________________________________________________________________
soundcheck's SBT Toolbox 2.00: Modification Status
________________________________________________________________
Modification WLAN: disabled
Modification Watchdog: enabled
Modification Jive2: disabled
Modification Buffer: disabled
Buffersize: 20000
20000us
Modification Screen: disabled
Audio outputs: Analog: off Digital: on USB: off
Modification Kernel: enabled
# ttbuffer 4000
4000
sed: unmatched '/'
________________________________________________________________
soundcheck's SB Touch Toolbox 2.0: The buffer mod!
________________________________________________________________
Buffer set to 4000 us. Rebooting system.
________________________________________________________________
After reboot the ttbuffer is still as it was before.
# ttstat
________________________________________________________________
soundcheck's SBT Toolbox 2.00: Modification Status
________________________________________________________________
Modification WLAN: disabled
Modification Watchdog: enabled
Modification Jive2: disabled
Modification Buffer: disabled
Buffersize: 20000
20000us
Modification Screen: disabled
Audio outputs: Analog: off Digital: on USB: off
Modification Kernel: enabled
________________________________________________________________
#
You can see on the output of ttbuffer that sed complains about an unmatched /. I think this causes ttbuffer to write not down the settings on alsaplayer.
I can do that manually, but I think it would be more interesting to check why the upgrade causes the script to fail.
some days ago I upgraded to 7.5.3, both on Squeezebox Server and on Squeezebox Touch.
After that I tried to reinstall the mods again, but got some problems.
It seems that at least the ttbuffer script is not running correctly, as I can not set the buffersize to 4000 anymore.
See my output
# ttinit
________________________________________________________________
soundcheck's SB Touch Toolbox 2.00: Initialization
________________________________________________________________
Touch toolbox has been already initialised!
#
# ttstat
________________________________________________________________
soundcheck's SBT Toolbox 2.00: Modification Status
________________________________________________________________
Modification WLAN: disabled
Modification Watchdog: enabled
Modification Jive2: disabled
Modification Buffer: disabled
Buffersize: 20000
20000us
Modification Screen: disabled
Audio outputs: Analog: off Digital: on USB: off
Modification Kernel: enabled
# ttbuffer 4000
4000
sed: unmatched '/'
________________________________________________________________
soundcheck's SB Touch Toolbox 2.0: The buffer mod!
________________________________________________________________
Buffer set to 4000 us. Rebooting system.
________________________________________________________________
After reboot the ttbuffer is still as it was before.
# ttstat
________________________________________________________________
soundcheck's SBT Toolbox 2.00: Modification Status
________________________________________________________________
Modification WLAN: disabled
Modification Watchdog: enabled
Modification Jive2: disabled
Modification Buffer: disabled
Buffersize: 20000
20000us
Modification Screen: disabled
Audio outputs: Analog: off Digital: on USB: off
Modification Kernel: enabled
________________________________________________________________
#
You can see on the output of ttbuffer that sed complains about an unmatched /. I think this causes ttbuffer to write not down the settings on alsaplayer.
I can do that manually, but I think it would be more interesting to check why the upgrade causes the script to fail.
All the plug plugin does is to adjust the input stream to the sound card HW parameters. It does nothing to the final sound if parameters of the input stream can be accomodated by the sound card, just as plain hw. If the input stream deviates from the supported parameters (sample rate, format, number of channels), it does the minimum changes required. Replacing it with plain hw:x results only in fewer supported range of input audio data - e.g. radio stations broadcasting in format not supported directly by the sound card do not work with hw:x, while they would be perfectly OK with plughw:X. Good way to test is playing with aplay -v, where the plug plugin reports all the necessary changes it performs.
I thought you unsubscribed long time from that thread. Please stop trying to undermine not only my and btw not new findings (and not only this thread) with your opinions again. You don't even own that device. We had that discussions over here before.
People can turn my modifications on and off and decide by themselves to see if there is a difference in soundquality. The impact will differ from system to system of course.
You'll be invited to contribute "anything" constructive which would get my project further as it already is (though I doubt that this will ever happen) -- otherwise I'd appreciate if you stay out of here.
Last edited:
Yep I know. And my buffer mod and most of the other things I'm doing belongs in the same category.
phofman - you better stop it. You don't do yourself a favour.
See it as a nice advise from my side.
No, you cannot quote me on that as I never said that.
Let's be specific.
http://www.diyaudio.com/forums/pc-based/168871-squeezebox-touch-modifications-2.html#post2338296
I said reducing alsa buffers will lead to underruns.
http://www.diyaudio.com/forums/pc-based/168871-squeezebox-touch-modifications-4.html#post2417746
http://www.diyaudio.com/forums/pc-based/168871-squeezebox-touch-modifications-5.html#post2426009
http://www.diyaudio.com/forums/pc-based/168871-squeezebox-touch-modifications-5.html#post2426054
http://www.diyaudio.com/forums/pc-based/168871-squeezebox-touch-modifications-8.html#post2447823
All these guys experienced underruns, due to uselessly short alsa buffers, resulting in CPU not keeping up with the sound card requirements.
The plug "mod":
http://www.diyaudio.com/forums/pc-based/168871-squeezebox-touch-modifications-9.html#post2467242
Of course, removing the plug plugin makes the device inoperable for some input streams.
Do you really think the engineers behind SB are so stupid?
Well, you may find telling others to deliberately cripple their devices to be more constructive than my warnings. I do not.
The sad thing is most of your followers believe you really know what all your mods actually do.
Last edited:
FTP vs UTP
Hi Folks!
Did someone experience SQ difference between FTP vs UTP on the Touch.
I tried an FTP cable with high quality connector (Draka FTP with Hirosa connectors recommended by Soundcheck) and it sounds subtantially better that an ordinary UTP cable. The sound is rounder, with warmer medium en much less harsch.
Best guess for an explanation: probably the higher quality cable with some metallic parts around the plastic of the outer connector, plays a kind of capacitance role that rolls off high freq interferences from Ethernet datastream?!?
Anyhow, I am hesitating now to damage the outer jacket of my cable to remove the shielding like recommended by Soundcheck, since SQ is already significantly improved and this change is irreversible. Did someone try both FTP with and without removing the shielding? Does it bring any additional improvement?
Thanks for feed-back!
Regards,
Emmanuel
Hi Folks!
Did someone experience SQ difference between FTP vs UTP on the Touch.
I tried an FTP cable with high quality connector (Draka FTP with Hirosa connectors recommended by Soundcheck) and it sounds subtantially better that an ordinary UTP cable. The sound is rounder, with warmer medium en much less harsch.
Best guess for an explanation: probably the higher quality cable with some metallic parts around the plastic of the outer connector, plays a kind of capacitance role that rolls off high freq interferences from Ethernet datastream?!?
Anyhow, I am hesitating now to damage the outer jacket of my cable to remove the shielding like recommended by Soundcheck, since SQ is already significantly improved and this change is irreversible. Did someone try both FTP with and without removing the shielding? Does it bring any additional improvement?
Thanks for feed-back!
Regards,
Emmanuel
In general, at least in the US, networking cables are referred to as shielded twisted pairs or STP, such as the foil twisted pairs FTP. The standard has been UTP or unshielded twisted pairs as there is over a hundred years of installed experience (standard for telephone cable.)
The shielded cable offers an opportunity for groundloops which is not present w/ unshielded.
I don't doubt that you hear a difference but I personally would never use anything but UTP.
0
The shielded cable offers an opportunity for groundloops which is not present w/ unshielded.
I don't doubt that you hear a difference but I personally would never use anything but UTP.
0
Short and concise there soundcheck
OK, my findings reading v2 script is that kernel log, syslog and samba are stopped. Optional we can tweak default for WLAN and screen.
But what I mostly like to know if there are any buffers tweaked default after initializing?
I installed (almost) all of the mods, including 100% volume mod.
I only left the screen unmodified.
Wireless, USB and analog outs are disabled, only the digital out is left on.
Buffer is set to recommended value of 4000.
Flac files are transcoded to PCM on the PC side.
PC is running last version of SBServer on Win XP.
Everything is wired through the Belkin N+ hub with Bandridge VL unshielded CAT 5e wire.
I'm using my Touch with Naim DAC, which has an unique option to play PCM wav files stored on USB memory sticks.
This is not an USB DAC.
There is no USB connection to computer - you just plug an USB memory stick in it and it starts playing.
This way, we have an option of avoiding influence of transport quality, SPDIF interface, cabling, etc, thus having the closest thing to the pure sound of the DAC as the reference sound.
My SPDIF cable is Stereovox XV2, with BNC connection on DAC side.
When I compare the sound of modded Touch / Naim DAC combination with the sound of Naim DAC alone (playing PCM wav directly from the USB memory stick),
Touch/Naim combination sounds somewhat duller.
Naim DAC alone, in memory stick mode, has greater dynamics, transients are sharper, there is more attack, bass has greater slam and kick, mids and highs are more detailed, treble is more extended, there is more air around instruments. Imaging is wider and deeper. Everything is more vivid.
Difference is not (it never is ) night and day, but it is very obvious.
Enough for me to worry about it, since I'm not using the full potential of this excellent DAC.
BUT...!!!
When I did put a SD card with the same music in the Touch, I was very surprised!
The sound became much closer to the real sound of Naim DAC.
Something I could live with.
In this scenario all the mods are still present, but the internal Tiny SBS is running and FLAC decoding is done inside the Touch.
This is supposed to be the bad thing, but the sound is better and it is very close to the "real" sound of the DAC.
So, I guess that these mods might give you a different sound.
Judging from this (still limited) experience, I'm not convinced that they will always bring sound quality improvement in absolute terms.
They only may bring you the sound you will like more, depending on your personal preferences and/or the rest of your equipment.
.
I only left the screen unmodified.
Wireless, USB and analog outs are disabled, only the digital out is left on.
Buffer is set to recommended value of 4000.
Flac files are transcoded to PCM on the PC side.
PC is running last version of SBServer on Win XP.
Everything is wired through the Belkin N+ hub with Bandridge VL unshielded CAT 5e wire.
I'm using my Touch with Naim DAC, which has an unique option to play PCM wav files stored on USB memory sticks.
This is not an USB DAC.
There is no USB connection to computer - you just plug an USB memory stick in it and it starts playing.
This way, we have an option of avoiding influence of transport quality, SPDIF interface, cabling, etc, thus having the closest thing to the pure sound of the DAC as the reference sound.
My SPDIF cable is Stereovox XV2, with BNC connection on DAC side.
When I compare the sound of modded Touch / Naim DAC combination with the sound of Naim DAC alone (playing PCM wav directly from the USB memory stick),
Touch/Naim combination sounds somewhat duller.
Naim DAC alone, in memory stick mode, has greater dynamics, transients are sharper, there is more attack, bass has greater slam and kick, mids and highs are more detailed, treble is more extended, there is more air around instruments. Imaging is wider and deeper. Everything is more vivid.
Difference is not (it never is
) night and day, but it is very obvious.Enough for me to worry about it, since I'm not using the full potential of this excellent DAC.
BUT...!!!
When I did put a SD card with the same music in the Touch, I was very surprised!
The sound became much closer to the real sound of Naim DAC.
Something I could live with.
In this scenario all the mods are still present, but the internal Tiny SBS is running and FLAC decoding is done inside the Touch.
This is supposed to be the bad thing, but the sound is better and it is very close to the "real" sound of the DAC.
So, I guess that these mods might give you a different sound.
Judging from this (still limited) experience, I'm not convinced that they will always bring sound quality improvement in absolute terms.
They only may bring you the sound you will like more, depending on your personal preferences and/or the rest of your equipment.
.
Hi Kuja.
I just read a bit about the Naim DAC.
The Naim DAC (2600€ + 3500€ for ext. PS) is a very special animal.
It runs a Sharc processor and plenty of storage inside . The whole
stream will be stored, the sample rate analysed and then reclocked.
No PLLs are used just 10 different fixed frequencies.
Great design, as far as I can see. I'm not sure if there is another design like that out there. They really intended to get the input jitter out.
My expectations would be that the DAC should not show any difference, doesn't matter what you feed!!
Naim even recommends Toslink, which proved to be inferior to SPDIF-Coax in many other occasions, to avoid ground loops.
The only question then would be why a Touch sounds different in different configurations? And equal on local operation to the DACs internal USB operation.
I can't answer that. Assuming the DAC does a close to perfect reclocking,
the only explanation might be that after applying my Toolbox (at the grade you've done it) is not working bit-perfect anymore.
There is one more: If I understood it correctly the Naim DAC kicks in an ASRC on rather instabil inputs. That one might cause different results. The question is then what would be the instabil input.
It is really hard to tell. What I can tell is that TT2.0 is by far not the end of the story. As you can read over here tweaking the network makes a huge difference. Turning the screen off is considered by many one of the major tweaks. And of course I don't want to talk about the stuff I still got under testing.
I just had the chance too listen quickly to the Meicords ethernet cable
btw. Those cables cause again a better resolution on rather standard DACs.
I also listened quickly to a TT2.0(sw only)-Touch->BigBen->Antelope DAC setup the other day. The Big Ben reclocked the stream.
The Big Ben setup seemed to be better ( I just listened a track or two) on the first glance then the basic TT2.0-Touch->Antelope setup. But please don't nail me on that. That was my first impression.
As I always say. The key issue is to find a DAC which kills the incoming
jitter. All my mods and audiophile SW players will become obsolete if that happens. I'm more than looking forward to it.
And - if I want to go the SD-card route I go for the EC-Designs solution or similar like Bunpeis player.
My goal is to go for an iPad controlled audiophile network solution at best price/performance ratio. So far I'm more then pleased with the result.
I always said, proper reclocking or slaving the PC or transport to the DAC plus galvanic isolation will supposedly be the best solution of all.
I guess Naim did a big step into that direction. They even found a great clocking mechanism to avoid PLLs. It's time for others to follow.
Cheers
I just read a bit about the Naim DAC.
The Naim DAC (2600€ + 3500€ for ext. PS) is a very special animal.
It runs a Sharc processor and plenty of storage inside . The whole
stream will be stored, the sample rate analysed and then reclocked.
No PLLs are used just 10 different fixed frequencies.
Great design, as far as I can see. I'm not sure if there is another design like that out there. They really intended to get the input jitter out.
My expectations would be that the DAC should not show any difference, doesn't matter what you feed!!
Naim even recommends Toslink, which proved to be inferior to SPDIF-Coax in many other occasions, to avoid ground loops.
The only question then would be why a Touch sounds different in different configurations? And equal on local operation to the DACs internal USB operation.
I can't answer that. Assuming the DAC does a close to perfect reclocking,
the only explanation might be that after applying my Toolbox (at the grade you've done it) is not working bit-perfect anymore.
There is one more: If I understood it correctly the Naim DAC kicks in an ASRC on rather instabil inputs. That one might cause different results. The question is then what would be the instabil input.
It is really hard to tell. What I can tell is that TT2.0 is by far not the end of the story. As you can read over here tweaking the network makes a huge difference. Turning the screen off is considered by many one of the major tweaks. And of course I don't want to talk about the stuff I still got under testing.
I just had the chance too listen quickly to the Meicords ethernet cable
btw. Those cables cause again a better resolution on rather standard DACs.
I also listened quickly to a TT2.0(sw only)-Touch->BigBen->Antelope DAC setup the other day. The Big Ben reclocked the stream.
The Big Ben setup seemed to be better ( I just listened a track or two) on the first glance then the basic TT2.0-Touch->Antelope setup. But please don't nail me on that. That was my first impression.
As I always say. The key issue is to find a DAC which kills the incoming
jitter. All my mods and audiophile SW players will become obsolete if that happens. I'm more than looking forward to it.
And - if I want to go the SD-card route I go for the EC-Designs solution or similar like Bunpeis player.
My goal is to go for an iPad controlled audiophile network solution at best price/performance ratio. So far I'm more then pleased with the result.
I always said, proper reclocking or slaving the PC or transport to the DAC plus galvanic isolation will supposedly be the best solution of all.
I guess Naim did a big step into that direction. They even found a great clocking mechanism to avoid PLLs. It's time for others to follow.
Cheers
Last edited:
Squeezebox Touch + Naim DAC
Soundcheck: First, I would like to thank Soundcheck for his great work in modifying the SQT.
Kuja, I thought we could share our experience as we pretty much have the same system; my sys:
NAS: Synology 411+
SQT: modded with Soundcheck Toolbox 2.0
DAC: Naim
Digital Cable: Vitus Digital Interconnect
Most of the mods worked for me, except having the FLAC decoded at the NAS level. I found the sound I get is almost "in my face" when I had the FLAC decoded at the NAS level. However, when I had the SQT decode the FLAC, everything feels much more comfortable, a more laid back presentation. I was wondering if this had to do w/ the network setup at home (I had to go through 3 routers between my NAS and SQT).
Additionally, I found digital cable (coax or optical) makes a huge difference. I am still experimenting digital cables. Any experience you could share?
Lastly, I am thinking to get a linear power supply, anyone has any experience to share? I am thinking between the TeddyPardo and the S-booster.
Cheers!
Soundcheck: First, I would like to thank Soundcheck for his great work in modifying the SQT.
Kuja, I thought we could share our experience as we pretty much have the same system; my sys:
NAS: Synology 411+
SQT: modded with Soundcheck Toolbox 2.0
DAC: Naim
Digital Cable: Vitus Digital Interconnect
Most of the mods worked for me, except having the FLAC decoded at the NAS level. I found the sound I get is almost "in my face" when I had the FLAC decoded at the NAS level. However, when I had the SQT decode the FLAC, everything feels much more comfortable, a more laid back presentation. I was wondering if this had to do w/ the network setup at home (I had to go through 3 routers between my NAS and SQT).
Additionally, I found digital cable (coax or optical) makes a huge difference. I am still experimenting digital cables. Any experience you could share?
Lastly, I am thinking to get a linear power supply, anyone has any experience to share? I am thinking between the TeddyPardo and the S-booster.
Cheers!