Re: [linux-audio-dev] sched_setscheduler question ...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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
-------------------------------------------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Jun 11 2000 - 03:58:00 EEST