PDA

View Full Version : Squeezebox: Sound drop out with Flac files



Jason Holtzapple
2004-03-14, 12:17
--- "Andrew W. Donoho" <awd (AT) DDG (DOT) com> wrote:

> Since this problem appears with both FLAC and AAC, I would suspect the
> common element is the root cause - SlimServer and how it handles .wav
> streams. It also appears to occur in both WinXP and Linux. Both systems
> use external to slimserver.pl helper applications to decode the
> streams. At minimum, I would be looking at that interface between
> processes. (In Linux, the decoder has a "lower" execution priority than
> the server. This leads to my suspicion that the decoder is being
> starved for cycles under heavy load.)

Unix child processes should have the same priority as the parent.
I've verified that decoder processes have the same priority under
NetBSD, and they should also under Linux.

By the way, I'm not suffering from FLAC dropouts. NetBSD server,
wireless to squeezebox.

--Jason

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

Andrew W. Donoho
2004-03-14, 18:09
On Mar 14, 2004, at 13:17, Jason Holtzapple wrote:

> --- "Andrew W. Donoho" <awd (AT) DDG (DOT) com> wrote:
>
>> Since this problem appears with both FLAC and AAC, I would suspect
>> the
>> common element is the root cause - SlimServer and how it handles .wav
>> streams. It also appears to occur in both WinXP and Linux. Both
>> systems
>> use external to slimserver.pl helper applications to decode the
>> streams. At minimum, I would be looking at that interface between
>> processes. (In Linux, the decoder has a "lower" execution priority
>> than
>> the server. This leads to my suspicion that the decoder is being
>> starved for cycles under heavy load.)
>
> Unix child processes should have the same priority as the parent.
> I've verified that decoder processes have the same priority under
> NetBSD, and they should also under Linux.


Jason,

All I can do is report what I see. Here is snapshot from top while
SlimServer is decoding an AAC file:

215 processes: 209 sleeping, 5 running, 1 zombie, 0 stopped
CPU0 states: 21.1% user 6.1% system 0.4% nice 0.0% iowait
72.3% idle
CPU1 states: 97.5% user 1.1% system 96.2% nice 0.0% iowait
1.0% idle
Mem: 513228k av, 503484k used, 9744k free, 0k shrd,
80436k buff
375692k actv, 8k in_d, 14204k in_c
Swap: 1179872k av, 47232k used, 1132640k free
262172k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU
COMMAND
1041 awd 39 19 14824 14M 844 R N 98.4 2.8 2822m 1
setiathome
24261 slimserv 15 0 22688 22M 1420 R 13.7 4.4 71:30 0
slimserver.pl
19559 slimserv 25 0 1200 1200 968 R 5.9 0.2 0:09 0 faad
1089 awd 15 0 2896 2896 1268 S 3.5 0.5 61:32 0
gkrellm
19456 awd 16 0 1268 1268 804 R 1.7 0.2 0:10 0 top
968 root 15 0 48796 9808 464 R 0.7 1.9 150:01 0 X
8 root 15 0 0 0 0 SW 0.1 0.0 0:04 0
kscand/DMA
17 root 15 0 0 0 0 SW 0.1 0.0 0:12 0
kjournald
647 named 25 0 12680 12M 1256 S 0.1 2.4 5:36 1 named
661 root 15 0 524 452 288 S 0.1 0.0 0:06 0 sshd
924 root 15 0 3672 1184 812 S 0.1 0.2 0:06 0
miniserv.pl
1101 awd 15 0 10956 10M 2900 S 0.1 2.1 83:28 1
rhn-applet-gui

The two processes with user "slimserv" are the server perl process,
slimserver.pl, and the native C AAC decoder, faad. For example,
setiathome is running fully reniced to 19. From this snapshot the
server is running at a priority of 15 and the child process is running
at a priority of 25. (Lower numbers are higher priority on Linux.) I
conclude from that data that the decoder is somehow running at a lower
priority (higher number = 25) than its parent (lower number = 15).
Hence, my use of the term "priority starvation."

I would invite your analysis of the above and any guidance on other
information I might be able to dig out of Linux to diagnose the
skipping behavior.

As an added data point, I have been able to manually renice the faad
tool to equal the priority of the slimserver.pl. As a result, I have
not been able to induce skipping. OTOH, I haven't tested it very hard
yet.

> By the way, I'm not suffering from FLAC dropouts. NetBSD server,
> wireless to squeezebox.

Congratulations.

Andrew
____________________________________
Andrew W. Donoho
awd (AT) DDG (DOT) com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

Stephen Ryan
2004-03-14, 18:56
On Sun, 2004-03-14 at 20:09, Andrew W. Donoho wrote:
> On Mar 14, 2004, at 13:17, Jason Holtzapple wrote:
>
> --- "Andrew W. Donoho" <awd (AT) DDG (DOT) com> wrote:
>
> Since this problem appears with both FLAC and AAC, I
> wouldsuspect the
> common element is the root cause - SlimServer and how
> it handles .wav
> streams. It also appears to occur in both WinXP and
> Linux. Bothsystems
> use external to slimserver.pl helper applications to
> decode the
> streams. At minimum, I would be looking at that
> interface between
> processes. (In Linux, the decoder has a "lower"
> execution prioritythan
> the server. This leads to my suspicion that the
> decoder is being
> starved for cycles under heavy load.)
>
> Unix child processes should have the same priority as the
> parent.
> I've verified that decoder processes have the same priority
> under
> NetBSD, and they should also under Linux.
>
>
> Jason,
>
> All I can do is report what I see. Here is snapshot from top
> whileSlimServer is decoding an AAC file:
>
> 215 processes: 209sleeping, 5 running, 1 zombie, 0 stopped
> CPU0 states: 21.1% user 6.1% system 0.4% nice 0.0% iowait
> 72.3% idle
> CPU1 states: 97.5% user 1.1% system 96.2% nice 0.0% iowait
> 1.0% idle
> Mem: 513228k av, 503484k used, 9744k free, 0k shrd,
> 80436k buff
> 375692k actv, 8k in_d, 14204k in_c
> Swap: 1179872k av, 47232k used, 1132640k free
> 262172k cached
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME
> CPUCOMMAND
> 1041 awd 39 19 14824 14M 844 R N 98.4 2.8 2822m
> 1setiathome
> 24261 slimserv 15 0 22688 22M 1420 R 13.7 4.4 71:30
> 0slimserver.pl
> 19559 slimserv 25 0 1200 1200 968 R 5.9 0.2 0:09 0 faad
> 1089 awd 15 0 2896 2896 1268 S 3.5 0.5 61:32
> 0gkrellm
> 19456 awd 16 0 1268 1268 804 R 1.7 0.2 0:10 0 top
> 968 root 15 0 48796 9808 464 R 0.7 1.9 150:01 0 X
> 8 root 15 0 0 0 0 SW 0.1 0.0 0:04
> 0kscand/DMA
> 17 root 15 0 0 0 0 SW 0.1 0.0 0:12
> 0kjournald
> 647 named 25 0 12680 12M 1256 S 0.1 2.4 5:36 1
> named
> 661 root 15 0 524 452 288 S 0.1 0.0 0:06 0 sshd
> 924 root 15 0 3672 1184 812 S 0.1 0.2 0:06
> 0miniserv.pl
> 1101 awd 15 0 10956 10M 2900 S 0.1 2.1 83:28
> 1rhn-applet-gui
>
> The two processes with user "slimserv" are the server perl
> process,slimserver.pl, and the native C AAC decoder, faad. For
> example,setiathome is running fully reniced to 19. From this snapshot
> theserver is running at a priority of 15 and the child process is
> runningat a priority of 25. (Lower numbers are higher priority on
> Linux.) Iconclude from that data that the decoder is somehow running
> at a lowerpriority (higher number = 25) than its parent (lower number
> = 15).Hence, my use of the term "priority starvation."
>
> I would invite your analysis of the above and any guidance on
> otherinformation I might be able to dig out of Linux to diagnose
> theskipping behavior.

I'm pretty sure that most recent versions of Linux do some kind of
dynamic adjustment of priorities; processes that hog the cpu
automatically get downgraded, while "interactive" processes (=waits for
user input) get boosted. I have strong suspicions that WinXP does
similar things to boost responsiveness.

Since the transcoding process typically hogs a log of the cpu *and* is a
program normally run as a non-interactive process being run in the
background, it makes sense that the priority would drop, since it looks
just like something that normally shouldn't be allowed to hog the cpu
(and in fact, the OS is normally correct in lowering the priority of
those processes, because the intended usage is not as a real-time
transcoder). The fix is to identify the transcoder as a "real-time"
task; unfortunately, I know pretty much nothing about that other than
manually renicing (perhaps that could be part of the configuration?)
--
Stephen Ryan <steve (AT) deepthought (DOT) dartmouth.edu>

Stuart Hickinbottom
2004-03-15, 15:44
On Sun, 14 Mar 2004 20:56:42 -0500, Stephen Ryan
<steve (AT) deepthought (DOT) dartmouth.edu> wrote:

> transcoder). The fix is to identify the transcoder as a "real-time"
> task; unfortunately, I know pretty much nothing about that other than
> manually renicing (perhaps that could be part of the configuration?)

Hmmm. After being quite convinced that this was a problem, and raising an
official bug (#218), I must now admit to being less than convinced.

I've now been playing FLACs for many hours and have had no more drop-outs.
I've been experimenting with moving the wireless AP around a bit and that
may have had an effect. While we were all convinced that the 'suddenly
emptying buffer' effect was indicative of a problem I'm no longer sure -
on my system, at least, I've noticed that the buffer emptying almost
immediately is normal behaviour at the end of every FLAC track.

Whilst I can imagine that raw audio over the wireless might be stretching
things given my signal strength (60%) and my faily weedy server (530MHz
Via Samuel 2), it doesn't explain problems with larger servers and wired
connections so perhaps there are two different problems here?

On the priority front, as I've decided that my server should give priority
to serving sound, I start the slimserver.pl server with a "nice
--adjustment=-10" command. This nice value then applies to the server
itself as well as any flac child process that it creates. This is the
resulting bit of my process list:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12688 root 39 19 15076 14m 1160 R 76.1 6.0 9154:50 setiathome
22088 slim 5 -10 43176 38m 8296 S 8.1 15.7 190:36.20 slimserver.pl
21927 slim 5 -10 828 824 548 S 7.8 0.3 0:00.88 flac

As you can see, both processes are given the -10 niceness value (so they
have pretty much all the CPU they want), and they both end up with the
same priority value (on my 2.4.20-gentoo-r8 system, at any rate).

Whilst you might expect the child process to be a higher priority, I'm not
sure that it necessarily has to be. Looking at your 'top', CPU0 (which has
the two SlimServer processes) is 70% idle, which I would assume means that
faad is blocking waiting for the network to drain the data from it, rather
than it straining at the CPU wanting more time to do the decoding. It's
also possible that faad is blocking waiting for data from the disk, but
I'm guessing you'd have noticed if the disk was thrashing terribly.

Hmmm, I don't think I've done much to help things here, I'm afraid to
say...

Stuart