Backyard deck system

[philippe_44]

So far I connected my Nexus 7 via Bluetooth to a Nude Audio "Super M" while playing songs from Google Music.
But it doesn't work without hiccups... Lot's of buffering.

So this LMS => SqueezePlayer combo might be a better option.

I'm just not 100% sure if my NAS has enough power for the downsampling?!

Just as a curiosity, wouldn't LMS downsampling from 96 to 48 be a simple puncturing of every other sample, so very limited CPU requirement ? (no spectrum aliasing expected)

[pippin]

Backyard deck system

LMS uses sox which does rather complex interpolation and actually eats quite a bit of CPU in the process. Even more than MP3 encoding and dramatically more than FLAC encoding.
Keeps surprising me, too

[Mnyb]

LMS uses sox which does rather complex interpolation and actually eats quite a bit of CPU in the process. Even more than MP3 encoding and dramatically more than FLAC encoding.
Keeps surprising me, too

Just as a curiosity, wouldn't LMS downsampling from 96 to 48 be a simple puncturing of every other sample, so very limited CPU requirement ? (no spectrum aliasing expected)

Yes pippin is right LMS does state of the art downsampling when a player needs it it's inaudible to the listener a very good choice.

But if your server can't take it that's a problem .

Very very old server versions >10 years ago ,that where around at the time of slimp3 and SB1 might just dumped 1/2 of the samples , but at those time squeezeboxes where fun gadgets before anyone at slimdevices realised that it had hifi potential ,that came with the SB2.

[philippe_44]

Yes pippin is right LMS does state of the art downsampling when a player needs it it's inaudible to the listener a very good choice.

But if your server can't take it that's a problem .

Very very old server versions >10 years ago ,that where around at the time of slimp3 and SB1 might just dumped 1/2 of the samples , but at those time squeezeboxes where fun gadgets before anyone at slimdevices realised that it had hifi potential ,that came with the SB2.

Agreed but in the special case of 192/96/48 there is no need for filtering, so I was wondering if that optimization was there and could help by setting downsampling to 48 instead of 44.1

[Mnyb]

Agreed but in the special case of 192/96/48 there is no need for filtering, so I was wondering if that optimization was there and could help by setting downsampling to 48 instead of 44.1

There is always need for filtering for various reasons, but I'm afraid I can't explain it very good .
Simplest case there is signal content even if it's noise above the nyqvist limit for 44.1 or 48 k (22,05khz , 24khz) or in practice a little bit lover ,this will aliase back into the signal if you just drop samples . Therefore they are filtered before downsampling . There must be no signal content at all above the nyqvist limit of the target sample rate .

[Mnyb]

There is a low end alternative to lame , shine . Results is worse , but it actually works on Sheeva plug and other machines without floating piont .

I have not yet seen a cruder alternative to SoX for low end servers ?

Depending on CPU architecture and FPU I've had a server where lame used much more CPU than SoX.

But enough off topic from me , let's see some backyard systems

[philippe_44]

There is always need for filtering for various reasons, but I'm afraid I can't explain it very good .
Simplest case there is signal content even if it's noise above the nyqvist limit for 44.1 or 48 k (22,05khz , 24khz) or in practice a little bit lover ,this will aliase back into the signal if you just drop samples . Therefore they are filtered before downsampling . There must be no signal content at all above the nyqvist limit of the target sample rate .

You're right but here is what I meant more precisely.

Sampling a signal s at a rate of T has the effect of duplicating its spectrum an infinite amount of time with an n/T spacing. Obviously if the spectrum is larger than 1/T (max complex frequency 1/2T), then overlapp (aliasing) occurs and original info is lost.
So, assuming that spectrum is below that 1/T limit, sampling at T/2 has the effect of duplicating spectrum every 2n/T and sampling at 4T spaces it at 4n/T. So, mathematically speaking, a signal with a spectrum below 1/T and sampled at T/2 or T/4 can be simply punctured at 1/2 or 1/4 without any loss of information, assuming that you do a perfect cardinal sine filtering when you switch back to analogue domain.

What I meant by "no filtering needed" is that if you want do downsample at non integer multiple of initial rate, then you have to re-interpolate (filtering ...) in the digital domain at the new rate . When it is an integer multiple, there is no need of that. And if you downsample in respect with spectrum size, there is no need to lowpass filter

In "real life", the analogue conversion filtering is not a perfect cardinal sine and the benefit of oversampling is that by increasing space between spectrum "replica", you ease the analogue filtering requirements. But, without entering into an audiophile debate, assuming a decent DAC, I was suggesting that in case the host CPU is a problem, moving from 96K to 48K without filtering should be done by 1/2 puncturing which requires no CPU, re-interpolating and lowpass is not needed

(PS: I'm not trying to be pedantic, sorry if it looks like that )

[Mnyb]

You're right but here is what I meant more precisely.

Sampling a signal s at a rate of T has the effect of duplicating its spectrum an infinite amount of time with an n/T spacing. Obviously if the spectrum is larger than 1/T (max complex frequency 1/2T), then overlapp (aliasing) occurs and original info is lost.
So, assuming that spectrum is below that 1/T limit, sampling at T/2 has the effect of duplicating spectrum every 2n/T and sampling at 4T spaces it at 4n/T. So, mathematically speaking, a signal with a spectrum below 1/T and sampled at T/2 or T/4 can be simply punctured at 1/2 or 1/4 without any loss of information, assuming that you do a perfect cardinal sine filtering when you switch back to analogue domain.

What I meant by "no filtering needed" is that if you want do downsample at non integer multiple of initial rate, then you have to re-interpolate (filtering ...) in the digital domain at the new rate . When it is an integer multiple, there is no need of that. And if you downsample in respect with spectrum size, there is no need to lowpass filter

In "real life", the analogue conversion filtering is not a perfect cardinal sine and the benefit of oversampling is that by increasing space between spectrum "replica", you ease the analogue filtering requirements. But, without entering into an audiophile debate, assuming a decent DAC, I was suggesting that in case the host CPU is a problem, moving from 96K to 48K without filtering should be done by 1/2 puncturing which requires no CPU, re-interpolating and lowpass is not needed

(PS: I'm not trying to be pedantic, sorry if it looks like that )

He he so you mean by the typical 24/96 download which is fake it's really a 16/44 master but HD tracks don't tell you that there is not much that could aliase down ? Or for other reasons there are nothing much above the limit .
There might be real world issues anyway ,but that's beyond my detailed understanding . I think the current use of SoX is best practice .

But the LMS architecture may need a compromise solution for low CPU servers that just do as you suggest with multiples of the sample rate giving end results that's playable but may be compromised . Or is there a less CPU demanding resampler out there .
Or is it so simple as give SoX the right commands and it runs a less demanding procedure .

But how many low CPU servers is there today ? Would not mores law fix this faster than the comunity finds a solution ?

[pippin]

No, what he's saying is that if you just drop every second sample that would be the same process as sampling at a lower sampling rate all along.
If there is really any improvement in a particular recording from going from a 48 kHz sample rate to a 96 kHz sample rate that improvement will be lost in the process but you still get something slightly superior to CD quality which should be fine for applications where you don't have a 96kHz DAC anyway. You might be able to get a very slight improvement over that by interpolation so you would "save" some of the benefits of the higher sample rate recording but if you don't have the CPU required, the result is actually a broken playback which is the worst SQ you'll ever have. Working always beats "theoretically better but not working".

Those upsampled tracks have gone through so many potentially distortion- and aliasing-adding conversions it probably doesn't matter what you are doing to them anyway, they will be worse than the original 44.1/16 recording anyway.

[Mnyb]

No, what he's saying is that if you just drop every second sample that would be the same process as sampling at a lower sampling rate all along.
If there is really any improvement in a particular recording from going from a 48 kHz sample rate to a 96 kHz sample rate that improvement will be lost in the process but you still get something slightly superior to CD quality which should be fine for applications where you don't have a 96kHz DAC anyway. You might be able to get a very slight improvement over that by interpolation so you would "save" some of the benefits of the higher sample rate recording but if you don't have the CPU required, the result is actually a broken playback which is the worst SQ you'll ever have. Working always beats "theoretically better but not working".

Those upsampled tracks have gone through so many potentially distortion- and aliasing-adding conversions it probably doesn't matter what you are doing to them anyway, they will be worse than the original 44.1/16 recording anyway.

Very likely , but I do have some real content that ain't to broken that do contain above 24khz signal there are actual hires recordings just far fewer than audiophiles care to admit ( even fewer that contains music anyone cares for ) . But obviously I won't care in the garden or on mobile

One obvious choice we all have is to just down convert everything offline , I convinced that I can't hear the difference even on state of the art recordings down converted to 16/44.1 if you do 24/44.1 and 24/48 of everything you are probably good to go and enjoy life and music

[marflao]

Well... I just installed SqueezePlayer on my tablet and it's playing well up to 24/44,1.
Above it stops playing.

Is there something I need to setup in LMS that songs with bitrates up to 24/192 can be played or will this not be possible?

It's not that I will hear a difference between 16/44,1 and higher rates. But it would be more convenient if they would be played. Honestly I don't like the idea to downsampling them (lazy me).

[Apesbrain]

Is there something I need to setup in LMS that songs with bitrates up to 24/192 can be played...

You might be able to do it with a "custom-convert.conf" file that tells LMS to use SoX to resample all FLAC going to that device to 16/44. The contents of this text file would look something like this:

flc flc * 00:00:00:00:00:00
	# FT:{START=--skip=%t}U:{END=--until=%v}
	[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -C 0 -b 16 -r 44.1k -

Where 00:00:00:00:00:00 is the MAC address of your tablet.

This file goes on your server in same folder as "convert.conf". Restart.

[marflao]

Thanks for that hint, apesbrain.

Just one question: in case I would choose my Touch as the player this custom conversion would not be applicable (because the Mac address of the tablet is used), right?
Or am I wrong and the songs will also be downsampled once I'll choose the Touch?

[philippe_44]

He he so you mean by the typical 24/96 download which is fake it's really a 16/44 master but HD tracks don't tell you that there is not much that could aliase down ? Or for other reasons there are nothing much above the limit .
There might be real world issues anyway ,but that's beyond my detailed understanding . I think the current use of SoX is best practice .

But the LMS architecture may need a compromise solution for low CPU servers that just do as you suggest with multiples of the sample rate giving end results that's playable but may be compromised . Or is there a less CPU demanding resampler out there .
Or is it so simple as give SoX the right commands and it runs a less demanding procedure .

But how many low CPU servers is there today ? Would not mores law fix this faster than the comunity finds a solution ?

You're right on CPU, it should not be the issue unless you want to have many players in parallel.

I also meant that tracks made to be played should have nothing in spectrum above 20KHz, it is useless. The benefit of A/D oversampling is to push away spectrum images so that you can use easier analogue filters and then in the digital domain, you should eliminate anything above between 20KHz (up to Fs/2 or course) by digital filtering where you can use all the complicated, non real-time, post-processing in the world. After that, your file can be downsampled for size improvment with no information loss. Then when you do the D/A process, the benefit of up-sampling is that again, with the images being rejected further, the analogue filters can be less complicated. But up-sampling and interpolation could be done realtime, do not need to store the over-sampled file.

But you're right, I'm hijacking the original thread on top of risking to start another flame war

[Mnyb]

You're right on CPU, it should not be the issue unless you want to have many players in parallel.

I also meant that tracks made to be played should have nothing in spectrum above 20KHz, it is useless. The benefit of A/D oversampling is to push away spectrum images so that you can use easier analogue filters and then in the digital domain, you should eliminate anything above between 20KHz (up to Fs/2 or course) by digital filtering where you can use all the complicated, non real-time, post-processing in the world. After that, your file can be downsampled for size improvment with no information loss. Then when you do the D/A process, the benefit of up-sampling is that again, with the images being rejected further, the analogue filters can be less complicated. But up-sampling and interpolation could be done realtime, do not need to store the over-sampled file.

But you're right, I'm hijacking the original thread on top of risking to start another flame war

I get you but believers in hirez do want content above 20kHz even in the delivery format to customers . But I agree that most likely this creates problem in the playback chain tweeter resonances and IM and provoke IM in amplifiers etc and actually transformer resonances in tube amps etc .
So hirez dowloads to consumers do contain over 20kHz . Worst case they contain unfiltered DSD noise as the original might have been DSD ,that you *really* want to filter out .

I do understand that recording in very high resolution is necessary for a myriad of reasons , this is not the same topic as playback I constanly say this as this is always confused . (now thats done )

But i agree that not hearing them is the worst option , you really want the music .

On topic should not even the software players report back properly to LMS about their capability so LMS can downsample automatically . If you have to write you own convert conf's something seem broken to me ?? So bug report to the author of such player seems the next step