Re: esound and playing mp3's ?

[R Pickett <emerson hayseed net>]

On Sat, 9 Jan 1999, Michael Johnson wrote:

> It's really sad to have to kill esd to play an mp3 and then restart
> it when you're finished as I think the whole point of having a sound
> daemon was to not have to do this. 

Ah, a topic near and dear to my heart.

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;  it's a very "my way or the highway" attitude for
a program to take.  It's also going to hinder Gnome acceptance in the
short-term -- 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.  Speaking of which....

esdcat is a kludge of the worst degree.  Having to pipe my audio through a
second process just to hear it is not acceptable.  I'm in the process of
writing a series of articles for Electronic Musician magazine about Linux- and
OpenSource- based music tools, and my target audience will not be tolerant of
extra overhead, no matter how small, between producing sound and hearing it.
And so, esd isn't even on the map for mentioning in this series, unless it is
to say that Gnome is shaping up to be very nice except don't run the sound
daemon if you want to get professional sound design or music production work
done.


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.  That would also allow for on-the-fly sample
rate and bit depth handling without conversion, since esd could re-config
/dev/dspX at each grab.  And non-enlightened programs could do their thing in
the meantime.

Also, I run the commercial version of OSS, with the SoftMix capability -- I
have /dev/dsp0 - /dev/dsp15, each of which can be opened and utilized
concurrently with the others, and will be mixed on-the-fly by the kernel
module (where this kind of capability belongs, IMHO, but that's not really my
topic).  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?
THAT would be a useful tool, since currently, the end-user or the OSS-based
program has to keep tabs on the currently-used /dev/dsp's and pick an unused
one by hand.  For those of us using some of the OSS hardware drivers for
profesional audio hardware, esd would then become a VERY thin audio-out
manager, which is something that the various OpenSource audio systems are
SORELY lacking.  And then provide its own mixing and the like for folks that
have just the consumer soundcards with the one hardware output, where tens of
milliseconds of overhead is acceptable.

Just a few thoughts -- I'm meeting with my co-writer for these articles this
afternoon, so this stuff is strongly on my mind.  I'd like to talk to some of
the esd people off-line, if they're interested...

Thanks for listening to my mostly off-topic rant.

-- 
----------------------------------------------------------------
R Pickett                Look around you. This is what the world
emerson@hayseed.net      looks like at the end of the millenium.
----------------------------------------------------------------