Backyard deck system

[Julf]

I can´t log in via putty to the LMS. I tried it with the IP address and port 9000 but that doesn´t work. Putty shuts down.

It won't be listening for ssh on port 9000 - the correct port is 22 (but the ssh client should use that by default).

Isn´t that how it should work? Once i would be connected login as "root" and PW "1234", or?

Can you remind me - what system are you running LMS on?

[marflao]

Thanks Julf.

Now another hurdle ;-)

I can´t log in via putty to the LMS. I tried it with the IP address and port 9000 but that doesn´t work. Putty shuts down.

Isn´t that how it should work? Once i would be connected login as "root" and PW "1234", or?

Sorry for the noob questions ;-)

[Julf]

Is that enough or do I need to insert some other rows in that conv file (besides my SqueezePlayer´s MAC address)?

That should be enough.

[marflao]

Yes, you can prepare and edit it on another system, but in the end you have to get into the right place, so a brief ssh session is needed.



If the config is based on mac addresses, it only affects those specific players, so you can leave the Touch unaffected.

OK..that sounds great, Julf.
Now my questions regarding the code for the conv file Apesbrain has mentioned:

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.

Is that enough or do I need to insert some other rows in that conv file (besides my SqueezePlayer´s MAC address)?

Thanks in advance.

[Julf]

(i) i'm not so familiar in Linux (and i guess i need to ssh in that file, or?).

Yes, you can prepare and edit it on another system, but in the end you have to get into the right place, so a brief ssh session is needed.

But i will check this if
(ii) downsampling won't take place once i choose the Touch.
But from pippin's post above i understood that it will be downsampled as well with the Touch as player. Or was his post not a respond to my question? Maybe i misunderstood something ?!

If the config is based on mac addresses, it only affects those specific players, so you can leave the Touch unaffected.

[marflao]

Backyard deck system

Haven't tried that yet, Julf.
Reasons:
(i) i'm not so familiar in Linux (and i guess i need to ssh in that file, or?). But i will check this if
(ii) downsampling won't take place once i choose the Touch.
But from pippin's post above i understood that it will be downsampled as well with the Touch as player. Or was his post not a respond to my question? Maybe i misunderstood something ?!

[Julf]

Hmm.... doesn't seem that easy.

Now I'm thinking of creating a playlist with songs up to 24/44,1 which I will use with SqueezePlayer.

So you didn't get the custom-convert.conf to work?

[marflao]

Hmm.... doesn't seem that easy.

Now I'm thinking of creating a playlist with songs up to 24/44,1 which I will use with SqueezePlayer.

[Mnyb]

The last point is right. I suspect SqueezePlayer reports what it can handle but it doesn't do any own processing and whether it successfully plays depends on the capabilities of the Android device which vary much more than under iOS....

Aha got that ,there are so many of android devices of varying quality and provenance . Maybe there is no reasonable way to query the hardware about it either , for squeezeplayer .

And to have a manual setting in the app , you get a support issue as it's going to be misunderstood .....

[philippe_44]

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

(sigh) understood - that's why I'm not an audiophile, I guess

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

The LMS protocol lets you (at registration) specify a capability list that includes the maximum supported sample rate. Based on that, LMS does downsampling, I think. What is still missing is the possibility to declare the supported sample depth. Hence in my UPnPBridge plugin I still have to mess with sample size in case the player does not support 24 bits

[pippin]

The last point is right. I suspect SqueezePlayer reports what it can handle but it doesn't do any own processing and whether it successfully plays depends on the capabilities of the Android device which vary much more than under iOS....

[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

[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

[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?

[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.