From: Willy Tarreau <willy@w.ods.org>
To: Anthony DiSante <orders@nodivisions.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Audio skips when RAM is ~full
Date: Sat, 1 Nov 2003 07:20:50 +0100 [thread overview]
Message-ID: <20031101062050.GA13731@alpha.home.local> (raw)
In-Reply-To: <3FA34523.30902@nodivisions.com>
Hello !
On Sat, Nov 01, 2003 at 12:31:15AM -0500, Anthony DiSante wrote:
> The kernel is buffering the contents of each directory (album) that it
> reads (and also, mpg321 copies each mp3 file into RAM before playing it?).
> I understand that the idea is to stuff as much into RAM as possible to
> reduce pagefile usage, and that the kernel will reclaim memory utilized by
> buffers if/when it needs to. But apparently that isn't happening fast
> enough to allow a realtime process like music-playing to work skip-free on
> this system with this soundcard. I think that if I could regularly
> forcibly dump the buffered stuff out of the RAM (dropping the used-RAM
> percentage down to, say, 10%, like at boot time) then this would make the
> skipping stop.
1) are you certain that none of your programs (including mpg321) leaks
memory ? As I understand it, it's really the cache which fills memory.
2) you can try to preload your file into the cache just before playing it :
cp $file /dev/null ; mpg321 $file
> So... do I have a correct understanding of the problem, and a correct
> analysis of the kernel/mem issues that are related to it? Is it possible
> to clear some of the RAM; if so, would that help?
Unless a leak happens somewhere in the kernel, sound driver, etc..., memory
consumed by programs is restored when your programs exit. The only part which
is not restored immediately is the cache.
BTW, there may be one other reason for your problem. Considering that you
scan your disk to find random albums, I think that the system updates all
directories access time after 5s, thus preventing your player from reading
an uncached file fast enough. You might be interested in mounting it with
the 'noatime,nodiratime' options in /etc/fstab.
You might also want to try 2.4.23pre9 which includes VM changes compared to
2.4.22, and seems quite stable to me.
Regards,
Willy
next prev parent reply other threads:[~2003-11-01 6:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-01 5:31 Audio skips when RAM is ~full Anthony DiSante
2003-11-01 6:20 ` Willy Tarreau [this message]
2003-11-01 6:34 ` Anthony DiSante
2003-11-01 7:19 ` Willy Tarreau
2003-11-01 12:48 ` Anthony DiSante
2003-11-01 14:57 ` Jaroslav Kysela
2003-11-01 9:43 ` Maciej Zenczykowski
2003-11-01 18:08 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031101062050.GA13731@alpha.home.local \
--to=willy@w.ods.org \
--cc=linux-kernel@vger.kernel.org \
--cc=orders@nodivisions.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox