Thanks for your post.
I got busy last night w/ dBpoweramp music converter and after some problems found it works very nicely in converting 24/96 flac to 24/96 wave @2 channels. Then after reindexing the music files, music plays back @ full resolution (no truncating to 1411.)
My laptop that is my music server is getting tired. It was very balky this AM after all the fooling around last night. It was also quite chilly last night.
I have another older laptop that I could load Votexbox on but it needs a pcmcia card for USB 2.0 and that's a gamble to make work.
I posted too soon. A few times last nite and then once today, rather than music playback, when selecting a folder that contains 24/96 waves processed from an HDTracks download all that could be heard was noise similar to the interference heard between stations on an old radio. Very annoying and going to the next cut clears it immediately. Can't figure this out yet.
The issue w/ the noise rather than music playback has cleared up. There remains only a buffer issue on the first cut of 24/96 Wave material. After starting, the playback drops for a few moments then continues. Higher resolution music involves more packets in the buffer and there is probably a way to increase the size of the buffer to correct this.
Thanks, this leaves me with 2 possible ways to deal with this.
To answer the earlier question: When you open up squeezebox server has the screen split in two. If you select a song with out playing it on the left screen it will show song info. If you do this for the same song that you are currently playing it will show you how it was delivered (PCM rate etc).
To answer the earlier question: When you open up squeezebox server has the screen split in two. If you select a song with out playing it on the left screen it will show song info. If you do this for the same song that you are currently playing it will show you how it was delivered (PCM rate etc).
Ah.. I see it. It looks like a bug on SBserver
1. I have checked the hardware settings on the SBT when playing 24/96 pcm. It is exactly as expected:
# more hw_params
access: MMAP_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 960
buffer_size: 1920
2. I've run (again!) the flac decoding command used by SBserver to send the pcm over to the SBT, and it definitely decodes to 24/92 pcm. In fact in setting up my conversion to include room correction, I've found that the SBT will assume the sample rate and word format of the pcm to be that of the flac file, so you _must_ send 24/96 pcm if the flac reports to be 24/96. Otherwise you get the noise which was described elsewhere.
Converting hires flacs to wav is going to waste disk space, and cause audio tags to be lost. Can you please report the bug to Logitech?
Hi Larry,
The alsa hw parameters are direct from the SBT, via ssh. This is a close I can peek into the hardware settings in alsa as I know.
On an ssh session into the SBT:
# more /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 960
buffer_size: 1920
#
I was puzzled by the server secreen indicating that the flac was converted to 1141kHz pcm too. However the flac program that does the conversion on the server, as I mentioned earlier is:
[flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$
It means decode to stdout quietly (-dcs) the send it to the SBT. Flac is not able to resample anyway, so 96kHz flac will decode as 96kHz pcm. The message about 1141kHz pcm is from some programmer on the SBserver end, who probably did not consider that higher rate flac might be sent to th SBT. I'm familiar with these details because I needed to modify a brutefir wrapper program to send pcm to the SBT, instead of re-encoding it back to flac, then sending it to the SBT to be decoded (one extra set of encode/decode on server and SBT!)
The alsa hw parameters are direct from the SBT, via ssh. This is a close I can peek into the hardware settings in alsa as I know.
On an ssh session into the SBT:
# more /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 960
buffer_size: 1920
#
I was puzzled by the server secreen indicating that the flac was converted to 1141kHz pcm too. However the flac program that does the conversion on the server, as I mentioned earlier is:
[flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$
It means decode to stdout quietly (-dcs) the send it to the SBT. Flac is not able to resample anyway, so 96kHz flac will decode as 96kHz pcm. The message about 1141kHz pcm is from some programmer on the SBserver end, who probably did not consider that higher rate flac might be sent to th SBT. I'm familiar with these details because I needed to modify a brutefir wrapper program to send pcm to the SBT, instead of re-encoding it back to flac, then sending it to the SBT to be decoded (one extra set of encode/decode on server and SBT!)
Last edited:
I think I will have to try mb's brutefirdrc trick. It says that pcm is being downgraded on squeeze server, and it sure sounds like it. 44.1 sounds great, but 96/24 sounds almost like an mp3. The hardware may be able to handle it, but squeeze server may be calling on another object, class or whatever (stuff I remember from engineering school) that only does 1411kbps.
Omc: I might not have been clear. I do NOT believe that in your case 24/96 flac is being downsampled. In fact, I am quite sure it is not. What you are hearing is most likely the difference between 24/96 and 44.1.
I have traced the way the server is converting flac to pcm (without brutefir in between), and there is no downsampling. The message you see about 1141 kHz pcm is probably an *bug*, and the data is sent to the SBT as 24/96.
If you're thinking of adding brutefir to your playback chain, let me caution you that for the SBT it is a pretty manual task, as brutefirdrc has not been ported to the SBT. Measuring and getting the right settings for room correction is non-trivial, then making it send pcm to the SBT was another struggle.
I have traced the way the server is converting flac to pcm (without brutefir in between), and there is no downsampling. The message you see about 1141 kHz pcm is probably an *bug*, and the data is sent to the SBT as 24/96.
If you're thinking of adding brutefir to your playback chain, let me caution you that for the SBT it is a pretty manual task, as brutefirdrc has not been ported to the SBT. Measuring and getting the right settings for room correction is non-trivial, then making it send pcm to the SBT was another struggle.
I believe all that brutefir can do can be done by IngusDSP without any trouble. I made it work without any real problems.
But measuring and obtaining a set of good filters is not trivial for sure. That's what I've never accomplished :-(
Every time I get so-so results I decide it's just not worth it - I'm loosing some low level information and dynamics.
From what I've read, yes, IngusDSP will do just about the same. I used brutefir because my server is (was) an old P4 Dell, and runs linux (ubuntu).
I've upgraded the server, and expect brutefir will be able to provide full drc to three rooms
. Tony Dickenson provided some great notes on the basic measurement steps. and for me the correction has most definitely increased detail and dynamics. There is at least 6dB loss of signal, which is unavoidable. In terms of perception the loss is probably 10dB, as room modes are cut back dramatically, so the volume needs to be set a lot higher.
I have tried the filter setting generated by Ingus' "normal" correction file, and find that it takes away some of the life from the music, and use a "minimal" setting for brutefirdrc. I find this more to my taste.
There is an update to soundcheck's blog.
soundcheck's - audio@vise: Squeezebox Touch -- Modifications
Soundcheck is thinking about turning his mod into commercial product.
Please write what you think about this idea.
I find it unfair for two reasons:
1). It just kills future community works. Who will share his findings on Touch's configuration if he'll know Soundcheck will grab them into his commercial package.
Soundcheck writes on his blog:
"What keeps me back posting those modifications to the community is the fear that these might be misused or copied by others for different commercial purposes."
Is it fair Soundcheck? You will be exactly the same threat to the community. Can you swear you'll never use in your product what you'll find here or somewhere else online?
2). With all regards - Soundcheck already didn't find out all the mods by himself. Look at the proof:
http://forums.slimdevices.com/showthread.php?t=72787&highlight=soundcheck
By the way - I don't believe there is a market for such products.
How many people will pay for that? 10? May be.
soundcheck's - audio@vise: Squeezebox Touch -- Modifications
Soundcheck is thinking about turning his mod into commercial product.
Please write what you think about this idea.
I find it unfair for two reasons:
1). It just kills future community works. Who will share his findings on Touch's configuration if he'll know Soundcheck will grab them into his commercial package.
Soundcheck writes on his blog:
"What keeps me back posting those modifications to the community is the fear that these might be misused or copied by others for different commercial purposes."
Is it fair Soundcheck? You will be exactly the same threat to the community. Can you swear you'll never use in your product what you'll find here or somewhere else online?
2). With all regards - Soundcheck already didn't find out all the mods by himself. Look at the proof:
http://forums.slimdevices.com/showthread.php?t=72787&highlight=soundcheck
By the way - I don't believe there is a market for such products.
How many people will pay for that? 10? May be.
Hi there.
Just to make one thing clear.
I do not intend to go commercial with my modifications. I guess I pointed out why.
The current list of modifications is a collection of system relevant
parameter changes.
You can look up the basic idea in the "Linux Audio The Way To Go Thread" over here.
I am driving that idea for almost 4 years by now. 99% of those ideas are taken from that
journey. I can assure you that I put quite some time and energy into all that. Definitely more then those guys charging 200$ for a PS.
The link posted above has nothing to with the mods.
I currently install/provide the mods for systems run by
trustworthy persons offline and free of charge.
As I stated - I am not yet sure how to continue with this story.
Cheers
Just to make one thing clear.
I do not intend to go commercial with my modifications. I guess I pointed out why.
The current list of modifications is a collection of system relevant
parameter changes.
You can look up the basic idea in the "Linux Audio The Way To Go Thread" over here.
I am driving that idea for almost 4 years by now. 99% of those ideas are taken from that
journey. I can assure you that I put quite some time and energy into all that. Definitely more then those guys charging 200$ for a PS.
The link posted above has nothing to with the mods.
I currently install/provide the mods for systems run by
trustworthy persons offline and free of charge.
As I stated - I am not yet sure how to continue with this story.
Cheers
Last edited:
Nice to have you back soundcheck.
I don't know how much you would have to worry about others using your work for commercial purpose. I think that people that are doing stuff like this are probably savvy enough to a quick net search to find out the truth.
I have your mods installed, except the screen and buffer which I couldn't get a hold of, with a linear power supply. I was pleasantly surprised with the performance on my system. Good work. I eagerly await your other work.
By the way, if you are ever coming out to western Canada I would be happy to give you a big scare on the mountain bike.
I don't know how much you would have to worry about others using your work for commercial purpose. I think that people that are doing stuff like this are probably savvy enough to a quick net search to find out the truth.
I have your mods installed, except the screen and buffer which I couldn't get a hold of, with a linear power supply. I was pleasantly surprised with the performance on my system. Good work. I eagerly await your other work.
By the way, if you are ever coming out to western Canada I would be happy to give you a big scare on the mountain bike.
Ok. Sorry for misunderstanding.
I still think your decision to keep your mods in secret is wrong but it's your choice.
I do not deny that you've put a lot effort into that mod - all credits to you - but I believe we could all profit from joint development/testing program. There are several of us who are interested in this thread - some know more about linux, some more about pearl programming and some can only help doing testing. That's the free world spirit which would push the results further and faster.
Regards
ps. To all reading this thread - I've tested Soundcheck's mods and they really work. I've done BLIND a/b tests and I can distinguish modded vs unmodded system 10/10. Is it enough for non-believers? If you cannot hear the difference either you're deaf or your system is simply not resolving enough.
I've done blind tests to standard/linear power supply and to local/server flac decoding. I'm using SPDIF out all the time. After that i started trusting my ears more and i haven't done proper tests to wifi on/off and other minor upgrades but their cummulative influence is also positive.
Noone has ever disputed that replacing the noisy SMPS with a linear one will yield sonic improvements.
Even that is explainable - lowering CPU activity = lower noise on supply lines with direct impact on SPDIF output jitter.