View Full Version : SB3 running out of CPU cycles on HQ vorbis?

2007-09-20, 04:25
hi all!

i love my SB3. matter of fact, i just got my 2nd one. ;-)

BUT i just discovered something rather unsettling and i would like to see if anyone out there has noticed a similar effect.

i generally encode my CDs using SJeng's OggEncGTb3 tuned ogg-vorbis encoder set to q6. i find this gives vorbis tracks a lightness and airyness lacking in other encoders.

however, it allows does allow bitrates to soar quite a bit on complex tracks.

and now it seems i have found a track, which starves the SB3's CPU. Symptoms:

1. buffer fullness is always 100% -> no network problem.

2. play track with large spectrum analyser screensaver or now playing -> SB3 "chokes" after ~5-10 sec. of playing. displays "rebuffering 0%", display kind of flickers and playback stops/stutters. if i leave it alone long enough, it will recover after a minute or two and continue playing normally.

3. switch "now playing" to a static display without visualization -> playback commences again perfectly normally and never skips a beat.

4. turn visualization back on -> SB3 "chokes".

these symptoms would indicate that displaying viz + high-bitrate vorbis chokes the SB3s CPU?

the track in question is encoded @ q6, but will run at ~400-500 kbit/s for minutes on end. posting here is not practical, because the track is ~22 MB large. but i can provide it as a download or by mail if required.

if anyone else has been seeing this, should we report this as a bug? or a feature request?

i understand that one could argue OggEncGTb3 does not comply to ogg-vorbis reference specs, but then again i am only encoding @ q6. if CPU choking is indeed a problem, then it should even occur with the reference vorbis encoder @ q8-10, which is claimed to be supported by slimdevices, no?

thanks for your thoughts!


2007-09-20, 04:43
would say it is entirely possible that the SB3 chokes on some high quality encodes. And from your description of turning off anf on the visualisations, i think thats whats happening.

i generally encode my CDs using SJeng's OggEncGTb3 tuned ogg-vorbis encoder set to q6. i find this gives vorbis tracks a lightness and airyness lacking in other encoders.

Have you thought about using FLAC instead? It's lossless so there is no question about "lightness and airyness" as it is identical to the original CD.

2007-09-20, 06:36
hi funktstar,

actually i have. when i ripped the file, i did not realize how complex it was and that vorbis bitrates would soar like that. i normally avoid FLAC, because it is too big for me and i find vorbis @q6 to be indistinguishable from FLAC.

so far, i see many workarounds, none which are too painful:

1. re-rip those tracks in FLAC.

2. transcoding. but my slimserver is running on a serverly resource-starved system anyway and it may have similar problems on that track. thats why i like the SB3's native vorbis decoder! :-)

3. just dont use the visualizations. shame, tho, because they look cool and impress the hell out of visitors! ;-)

4. just "zap" the track for know to prevent it from stalling my SB3.

but isnt there maybe a way to optimize the vorbis decoder in SB3's firmware?

2007-09-20, 06:39
Try the official encoder, we tested some tracks at q10 with the official encoder and they playback fine. q6 shouldn't produce files with such a large bitrate.

But yes, Ogg decoding is a cpu-intensive process so what you describe is definitely a cpu problem. I'm sure there is room for improvement in our Ogg decoder but right now your best bet is to use the official encoder, or just go with FLAC if you want the best quality as others have mentioned. :)

2007-09-20, 07:09
FWIW I have several thousand tracks encoded at Q8 using the standard encoder, and have never encountered a problem like this. :-)

2007-09-21, 03:06
thanx for your thoughts on this guys. :-)

yeah - i'll just re-rip the offending track in FLAC.

and i agree with jeebers - this is the first of my thousands of tracks encoded with GTuneb3 which exhibits this phenomenon. never seen it before.

i suspect it has to do with extreme and sudden bitrate spikes GTuneb3 produces. in this track, bitrates will jump from reasonable 250 kbit to ~570 kbit and back to 400 kbit.

i know vorbis normally makes heavy use of floating point operations, which are typically badly implemented (or must be emulated) on embedded CPUs. or does slimdevices already use the integer implementation of the vorbis decoder called "tremor"? (http://xiph.org/vorbis/)

gentlemen, does something like this merit a feature request / bugreport? probably not, but you never know, you know? ;-)