From: Anthony DiSante <orders@nodivisions.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Audio skips when RAM is ~full
Date: Sat, 01 Nov 2003 01:34:12 -0500 [thread overview]
Message-ID: <3FA353E4.60906@nodivisions.com> (raw)
In-Reply-To: <20031101062050.GA13731@alpha.home.local>
Willy Tarreau wrote:
> 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.
No, I'm not certain that mpg321 (or any other app, though there's
next-to-nothing else running) is leak-free.
> 2) you can try to preload your file into the cache just before playing it :
> cp $file /dev/null ; mpg321 $file
But wouldn't "cp $file /tmp/ramdisk0; mpg321 /tmp/ramdisk0/$file" accomplish
the same thing? (I've done that.)
>>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.
Actually, I don't scan the disk to find random albums; I have a text file
that contains a list of every album's full path, and I pick a random line
from that file. So only the selected album's directory gets scanned. And
the mp3 partition is mounted read-only (I should have mentioned that
before), so the atimes shouldn't be getting written as it is.
> You might also want to try 2.4.23pre9 which includes VM changes compared to
> 2.4.22, and seems quite stable to me.
Maybe I will give that a try.
So I'm guessing that there isn't actually a way to manually move buffer-data
out of RAM?
-Anthony
http://nodivisions.com/
next prev parent reply other threads:[~2003-11-01 6:35 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
2003-11-01 6:34 ` Anthony DiSante [this message]
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=3FA353E4.60906@nodivisions.com \
--to=orders@nodivisions.com \
--cc=linux-kernel@vger.kernel.org \
/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