PDA

View Full Version : Sox using inordinate amount of CPU



bmccall
2005-05-31, 11:15
I have slim server 6.0.2 on windows XP with 500 ram and 500 cpu. Each time I play something from my ogg playlist using sox and try to change to a new playlist or clear the playlist, sox consumes 90+ % of the CPU for two or three minutes. The playlist does not clear or change until sox stops using all of the Cpu. During that period Squeezebox usually loses contact with slimserver(ethernet wired) I see no reason why sox should participate in either of these functions as it is only supposed to decode the ogg vorbis music. Is this normal and if not how do I stop it as it is grossly disrupting trying to use the squeezebox.

Thanks!

Ben McCall

cliveb
2005-05-31, 11:26
I have slim server 6.0.2 on windows XP with 500 ram and 500 cpu. Each time I play something from my ogg playlist using sox and try to change to a new playlist or clear the playlist, sox consumes 90+ % of the CPU for two or three minutes. The playlist does not clear or change until sox stops using all of the Cpu. During that period Squeezebox usually loses contact with slimserver(ethernet wired) I see no reason why sox should participate in either of these functions as it is only supposed to decode the ogg vorbis music.
When I was running Slimserver on a Windows 2000 machine I had exactly the same issue. I think you'll find that, out of the box, Slimserver is set up to transcode ogg to flac (which requires running both sox and flac with a pipe between them).

The simplest solution I found was to edit the convert.conf file and comment out that line, leaving only the option to convert ogg to wav directly with oggdec.

stuorguk
2005-05-31, 13:16
I have the same problem on my Linux box ever since I upgraded to version 6. V5 was better, but also slow. If I browse my music folder, my squeezebox regularly looses contact. It's not just ogg files either.

The SB should be running under a separate thread. Surly it shouldn't be loosing contact, regardless of what slimserver is doing. The most frustrating thing of all, is if I browse into the wrong directory, then apon realising my mistake, have to wait for slimserver to catch up before I can browse back a step - loosing contact for a minute or two in-between.

Stuart.

jared1999
2006-05-03, 16:04
Did anyone solve this problem? The same thing happens with SlimServer v6.2.2 on Gentoo Linux x86-64 with Sox v12.17.19. If a vorbis track plays out the Sox process dies normally. However, if playback is interrupted (e.g. changing the track) the Sox process jumps to 100% cpu usage and never disappears (at least not for the 30 minutes I tested). If the same procedure is repeated the Sox processes start piling up.


The simplest solution I found was to edit the convert.conf file and comment out that line, leaving only the option to convert ogg to wav directly with oggdec.
Can oggdec pipe to flac instead of sox? Bandwidth is more important to me than cpu usage.

jared1999
2006-05-03, 16:24
Can oggdec pipe to flac instead of sox? Bandwidth is more important to me than cpu usage.
If I had just browsed through convert.conf sooner I would have seen that the previous conversion does exactly that.

knigma
2006-07-06, 23:55
I see runaway sox just as described above by jared1999 with slimserver 6.3 playing ogg files with a stock convert.conf file. sox: Version 12.18.1, FreeBSD 6.1 with perl 5.8.8. Does anyone have an understanding of the cause?

knigma
2006-07-07, 12:07
I see runaway sox just as described above by jared1999 with slimserver 6.3 playing ogg files with a stock convert.conf file. sox: Version 12.18.1, FreeBSD 6.1 with perl 5.8.8. Does anyone have an understanding of the cause?

I confirm that switching to oggdec solves the problem for me. Does this mean the bug lies in sox rather than slimserver? I haven't managed to provoke this behaviour using sox and lame in a simple shell pipeline.