Re: From the Horse's Mouth (long) - Was: esound and playing mp3's

["Yo 'Ric Dude" <ericmit ix netcom com>]

R Pickett, over the course of the last day has let it be known:

> I don't run esd, simple because I mostly run 'un-enlightened'
> sound-producing programs.  The entire concept that a single daemon
> is going to grab my sound hardware and only allow access to
> esd-compliant programs seems very contrary to the goals of
> OpenSource;

Many programs work with the esddsp wrapper script. xanim, x11amp,
xwave, rvplayer among others.  If you're running one of them without
esd, you won't hear any other sounds either.  X is a daemon that grabs
your video hardware and only allows access to X-compliant apps.  But
if you need an svgalib console, you can switch VTs.  Likewise, "esdctl
off" can be used to allow other apps access to the audio device.

Also, esd now has an "auto suspend" feature that will release the
sound hardware after a period of inactivity: esd -as TIMEOUT, where
TIMEOUT is number of seconds after which to free the audio device,
TIMEOUT > 0.  You get gnome/esd noises when they're playing, you can
hog the audio device with another program when they aren't.


> try telling the newbie, that's just installed his Gnome-containing
> distribution, that he can't run his RealAudio without killing a
> process or doing CLI piping.

RealPlayer.desktop: Exec=esddsp rvplayer

I'll know that esd is pretty darned "there" when a distro can do this.
Not quite there yet, but i'm working on it.


> esdcat is a kludge of the worst degree.  Having to pipe my audio
> through a second process just to hear it is not acceptable.

Agreed. It's not really designed as something the average end-user
would have to use.  It's more of a diagnostic tool and basic utility
than anything else.


> I'm in the process of writing a series of articles for Electronic
> Musician magazine ... my target audience will not be tolerant of
> extra overhead ... between producing sound and hearing it

esdctl off ; use the fancy audio editing tools ; esdctl on

However, keep in mind that esd allows networked connections, too, so
an esd-compatible program could edit on one machine, and play back to
another one.  It's not just an audio hog, it's a network hog, too. =)


> One simple thought that comes to mind; it would seem that it would
> be easy enough to write esd to grab /dev/dspX only when there's a
> sound to be played, and then let go once it's done

It's as easy as using the auto-suspend feature: "esd -as 1"


> Given that esd could have the grab-and-release capability discussed
> in the previous paragraph, couldn't it also be written simply to
> grab the next available /dev/dspX and blat directly to it without
> any further processing

Only works on Linux.  esd is known to run on Solaris, HPUX, IRIX, BSD,
maybe even more.  However, you could specify a specific audio device
to use on the command line: "esd -d /dev/dsp10". If the OSS SoftMix
stuff is in the kernel already, it should be intelligent enough to
route you to an open /dev/dspX if /dev/dsp is already taken.


> I'd like to talk to some of the esd people off-line, if they're
> interested...

I'm esd people, and i'm interested.  =) Reply at your convenience.


> Is the fact that it doesn't work with everything esd's fault, or
> those apps' fault?  I'm not being snitty, here, this is an actual
> question I'd like enlightenment (pun intended) on.  If this is a
> temporary solution that works with all correctly-written OSS apps,
> that's a good thing.  Although it's still esd imposing its rules on
> the rest of the universe.

esddsp does not emulate memory mapping of the sound card dma buffers.
As far as I know, this is only a problem with quake and quake2.
It works on *most* other basic audio apps.  It's possible to make
esddsp emulate memory mapping via shared memory, but would be tricky.


> And again I ask, why doesn't it do this automagically, since it has
> this capability?

It's in there, "esd -as 1" (one second timeout)


> What about third-party programs, installed via RPMs or the like,
> that don't supply such a wrapper script?

They won't play nice with any other audio programs, either.
"Why don't I get audio ICQ notifications when I'm playing mp3s?"


> Again, I maintain, esd must play nice, automatically, with
> non-esd-compliant apps, or else people will not use it.  The burden
> should not be on each application's author to provide a way to
> coexist with esd.

esd plays as nice as it can within the confines of a single audio
device.  Those limitations are outside the ability of esd to alter.


> Last I checked, non-coding individuals discussing the needs of the
> end-user with developers DID constitute helping with development.  I
> still await input on the other half of my mail, the part that
> offered solutions and suggestions to the 'complaints' I was making.

I checked my EsounD mail archives, and didn't come across anything
from you.  I urge you to check resources like the AUTHORS file, and
the ChangeLog, which is the best place to check for new features.


> But for film and audio work, where audio has to be synchronized at
> the sample level, this is not acceptable.

For that level of use (not average end-user), you would either want
something that directly supports esd, or you would want direct memory
mapping capability; i.e. take total control of the sound card.  You
probably aren't concerned about catching an icq audio notification in
the middle of your audio editing work, so esd would not be an
appropriate tool for the job.  I don't think *anything* that sat
between an application like that and the dma buffers would be acceptable.


> But if this is not a direction the authors of esd are interested in
> taking it, there are more polite ways of telling me.

I'm always open to suggestions, but it also helps if it's "esd would
be so much more useful if it were capable of ..." instead of "I refuse
to use esd until it is capable of ..." =)


> DMA: Hmn.  I don't know about that.  If that's the case, there
> _ought _ to be a workaround (dwiddle the mixer volume for a few
> dozen nanoseconds while you init DMA or the like), but I'm not
> enough of a coder to know for sure.

Oooh a Hamming window, or Hanning window, or raised cosine, or
whatever. Too computationally expensive to worry about.  Also, if you
tweak the mixer level like that, you're just as likely to introduce
clicking.  Try it with the mixer_applet.  The clicking is probably just
a poorly recorded sample starting and stopping. Any abrupt jump in
volume (e.g. zero to something big) will result in a click.


> The original context of this paragraph was the newbie who installs
> his distribution that defaults to esd, and then installs some
> non-esd-compliant program from RPM, say.  And it doesn't work, and
> said newbie doesn't know or care to know about workarounds, command
> lines, or scripts.  And can't spell FAQ.  Don't think it won't
> happeni, more and more....

If the newbies can't spell FAQ, they've got bigger problems than
whether or not their non-esd-compliant apps work. =)


> > You must be esd-compliant or face lesser performance or not use
> > esd.

> (*nod)  Right, exactly.  Which is the least of the three evils?

I've attempted to get esd to play as nice as possible with other apps.
esdctl off/on for the duration of the "real" work, is probably the best
bet under this situation.


> 'Small' is a relative term.  I don't have any actual numbers on esd,
> so my comparison to MMSYSTEM may be less than fair (or may not be),
> but for professional applications, sample-level synchronization is a
> sine qua non.  1/44100 or 1/48000 of a second is the MAXIMUM, and
> higher-end audio is now running at 96K sample rates, so 1/96000 of a
> second will soon be the maximum latency.  That's about 100
> microseconds, for those of you keeping score at home...  ;-) So, a
> 10ms delay between trying to play a sound and hearing it is roughly
> two orders of magnitude too long.  For comparison's sake, MMSYSTEM
> originally could only guarantee a maximum _250_ ms latency -- up to
> 1/4 second.

IIRC, the human ear is only accurate to 5-10 ms, anyway, but...
The right tool for the job.  That's always the answer. Esd is a tool
for allowing mutiple audio apps to share a sound card, and to the
extent possible, that support is transparent.  It's there to allow you
to play sounds on one machine and listen on another.  Esd's latency is
on the order of 1/10 of a second.  It's acceptable for audio feedback
from GUI apps.  It's acceptable for most simple games.  Quake needs
more.  Synchronizing Audio/Video editing requires more.  Esd is not
necessarily the right tool for every job.  But for the average desktop
user, I think it's a useful tool.  And it may get there yet... =)


> Reducing your statement to its logical conclusion, we get "don't
> comment on a product to the developers until they announce it is
> finished," since anything but 'grate softwarez d00d' could be
> construed as 'judgment.'

Personally, I'm always up for *constructive* criticism.  I'm not an
elitist "you don't code, therefore you can't comment" type.  

> Jeez, folks, is it really that for this project, you can only make
> critical comment if you can offer a patch to fix it?  I was hoping
> to help out in what ways I could, but it's starting to look like my
> type of help ain't welcome here....

One more reason to check the AUTHORS file, and direct your inquiries
there. =) The authors are typically more receptive to constructive
criticism and feedback.  Sometimes the mailing lists tend to be havens
for flame-bait, and religious defenses of irrelevant positions.


In conclusion, I'd like to say

1) thanks for the feedback
2) sorry I couldn't help sooner
3) be sure to check the AUTHORS file if you have comments/suggestions 
4) check the ChangeLog and available documentation for new features
5) "esd -as 1", to free the audio device after one second of inactivity
6) you probably don't want to use esd for A/V editing.  yet. =)

Take care,

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ 
|  __                        a.k.a. Eric B. Mitchell  | 
|  |_) .  _  _|      _|  _     ericmit@ix.netcom.com  | 
|  | \ ( (_ (_| (_| (_| (/_  www.netcom.com/~ericmit  | 
|  How's My Programming?  Call: 1 - 800 - DEV - NULL  |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+