Subject: Re: [linux-audio-dev] sched_setscheduler question ...
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Sun Jun 11 2000 - 03:30:03 EEST
This note will make more sense if read after my reply to Paul's
note a few minutes ago, since there are a few cross-references ...
> 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.
Essentially, in -timesync mode, sfront monitors the data from
the SNDCTRL_DSP_GETOPTR and SNDCNTRL_DSP_GETOSPACE ioctl's, and
busy-wait spins when necessay to ensure this always happens. Actually,
the development version (the upcoming sfront 0.62 in a few weeks) uses
both, and thus works more reliably -- the current 0.61 only used
SNDCTRL_DSP_GETOPTR info and tried to deduce blocking status from the
size value, with enough heuristics to work >99% of the time, and fall
victim to an infinite loop bug under rare conditions.
This is done because it was the most straightforward way to ensure
MP4-SA semantics, in the case where you have "pre-recorded" SASL or
MIDI data that a user is "playing along" with in real-time (either
audio in or MIDI in or both), in a world where you only have a single
thread (the "ANSI C in the core code section" requirement).
Once you go with this approach, its natural to use MMMM=7FFF in the
SETFRAGMENT ioctl, and use the maximal number of buffers, which is
what the C code sfront generates currently does.
So, as I explained in the earlier note to Paul, the basic hope was
that when running in SCHED_FIFO mode, I'd detect situations where
I was planning to busy-wait for a long time, and occassionally pick
one of those times to let the SCHED_OTHER processes communicate any
cntrl-c's.
In -playback mode, sfront essentially works like:
while(1) {
do_your_stuff()
write_audio_fragment()
}
so your comments apply to it. However, given that I'm working with an
arbitrary user SAOL program as input, the chances that the program
is just complex enough to keep:
> 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.
going for minutes and minutes, never blocking and letting
the cntrl-C through, is not miniscule -- not to mention:
> if you are unable to keep the buffer always full, then your sound
> will dropout sooner or later ,
Lots of dropouts are happening, so the user wants to cntrl-C, but he
can't because nothing ever blocks!
For both cases, it seems wise to have code smart enough to detect
when a write hasn't blocked for a long time, and sneak in a forced
SCHED_OTHER pass at an opportune time ...
--jl
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Sun Jun 11 2000 - 03:58:00 EEST