Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: linux-sound@vger.kernel.org
Subject: Re: [alsa-devel] New scheduling latencies during audio playing + heavy disk I/O on various kernels
Date: Thu, 17 Jun 1999 12:02:44 +0000	[thread overview]
Message-ID: <marc-linux-sound-92962100616666@msgid-missing> (raw)

>From:	Benno Senoner <sbenno@gardena.net>
>
>audio FX, harddisk recording .. , DURING HIGH DISK ACTIVITY,
>
>Unfortunately the answer is NO, with current kernels.

Your last test had an unlimited disk activity but in an audio application
the disk activity is limited by number of channels times the sample rate.
(We just have to make sure that the audio application is only serious
disk user.)

How about testing it too? Does it really make difference?
I think it makes because your current tests seems to not be limited
in any reasonable way.

>what helped alot is the remount of the disk in sync mode
>( mount / -oremount,sync )
>in this case the average scheduling latencies are very good
>between 16-19ms during the disk stressing tests.

Did you measure the wall clock time used to copy (whatever) the file
in both cases? I have feeling that it took longer to copy the file,
i.e., the same effect what is gained by limiting the disk activity.
So, perhaps we reach the < 20 ms latencies just by using the disk the
way audio software uses it.

But surely a change to kernel would make it possible to limit the disk
activity in favor of RT scheduling.

>I'm not a kernel hacker but IMO the problem seems
>the kernel which holds some locks for too much time 
>during heavy disk I/O, which results in a blocking of the
>write() call (to /dev/dsp).

How about defining a maximum number of swap pages to write to disk at
a time? Does kernel really have to wait for the disk operation to complete?
I have heard the disk interrupt takes only 0.4 ms -- not the tested
50-200 ms. Ok, I know next to nothing about the kernel...

Yours,

Juhana

             reply	other threads:[~1999-06-17 12:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-17 12:02 Juhana Sadeharju [this message]
1999-06-17 19:35 ` [alsa-devel] New scheduling latencies during audio playing + Andrea Arcangeli

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=marc-linux-sound-92962100616666@msgid-missing \
    --to=kouhia@nic.funet.fi \
    --cc=linux-sound@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