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

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

Subject: [linux-audio-dev] Re: sched_setscheduler question ...
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Sat Jun 10 2000 - 03:07:54 EEST


  
> From: Paul Barton-Davis <pbd_AT_op.net>

and

> From: Benno Senoner <sbenno_AT_gardena.net>

Thanks for the quick replies, there's enough overlap in the
two responses that I'll consolidate for lessen redundancy ...

[pbd_AT_op.net]

> However, I cannot understand why you want sfront to run SCHED_FIFO. My
> understanding of sfront (and I've read most of the manual
> cover-to-cover) is that its a non-realtime application.

See:

http://www.cs.berkeley.edu/~lazzaro/sa/sfman/user/use/index.html#rt

Basically, you can create sa.c files using sfront with the -playback
(audio streaming for SAOL that has no real-time audio or control
inputs) or -timesync (real-time systems that take audio and control
input from a sound card, and use it to control the SAOL program). See
the examples/linux subdirectories in the distribution for real-time
examples -- these work pretty well on my PIII 450 Mhz with a Soundblaster
PCI 128 soundcard with audio and MIDI inputs.

There are actually some content-oriented folks that are using it
pretty seriously (see www.saol.net) and they've been asking for
improvements in the Linux support. So I've been rewriting the sfront
audio and control drivers for Linux -- so far just bug-fixes and ioctl
error checking (note these fixes aren't in the release available for
download at the moment, it should be out in a few weeks -- the current
release can lock up under very heavy loads occassionally, so be
careful if you run it under SCHED_FIFO).

So, I'm now looking at the pros and cons of adding SCHED_FIFO and page
locking for -timesync and -playback modes ... the biggest problem with
-timesync now is the occassional daemon wake-up causing a click, which
SCHED_FIFO seems to solve completely, so it seems worth pursuing so
the saol.net folks can stop rebooting into single-user mode so often :-).

[sbenno_AT_gardena.net]

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

[pbd_AT_op.net]

> One bizarre thing that you could do is to open an audio device, and
> sleep on the I/O to/from the card.

This seems like it might do the trick, assuming it can work given the
"write() doesn't block" issue above. But I'm not quite sure what you
mean -- do you mean using select on the audio file descriptor with a
really short timeout? I'll try this, if it works it (i.e. if it gives
waiting SCHED_OTHER tasks the opportunity to run) it would be perfect.

[sbenno_AT_gardena.net]

> The fun starts when you enter an infinite loop.
> At this point you are screwed.

This is especially an issue because it's not my code that would
have the infinite loop -- it would be SAOL code users write, which
could very easily have an infinite while loop in it, and short of
solving the halting problem, sfront couldn't really catch the problem
during compilation in the general case :-).

> One way to avoid this would be to let your app start a 2nd thread which
> runs with higher SCHED_FIFO priority than the main thread.

Good idea, I'll do this -- since the C code sfront produces is a
single thread (the core code block sfront generates is strict ANSI C,
so that Windows folk can run it as a batch program -- the
machine-specific code gets included in the generated code as "driver
code" inserted into the C file, and having this driver code spawn
threads would require a lot of rewriting), so it would be a watchdog
process, which will probably use signals for watchdog communication.

> PS: sorry for my ignorance what is the exact purpose/application field of
> sfront ? let's say you have an MP4 file which describes an audio file.
> You pipe it through sfront, get a C file , compile it, and then
> running the C program you get the original audio file ?
> Is that the purpose ? (correct me if I am wrong)

That's the idea in a nutshell.

> But that will not be suitable for realtime decoded streams like in the
> case of an MP3 player.

You have three choices:

[1] MP4-SA players get rated to have a particular "Level" of CPU. As
a server you query the client, see its Level, and send a SAOL program
that is simple enough that it can safely run on the machine open loop.
See:

http://lsiwww.epfl.ch/saog/forum/SA_conf.pdf

part 5 for a draft of how these levels get specified.

[2] SAOL has a variable called cpuload, that ranges from 0.0 to 1.0,
and that changes each control cycle. 1.0 means "the CPU is completely
loaded, and any more work risks real-time data problems" and 0.0 means
"the CPU is totally unloaded". So, SAOL programs can dynamically vary
its computation to not overrun. The sfront currently in release doesn't
have a working cpuload, but while I was fixing the bugs in the Linux
driver I also added in cpuload support, so the next release should support
it.

[3] The SAOL decoder itself (in sfront's case, the sa.c file it creates)
can be written in such a way that it monitors cpuload and other factors,
and decides when a "normative" decoding of the audio is simply impossible
because there's no more CPU. It then could start doing the sorts of
tricks real-time audio synths do in this case (dropping notes, degrading
synthesis, ect), to make a "best effort" to keep things alive. Sfront
doesn't do this right now either, but probably will in a few releases,
at least in a limited way.

So, that's the big picture -- I've been way too busy to code up an MP3
decoder in SAOL, and test out if it could really handle it in real-time,
but intuitively I think its not impossible that it could, if not with
today's hardware then in a year or two (or alternatively, with better
code generation out of sfront).

---

Thanks again for the replies ...

--john lazzaro

------------------------------------------------------------------------- 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 : Sat Jun 10 2000 - 03:47:18 EEST