Re: Why are sound ioctl calls so slow?

[Drop my IPv6 address for any replies or hostname-only for IPv4...]
[Sorry for replying to more than a week-old message, but I'm catching
 up from the archives, with the risk there's been more replies over
 the last week that I haven't seen...]

In the beginning, it was written...

> On Tue, Dec 09, 2003 at 02:25:57PM -0500, Mathew Kanner wrote:

> > 	My first guess would be the device is rebuilding feeder/mixer
> > chains every time mpg123 changes format.  I would run the test one
> > more time, disabling vchans and rate conversion.

> FWIW, I see this too, without vchans enabled - this problem has
> existed for a long time (over a year).  In fact it was the catalyst
> for me to stop using mpg123 (in favour of madplay, which seems to be
> generally better anyway).

Yeah, I'm not using -current, but at least FreeBSD-4 has some sound
issues I'll describe that may well be applicable to -current as well.
Allow me to toss in some more possibly-interesting info based on 4.x,
with apologies if it no longer applies to -current, but I suspect does,
given the mpg123-startup problem.

I only recently tried using `mpg123' on a machine slow enough for me
to go downstairs and fetch the paper before audio would start to play.
I'd switched all my recordings over to ogg vorbis quite some time ago,
so I had forgotten about this.

My reference is NetBSD from more than a year ago, which does not have
the described audio problems, nor does it have any delay at start of
mpg123.  Whether the soundcards in question are ISA or PCI makes no
difference to FreeBSD.  To be fair, the NetBSD audio code is rather
different than FreeBSD's, compared to, say, the USB code, so finger-
pointing at my hardware can be rebutted with .. but it works under
windows!! .. I mean netbsd!!

Probably few people observe this, because audio device open()/close()/
ioctl()s affect the other sound devices, and most users probably have
a single card, while I've had three when I was investigating this.
In particular, when playing back audio on one card, starting or ending
a recording from a different card would put a fraction of a second of
looping audio playback into the output stream (as if the audio buffer
in the playback card could not be refreshed during that time).  Likewise
starting or stopping a second playback would do the same brief looping.

Comparably, when making a recording, and then starting or ending audio
recording or playback on a different card would result in a skip of the
recorded audio by a fraction of a second each time.  (So, too, could
heavy disk activity on my machines, or any disk activity with the stupid
CMD640 controller I'm now plagued with having.)

I tried adding small sleep()s in the recording program along with some
debugging at every open()/close()/ioctl() to see which one(s) were
causing problems with other active audio devices.  This showed me that
both open() and close(), and if I remember right, the set-speed and
set-format ioctl()s, at least, caused problems with other devices.

I had never been aware of this problem with NetBSD, and indeed, reverting
to that for making my recordings and testing heavily showed no such
problems.  Other issues of performance and periodic problems when
recording simultaneously from two cards (that has never been a problem
recently under FreeBSD 4; I've just heard this problem in many-year-old
recordings I made that unfortunately I no longer remember if they were
made with NetBSD or FreeBSD 3.x ...), made me return to FreeBSD with a
workaround.

The FreeBSD 4.x workaround I have to avoid skips in recorded audio on
my slow machines (75-120MHz pentia) is, in addition to not doing any
playback (or disk activity with the stupid CMD640) during recordings,
when I make overlapping recordings, to open() and set the ioctls for
both audio devices before the time windows of the recordings, then if
needed sleep until the recording starts, and again, sleep at the end
of the recording if needed before closing the audio devices.

For fun, I should fire up a several-year-old FreeBSD stable disk and
see if the mpg123 problem persists, and because the open() and ioctl()
functions are so problematic for me, see how 3.x and earlier 4.x
behave to see if a downgrade would help me (perhaps slightly speeding
up other CPU-bound activities -- I know my year-plus-old 5.x showed
worse performance creating mpeg or ogg vorbis files, as did netbsd,
compared to the reference 4.7-ish).

A quick look at the kernel source did not reveal any clues why these
operations would monopolize the machine.  Not surprising, with the lack
of clue I personally possess.

Once again, this looping/skipping behaviour seems only a concern with
multiple sound cards in a machine, regardless of type/make, while the
mpg123 behaviour (also not present with ogg123) can be seen by anyone.
NetBSD (with a very different sound infrastructure) does not exhibit
the mpg123 problem, although I no longer recall if a `truss' equivalent
showed similar activity -- or if I even tried one.

Hope this information is useful, and relevant to -current also...
Otherwise, sorry for the noise that should have been directed to
multimedia or elsewhere...


thanks
barry bouwsma