Pause after track change with multiple Squeezeboxes using Apple Lossless

[Jon Webber]

I have two Squeezeboxes. I'm streaming Apple Lossless to both of them.

When I have both running with separate tracks things are fine until I
skip to another track on one unit. This causes the music to pause on
the other squeezebox. On investigation this is because the mov123.exe
file takes up about 80-90% of CPU for a short burst (I'm guessing while
it loads in the Lossless file?), thus affecting the other stream. I'm
running this on an old Pentium II PC 400Mhz, with 380 RAM. I've also
tried it on my relatively new AMD 2600 PC with 1 Gb of RAM, and
mov123.exe occasionally gets up to the 60% CPU mark, sometimes causing
the other player to pause in a similar fashion.

Is there anything that can be done in mov123.exe to soften this peak of
CPU activity? or can you suggest I try something else to fix the
problem.

Cheers,

Jon

[vidurapparao]

Pause after track change with multiple Squeezeboxes usingApple Lossless

Jon Webber wrote:

> I have two Squeezeboxes. I'm streaming Apple Lossless to both of them.
>
> When I have both running with separate tracks things are fine until I
> skip to another track on one unit. This causes the music to pause on
> the other squeezebox. On investigation this is because the mov123.exe
> file takes up about 80-90% of CPU for a short burst (I'm guessing
> while it loads in the Lossless file?), thus affecting the other
> stream. I'm running this on an old Pentium II PC 400Mhz, with 380
> RAM. I've also tried it on my relatively new AMD 2600 PC with 1 Gb of
> RAM, and mov123.exe occasionally gets up to the 60% CPU mark,
> sometimes causing the other player to pause in a similar fashion.
>
> Is there anything that can be done in mov123.exe to soften this peak
> of CPU activity? or can you suggest I try something else to fix the
> problem.

When an AAC or Apple Lossless track starts, there are 3 steps that can
contribute to a greater CPU load:
1) The mov123.exe application is loaded and initialized. An instance is
created for each individual track.
2) Quicktime is initialized and pointed at the audio file. Several
Quicktime calls are made to get information about the audio stream.
3) mov123.exe sits in a loop, decoding audio buffers until it fills up
the pipe between it and SlimServer (or lame.exe, if you are
transcoding). Once the pipe is full, it blocks until there's more work
to be done.

The other decoding tools - wmadec, oggdec, etc. - have similar
operational logic. I've confirmed that mov123.exe seems to have a higher
CPU spike than the others (for AAC as well as Apple Lossless, so it's
not codec specific), leading me to believe that it's Quicktime that's
the culprit. It's also possible that we could reduce the load by being a
little bit less aggressive about decoding in step 3).

I've filed a bug at http://bugs.slimdevices.com/show_bug.cgi?id=345
related to this. It will probably be looked at post 5.2. Feel free to
add yourself to the cc: list for the bug.

--Vidur