Subject: Re: [linux-audio-dev] Re: sched_setscheduler question ...
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Sun Jun 11 2000 - 02:53:42 EEST
> OK, so to clarify a little bit: the SCHED_FIFO policy is for the
> program produced by sfront, not for sfront itself, is that correct ?
Correct
> this seems unusual. people can run Csound without SCHED_FIFO and
> without clicks under Linux, unless the computational load is high. is
> that the situation you're describing ?
Basically, what you describe is true in practice in my own use of the
C files sfront creates too -- I can play pretty complex SAOL programs
from the MIDI keyboard for many many minutes and never hear a click.
But from what I understand from other users, you can get unlucky if
you run with the "latency" parameter low (basically, how many milliseconds
of silence at the start of the code), if you've got a heavy-CPU SAOL
instrument, and if a daemon wakes up at the wrong time, ect -- in this
case, every 10 or 20 minutes you'll get a click that "comes out of nowhere".
So, the goal with SCHED_FIFO is to eliminate those instances.
> How many fragments do you request ?
I let OSS decide -- I set the SSSS bits in SNDCTL_DSP_SETFRAGMENT to
a value derived from the "latency" the user asks for, and set MMMM to
7FFF. So far, this has seemed to work pretty well (i.e. running as
SCHED_OTHER).
> I don't get it. On the one hand, you seem to want to deal with
> situations where the computational load is so high that not running
> with SCHED_FIFO causes dropouts. On the other hand, you seem to be
> willing to yield the processor for 10-30ms at a time.
Hopefully the earlier paragraph helps answer this somewhat -- the
"rare click" is what I'm hoping to address with SCHED_FIFO ... but
the issue is, given the current way I set up the fragments, the
"natural" way to let SCHED_OTHER's run occassionally (when write
is blocking) never happens, and so I'm faced with the "how does the
user control-C an errant program" problem. One way you can imagine
handling this is, as part of sfront's computation of the "cpuload"
variable, it can sense when its finished computing all of its
control-period samples early -- in this case, in -timesync mode, it
spins to finish the control-period, then checks the MIDI In queue
for new notes, and processes them. Occassionally, when faced with
an "early completion" control cycle, instead of spinning it can
yield to SCHED_OTHER processes, taking the lowest-probability
risk of a click while letting the control-C get through. But this
approach is less reasonable to try if the only way to let SCHED_OTHER
processes run incurs a HZ delay, even if no other processes want to
run.
Of course, this are various other ways out of this problem that
sidestep the control-C problem entirely (denoting special program
change sequences from the MIDI keyboard to signal "end the C program",
for example), as well as ways to re-architect the code sfront produces
so that blocking on write() would happen. Maybe one of these is a better
way to go ... but the plan in the last paragraph has advantages too.
I guess one side issue to note, sfront has 200-page MPEG spec is has
to conform to, as well as other project-related goals (supporting a
general driver interface, ANSI C w/ only ANSI libraries for the core
generated program, real-time, streaming, and batch mode all in the
same framework, ect) -- these factors can make what would seem to
be simple changes hard to carry out in practice sometimes.
> Also, on an somewhat unrelated note: are you aware of
>
> (1) ALSA's support for high-end soundcards, which OSS cannot
> really support well because of API limitations
> (2) The fact that high-end soundcards will violate some or all
> of the assumptions that most Linux audio applications
> seem to use (16 bit, stereo, interleaved sample streams) ?
Yes, I totally agree, the goal is to have true ALSA audio drivers as
well as OSS drivers in sfront -- its on the list of things to do.
--jl
This archive was generated by hypermail 2b28 : Sun Jun 11 2000 - 03:23:34 EEST