Hm. I can't attach the file since it's too big. How do I do this?

Can you just put it on a web site temporarily somewhere?  Or upload it to http://www.yousendit.com/

Andy notes that it may have particular compression that is causing it to stutter, because he has played 24/96 files

http://penguinlovesmusic.de/wp-content/uploads/2010/01/track10_24_96000.flac

got it; you can take it down if you like.  Thanks!

Steven, could you investigate this file?

I do experience the issue described with the file mentioned in comment 3.  From what I can tell this file was encoded with the --best or -8 option.  I re-encoded the file using the --fast or -0 option that results in a file that does not seem to have the issue.  FLAC encoded with --best or -8 option does create the most processor intense FLAC files for both encoding and decoding while --fast or -0 creates the least.  This behavior is almost identical to Bug 4562 even though it was for the Transporter.

From metaflac:

METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4608 samples
  maximum blocksize: 4608 samples
  minimum framesize: 18 bytes
  maximum framesize: 21480 bytes
  sample_rate: 96000 Hz
  channels: 2
  bits-per-sample: 24
  total samples: 45703169
  MD5 signature: 220b77dfbeea345afa7790198ab9a55d
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 194
  vendor string: reference libFLAC 1.2.1 20070917
  comments: 6
    comment[0]: Album=WestPort Jazz Festival Hamburg 1999
    comment[1]: Artist=Pat Metheney
    comment[2]: Genre=Jazz
    comment[3]: Title=All The Things You Are (96 kHz)
    comment[4]: Tracknumber=10
    comment[5]: Date=1999
METADATA block #2
  type: 1 (PADDING)
  is last: true
  length: 3942

The file in question plays fine for me so long as I do not use either of the visualizers (VU-meter or graphic frequency analyser). With a visualizer running then the CPU cannot keep up, in either touch or remote skin. Even without the visualizer and in the remote skin, the effect of the scrolling text is pretty-much to saturate the CPU, but the real-time priority of the audio-output stage is just able to keep up in this case. This is with r8539.

Some ARM-targeted and ARM-specific optimisations can be found here: http://git.bogomips.org/cgit/flac-arm-1.1.3.git/

The workaround is: Use a lower compression ratio on your FLAC files OR turn off the visualizer.

Shall we use this bug for similar problems with 24/96 flac ?

I get circa >93% CPU usage on my Touch while playing such files (top said that).

No visualizers or local server running, no USB drive just my own server.

I do use wifi, does that consume much CPU cycles ?

Playing is just fine if I cue up one album and listen, ? it does stutter on first track or if I skip ?

What was the design goals for Touch ?

It has 24/96 dac and one goal was to make it support 24/96 files, right ?

Is it suposed to also run a local server and stream to two other Touch and use the wifi and visualizers at the same time ? (well visualizers I can do without)

I changed the bug title to reflect the expansion of the bug, Mikael

Can this be fixed realistically ?

Did you really meant for it to work with 24/96 2ch flac ?
(unconditionally at any encoding level)

I mean if the cpu is to small it is to small ?

Another known workaround seem to be to use Ethernet, it uses less cpu  ?
I'm having excellent 100% wifi reception, but I'm going to run cable anyway eventually.
So the wifi chip seems superior to SB3 and is fit for purpose, but it seems to use a bit of cpu.

Can you really find 50% more performance by optimizing the code ?

You need that if server is going in the background etc.

The Touch is very good and sounds fantastic, love the interface.
Congrats to the fantastic work you've done.

But if 24/96 flac is part of the spec it is not really fit for purpose as delivered.

Otherwise looking forward for hardware revision 2 under warranty.
Suggestion 2*cpu 2*memory possible a cpu with fpu.

I wired my Touch

Now it works what a difference, I could not imagine, it just works

skip is lightning fast and files cue up nicely.

My wifi network is good, and fast enough.
But it's soo much faster with Ethernet.

So if wired it already works as advertised.
I can run VU-meters to.

My 24/96 flac's are -5

Hopefully you can tune it cope with WPA2 decryption overhead and stuff, so it can have a chance to work with wifi too.
and also the rebuffering lag too needs tuning.

Running top gives me a very healthy margin CPU use is 60%

sorry for causing confusion and FUD.

I've found a connection between the way you control Touch and the stutter.

Try this, start a 24/96 album with the controller, then I get a drop out in the first song, but skipping inside that album works ok.

Controlling via Touch itself or web-UI works flawless if Touch is wired.

 == Auto-comment from SVN commit #8763 to the jive repo by ayoung ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8763 ==

bug 15361: Can't play 24/48 or 24/96 flac without stutter and rebuffering 
Implement outputThreshold

We can certainly fix this in the 7.6 timeframe.

I have the same experience. With wireless I get a lot of buffering and interruption of music. With Ethernet it plays great. No interruption and no buffering.
Using Ethernet and monitoring the CPU usage while the track10_24_96000.flac is playing and the visualizer running shows the cpu usage close to 100%, but still no interruption or buffering. I will re-run the test at home with my wireless to see the result.
If I play the music from my USB drive I get results very similar to Ethernet.
I will look into the cpu usage while playing this file and will improve the cpu utilization to fix this bug. We may be forced to look into the performance of our wireless drivers as well.

*** Bug 16227 has been marked as a duplicate of this bug. ***

Here is my experience

- Firmware: 7.5.1 r8786
- Server: SC running on SuSE Linux (not TinySC)
- Track: track10_24_96000.flac
- TinySC: not running

Ethernet:
- No visualizer - ok - no skips - top shows about 60% CPU load
- w/ visualizer - ok - no skips - top shows about 90% CPU load

Wireless (WPA2):
- no visualizer - ok - no skips - top shows about 70% CPU load
- w/ visualizer - not ok - skips - top shows about 80% CPU load

Hi guys, please try the following firmware build which contains the FLAC assembly code from comment 8.

http://update.slimdevices.com/update/firmware/7.6.0/fab4_7.6.0_r8796.bin

To monitor the cpu load it is better to use vmstat instead of top. I have already sent out a vmstat built for fab4.

Just to reiterate what I mentioned to Andy earlier, the build he points to plays perfectly either wired or wirelessly, for me.  

I even turned the VU meters and spectrograph back on and it still works perfectly, although the UI gets a bit sluggish.  I would say there seems to be about 250-500msec delays when I press buttons before it has an effect.

This seems overall much better to me, and I would suggest that no additional optimization is necessary for now, unless you feel really energetic about it for some reason.  I'm sure we will get some additional reports of files that still don't play properly, and we can look into further improvements at that time.

Now I don't want to crash the party, but have you tried with an USB drive connected to the Touch ? using the on-board TinySC ?

Personally I could care less realizing the reality of things and running a dedicated server for all my flacs 23500 and actually > 1000  of 24/96 flac files.
I'm quite satisfied by your work resolving this issue well done :-)
My Touch is also wired nowadays.

*** Bug 16228 has been marked as a duplicate of this bug. ***

I have tested the playing of FLACs from a USB device connected to Fab4 and the result is very close to playing FLACs from Ethernet.
Chris made it clear that he is happy with the performance of playing FLACs with the latest changes, so we will not spend any more resources on this bug.

Are the changes going to be made to firmware in the 7.5 branch?

What are we supposed to do wit the .bin file linked to in comment 15?

OK we've decided to pull this one back for 7.5.1.

 == Auto-comment from SVN commit #8804 to the jive repo by agrundman ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8804 ==

Fixed bug 15361, FLAC ARM asm patch

7.5.1 r8804 contains this fix.

Current nightly seems to be 7.5.1-30822. What is r8804?

And for the second time of asking, what needs to be done with the .bin file referenced in Comment #15?

Nevermind, just install SBS 7.5.1 and you'll get the latest 7.5.1 firmware automatically.

I Installed r8810 on my Touch, but I still have the same problems when reading certain 24/96 FLAC files with Tiny SC on a 3.5" 1.5 Tb LaCie HDD containing 400 Gb of music (1200 albums).

However, I have no problem when reading the same files on the same HDD containing only a couple of albums.

When using the top program, I noticed that the CPU usage was far greater for these problematic files when the database is big.

The Touch is not able to play in USB-Mode HR-Flacs.
Music starts after some seconds rebuffering and so on.

Attached is a WD 2,5 HD with 16474 Files in 1197 Albums.
3 Albums in HR-Flacs rest in normal Flacs and 256 VBR mpr
Playing normal Flacs and 256 VBR mpr no problems.

Firmware 7.51.8847

Please reopen it has returned in later 7.6 versions.

And is present in this vesrion (i try it out right now)

Version: 7.6.0 - r31644 @ Fri Dec 17 03:01:10 MST 2010

One brief droop out in the first track played when cuing up an 24/96 album.

workaround

<< and start track1 from the beginning then it's fine.

iritating issue....

Now << trak 1 doesn't help ? it stutters on first track whatever.

So the fix must have been reverted somehow ? it does not work anymore period !

Ok ,when using the controller to control my Touch, it's broken.
When using the ir remote it still works .

Sugesting some very unfortunate interaction between two squeezeplay interfaces conected to the same player.

I kept my controller conected to another player, during this test

I suspect that this is down to the player not buffering sufficient content to cope with the delay in supplying additional data that results in the high cost of supplying SP and iPeng-type controllers with status data when a track starts playing.

I will look into the possibility of finding a way to buffer more data for high bit-rate sources as well as looking to see if there have been server-side regressions with respect to ensuring that the streaming code receives sufficient service.

(In reply to comment #38)
> I suspect that this is down to the player not buffering sufficient content to
> cope with the delay in supplying additional data that results in the high cost
> of supplying SP and iPeng-type controllers with status data when a track starts
> playing.
> 
> I will look into the possibility of finding a way to buffer more data for high
> bit-rate sources as well as looking to see if there have been server-side
> regressions with respect to ensuring that the streaming code receives
> sufficient service.

Sounds like a good idea .

You can actually get the same problem using standard rez content flac 16/44.1 ?
If controlling the Touch with the controller, this also happened lately this was ok until the last 1-2 months

(In reply to comment #38)
> I suspect that this is down to the player not buffering sufficient content to
> cope with the delay in supplying additional data that results in the high cost
> of supplying SP and iPeng-type controllers with status data when a track starts
> playing.
> 
> I will look into the possibility of finding a way to buffer more data for high
> bit-rate sources as well as looking to see if there have been server-side
> regressions with respect to ensuring that the streaming code receives
> sufficient service.

Ok I did an experiment that worked well:

In file /usr/share/jive/jive/audio/Playback.lua 

On the Touch i changed (line 342 in latest 7.6)

From

"
-- We can begin decoding with 2K of data
	local decodeThreshold = 2048
"

To this:

"
-- We can begin decoding with 2K of data
	local decodeThreshold = 2097152
"

This is 2048K of data ? (2048*1024=2097152)

It works for me .
Tried a lot of different albums all cued up with my controller.
Maybe this completely wrong sux and works by coincident ? Half this value does not remove the problem double it and the player goes silent.
I only tried multiples of 1024 must be a reason for it.

This also "fixed" bug 16750 for me and may be relevant to 16275

My fix makes it stop in a playlist if the song is really short 19 seconds , I can live with that until a better fix appears.

Alan,

I see comments on the forum that with iPeng or SqueezePlay the load induced to
the server when creating a playlist or downloading the current playlist data to
the client (which happens at the same time, so don't know which it is, suspect
the second) dramatically increased the load on the server with recent builds.

Maybe there's a database change here that causes more load and is also causing
this issue.

(In reply to comment #42)
> Alan,
> 
> I see comments on the forum that with iPeng or SqueezePlay the load induced to
> the server when creating a playlist or downloading the current playlist data to
> the client (which happens at the same time, so don't know which it is, suspect
> the second) dramatically increased the load on the server with recent builds.
> 
> Maybe there's a database change here that causes more load and is also causing
> this issue.

Makes sense I think my server could handle 170 songs a a Suqeezeplay device before now it's barely over 100 songs .
I could easily have a 2000 4000 song pl on my boom with the same server now it to croaks at 300 songs ? ir plays but cpu goes 100% for  2 minutes and you get a drop out.

My previus experience was the ip3k was ca 20 times lighter on the server, than SP.
But now it's getting bad there too ?

Like this one : https://bugs-archive.lyrion.org/show_bug.cgi?id=16089
PS don't ever press "shuffle" on a large pl .

another factor is that precache artwork does not precache all artwork so the server will resize cover arts too.

Mikael,

What O/S are you running on? So far, I have not been able to reproduce this, which I want to be able to do before trying out various fixes.

Alan.

Created attachment 7076 [details]
Possible patch

The comments I've seen were on OSX.

(In reply to comment #45)
> Mikael,
> 
> What O/S are you running on? So far, I have not been able to reproduce this,
> which I want to be able to do before trying out various fixes.
> 
> Alan.

I'm using CC4.2 never version is it's called clear -OS ,rpm like linux OS .

Version: 7.6.0 - r31716 @ Mon Jan 10 06:39:10 MST 2011
Hostname: hal.home.lan
IP: 192.168.1.5
HTTP Port: 9000
OS: Red Hat - EN - utf8
Platform: i686-linux
Perl Version: 5.8.8 - i686-linux-thread-multi
Database Version: DBD::SQLite 1.32_01 (sqlite 3.7.4)
Total Players Recognized: 3

My Hardware is a 1,2GHz VIA-EPIA x86 with 1GB of ram OS (and everything except the music)is installed on an Solid State drive.

Will have a look at the patch ?

As you updated Playback.lua for spotify I have to adjust.

line 136 to "self.decodeThreshold = 2097152"
And line 639 "self.decodeThreshold = 2097152"

I could probably let line 136 be as it is .

(In reply to comment #46)
> Created an attachment (id=7076) [details]
> Possible patch

Ok  I'll shall soon try your patch. Just some comments

But as i said i tried "self.decodeThreshold = 1048576"

and that was not enough even for 16/44.1 FLAC ?

"self.decodeThreshold = 2097152" is what I use .

I don't notice any delay at all I also tried some 160kPs mp3 files no delays i press play and it starts like it use to do ?

Is this buffer/threshold really compressed data is it not applied after the audio is decoded to PCM ? as i see no difference playing mp3 vs 24/96 flac in response when pressing play and pause etc ?

I'll report about it later....

You do not really want to change self.decodeThreshold as this will delay when it starts to decode the compressed audio. My change sets self.threshold which controls how much must have been received before playing will start. The decoder is allowed to run while this data is being received (unless you also set self.decodeThreshold).

How big are the playlists that you are playing? I have had great difficulty reproducing this at all with 96000/24 FLAC tracks and several-hundred-track playlists and with a reasonably slow server.

It would be very interesting to hear if the ANALYZE idea that Michael suggested yields any change in behaviour.

Are you server logs otherwise clear of error messages?

(In reply to comment #50)
> You do not really want to change self.decodeThreshold as this will delay when
> it starts to decode the compressed audio. My change sets self.threshold which
> controls how much must have been received before playing will start. The
> decoder is allowed to run while this data is being received (unless you also
> set self.decodeThreshold).
> 
> How big are the playlists that you are playing? I have had great difficulty
> reproducing this at all with 96000/24 FLAC tracks and several-hundred-track
> playlists and with a reasonably slow server.
> 
> It would be very interesting to hear if the ANALYZE idea that Michael suggested
> yields any change in behaviour.
> 
> Are you server logs otherwise clear of error messages?

Tried the Patch works for 16/44.1 but not for 24/96 .

be sure to use a controller to control the Touch otherwise the bug won't show up.

Will try higer self.threshold next .

I only try to play one album 10-15 tracks .

If I cue up a 200 track PL of any kind with a controller against my Touch my server will never leave 100% cpu until I kill it and delete the client playlist.

Will try analyze , I just needs to figure out how to do it will google up some knowledge..

Does this  ANALYZE fixes even a freshly made "rescan everything"

 == Auto-comment from SVN commit #31733 to the slim repo by ayoung ==
 == http://svn.slimdevices.com/slim?view=revision&revision=31733 ==

bug 15361: Can't play 24/48 or 24/96 flac without stutter and rebuffering 
Add a couple of idleStreams calls to deal with the consequences of long playlists.

Found some precompiled binaries

Now i have "sqlit3" and "sqlite3_analyser" in /bin on my server ?

They start up if I try to use them .

Now how do I do this ANALYZE thing , I will try.. ?

If:

[root@hal /]# sqlite3 /var/lib/squeezeboxserver/cache/squeezebox.db
SQLite version 3.7.4
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> analyze;
sqlite> 

I assume it was the right command :-)

I cued up all my 1472 hirez 24/96 tracks I even dared to shuffle them.

Starting a new album now gives 10% cpu spike instead off 100% !!

I did it rigth after a clear and rescan everything

Thank you. That is a very helpful result. The scanner is supposed to do an ANALYZE at the end of a rescan. Something must be going wrong.

(In reply to comment #55)
> Thank you. That is a very helpful result. The scanner is supposed to do an
> ANALYZE at the end of a rescan. Something must be going wrong.

The last lines in anyof my latest scans looks like this:
"
[10-09-12 18:29:24.3347] Slim::Music::Import::runScanPostProcessing (393) Starting Database optimization.
[10-09-12 18:29:24.3399] Slim::Music::Import::endImporter (610) Completed dbOptimize Scan in 0 seconds.
"

It is weird that it takes 0 seconds .

And I have not seen the optimise db progress bar in the web-UI for ages ?

(In reply to comment #46)
> Created an attachment (id=7076) [details]
> Possible patch

I hope you patch go in to the product anyway , even if my un analysed dB made sbs slow for me there are other slow things out there including the Touch itself when it is a server.

I saw no bad effects using it .

Btw is there a bug for dB not being properly analyzed ?