Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 4 of 4
  1. #1
    Jason Holtzapple
    Guest

    Squeezebox: Sound drop out with Flac files

    --- "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

  2. #2
    Andrew W. Donoho
    Guest

    Squeezebox: Sound drop out with Flac files

    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)

  3. #3
    Stephen Ryan
    Guest

    Squeezebox: Sound drop out with Flac files

    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>

  4. #4
    Stuart Hickinbottom
    Guest

    Squeezebox: Sound drop out with Flac files

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •