Subject: Re: [linux-audio-dev] sched_setscheduler question ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Jun 11 2000 - 03:39:19 EEST
On Sun, 11 Jun 2000, John Lazzaro wrote:
> > I think I may have a good technique in answer to this question
> > I posted to the list yesterday:
>
> And as it turned out, I had thought wrong -- while the code posted
> does the function, I missed the mimimum 10ms sleep time in the
> kernal code -- so in practice, this is just a complicated way of
> sleeping for 10ms. As it turns out, I _think_ that:
>
Sorry this doesn't make sense to me.
You either want SCHED_FIFO or you give up the RT privilieges by
sleeping a small amount of time.
Since HZ = 100, as soon you release the CPU, you will not be
rescheduled until the next tick, that means 10ms.
>> As long your app does not enter an infinite loop , ctrl-C is not a
>>problem,
>> since when you output audio using write() , you block regularly, thus
>>giving the chance to all other processes to run, and to intercept your
>>ctrl-C.
>I can't seem to duplicate this under OSS/Free using a Soundblaster PCI 128
>card -- basically, always in -timesync mode and for heavy-compute SAOL
>programs in -playback mode, write() is always called when there is at
>least one fragment ready for use, and so it seems like write() isn't
>blocking. Basically, when I set SCHED_FIFO in -timesync mode, with all
>other processes as SCHED_OTHER, the ctrl-c's never get seen. Thus the
>need for some other tricks, such as:
use a simple
while(1) {
do_your_stuff()
write_audio_fragment()
}
as long as you compute the audio faster than your sampling rate,
the write() will sleep when the buffer gets full and at this point
SCHED_OTHER tasks get the chance to run.
if you are unable to keep the buffer always full, then your sound
will dropout sooner or later , regardless of SCHED_FIFO or not.
there could be one RARE case where then SCHED_FIFO app
does not release the processor AND no dropouts occur:
let's say your buffer is filled by 75%, and at this point you use
EXACTLY 100% of the CPU (per fragment), that means at the
next run the buffer will still be filled at 75% and the write() call
does not block.
But in this case your sleep trick will not work too:
as soon as you sleep the buffer will get more empty, and
you are unable to rerfill the additional space during the next runs.
After a few sleeps you will get dropouts.
As long you use <100% of the CPU my described concept
(basis of almost all audio apps) works.
But using 100% of the CPU will not work.
still not convinced ?
:-)
Benno.
This archive was generated by hypermail 2b28 : Sun Jun 11 2000 - 03:19:00 EEST