Bug 10543 - 24bit 96kHz files are transcoded for SqueezePlay on Desktop Machines
: 24bit 96kHz files are transcoded for SqueezePlay on Desktop Machines
Status: NEW
Product: SB Desktop
Classification: Unclassified
Component: Audio
: unspecified
: PC All
: P3 normal (vote)
: 8.0.1
Assigned To: Squeezebox QA Team email alias
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-05 08:25 UTC by Mikael Nyberg
Modified: 2009-10-22 11:17 UTC (History)
5 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Nyberg 2009-01-05 08:25:54 UTC
24bit 96kHz files are transcoded for SquezePlay on Desktop Machines:

My 24/96 is transcoded in SC to 24/48 before they are sent to my desktop which hosts SqueezePlay.

This is unnecessary as my server is not so powerfull, but the desktop machine is powerfull and is wired directly to the router. the server is also wired to the router.

Almost every PC can handle 96kHZ either directly on the soundcard or with a little help by the OS.

This behaviour might be wanted in some usercases, but it could be configured as option in the player settings for this player, maybe right at the same place as the bitrate limiting setting.

My server is an ClarkConnect 4.2 built around an VIA EPIA mini ITX:
Model  	VIA Esther processor
CPU Speed 	1.2 GHz
Cache Size 	128.00 KB
RAM             947.55 MB

The SOX process for transcoding eats 70% CPU for 24/96 to 24/48 transcoding.

I can transcode 1 stream on my machine but not more, lesser machines will start to stutter.

However tried  a rather ugly workaround:

On line 32 of LocalPlayer.lua

Change

["squeezeplay"] = 12,

to

["squeezeplay"] = 5,

Which is the Transporter player type.

Now i have 96000 stream to my PC :) thus my server which is not so powerful don't need to transcode this files for my desktop.
This works but, I'm unsure about my little ugly hack so I apply it when I want to and change it back to the original state afterwards.
Comment 1 James Richardson 2009-01-09 09:38:00 UTC
Alan: Dean would like you to have a look at this
Comment 2 Markus Schiegl 2009-01-15 07:50:33 UTC
links to
...the same bug/description: bug 9989
...a server side solution/fix: bug 9874 (comment #6)
Comment 3 Alan Young 2009-01-15 10:18:10 UTC
Change 24669 adds appropriate capabilities to SC. Now we need a preference for SP Desktop that allows one to select a max sample-rate (48000/96000/192000 would probably be adequate) and a default of 96000. Who should work on that?
Comment 4 Alan Young 2009-03-08 04:28:51 UTC
Ben, I guess that this should be yours. Please feel free to send it elsewhere if need be.
Comment 5 Charles Razzell 2009-07-23 14:22:17 UTC
Latest SP Beta plays 24/96Hz FLAC files in the wrong key, on my WinXP hardware. It seems to play at 41.1/48 of the correct speed/musical pitch. 

I have the latest SC 7.3.4 nightly and the latest SP Beta. I have been testing various high-rez audio downloads, e.g., from http://www.2l.no/hires/index.html. The particular test file I have in mind is: http://www.lindberg.no/hires/test/2L38_01_96kHz.flac 

Playback of this file through my normal hardware Squeezeboxen is no problem, but that utilizes the SOX -> FLAC transcoding mechanism to resample. 

Do you want a separate bug report for this?
Comment 6 Chris Owens 2009-07-31 10:33:47 UTC
Someone's already filed the wrong-play-speed bug as bug 12350
Comment 7 Ben Klaas 2009-08-26 07:52:57 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 8 James Richardson 2009-09-23 10:23:31 UTC
Could everyone experiencing this bug, please download and install the latest SBS 7.4 and SqueezePlay 7.4.  then re-test to see if these versions solve this issue.

Please report back your experience in the bug.
Comment 9 Mikael Nyberg 2009-09-23 11:28:25 UTC
You fixed this already in "old" squeezeplay but unfortunaletely all audio playback on ubuntu 8.10 and 9.04 and Under Wine in 8.10 is broken .
So I can no longer test this.