Re: esound and playing mp3's ?

[raster redhat com]

On  9 Jan, R Pickett scribbled:
->  On Sat, 9 Jan 1999 raster@redhat.com wrote:
->  
->  > incorrect. RTFM pay attention.
->  > 
->  > esddsp app_name
->  > 
->  > ooh wow it works via esd now
->  > 
->  > esddsp x11amp
->  > 
->  > ooh it works via sed now
->  > 
->  > esddsp blahblah
->  > 
->  > humpf
->  > 
->  > donest work with everything but works with quiet a few standard audio
->  > apps.
->  
->  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.

it works with apps that done mmap() the /dev/dsp device (ie quake,
quske2 and a few games). esd does not have the equivalent of an mmap
api (if it did it woudl be an mit-shm mem segment that acts just like
am mmap of /dev/dsp thus esddsp could intercept this too and make the
app use esd's mit-shm api instead of mmaping the device).

->  > there's ALSO 
->  > esdctl off
->  > esdctl on
->  > where esd will respectively release its hold on /dev/dsp and the regain
->  > it if it can.
->  
->  And again I ask, why doesn't it do this automagically, since it has this
->  capability?

because most /dev/dsp apps (x11amp etc.) open the device then HOG them
too whislt they are playing or longer - esd is unable to get the device
back and will sit there and spin trying to get it back or give up and
not play a sound.

->  > why? there will just be a tiny wrapper scritp to run realaudio under
->  > esd - it works here.
->  > 
->  > esddsp rvplayer
->  > 
->  > need i say more.
->  
->  Yes.  What about third-party programs, installed via RPMs or the like, that
->  don't supply such a wrapper sscript?

esd has provided esddsp - it IS a wrapper script. Any distribution
suppling gnome + esd etc. can automatically make all apps BE a wrapper
script that simply does:

#!/bin/sh
# wrapper scritp for rvplayer called rvplayer (and rvplayer bnary
# renamed rvplayer.bin)
esddsp rvplayer/bin $@

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

for now its a problem due to the fact not everyone plays nice yet - in
future they will - its called growin pains - svgalib apps dont work in
X - people had to port them. same with esd.

->  > well if apps were written well and latency was an issue they coudl
->  > happily upload samples to esd then tell esd to play then as needed.
->  
->  And now we're back to 'you must be esd-compliant or else you face lesser
->  performance.'  Not OK.

same with any new api or daemon or anything. you can chose nto to run
esd - libesd if it cannot find esd falls back to opening /dev/dsp so
the esd apps plays nice and falls back. you have the freedom. you dont
lose. you chose.

->  > esd is not finished - give it a break boy! do you think they developed
->  > X11 in a year? esd is the correct principle - it is the sampel
->  > rpinciple by whihc X works - you dont seem to complain about this. If
->  > you have issues then HELP wiht development. Dont' just sit and complain.
->  
->  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 think you're taking my criticism of the current paradigm a little bit
->  personally.  My interest, both in this mail, and in the articles I'm workings

no - people keep bashing esd simply out of ignorance and I really get
sick of that. If yoou are to make comments good or bad about somehting
research it first and knwo EXACTLY what you are talking about -
otherwise expect to be flamed by those who do know whats going on.

->  on, is to try to leverage OpenSource platforms into the professional musics
->  production industry, a market they are conspicuously missing out on, currently.
->  If my comments on esd are not welcome feedback, I can write it off completely,
->  and only work with applications that speak directly to OSS or ALSA.

whihc is like writing apps that speak directly to the framebuffer and
not via X. in the end those apps will be cut out and removed from the
food chain. Writing an esd complient app as opposed to a /dev/dsp using
one is trivial - see my slashdot post on "porting /dev/dsp apps to esd"
its childs-play.

->  I doubt you remember this, Raster, but you and I discussed the idea of a sound
->  daemon for E on #e, months before esd became a reality.  I was interested at
->  the time, and continue to be interested, in helping produce an OpenSource
->  sound system with the power and flexibility of some of the high-end audio
->  engines currently in the professional audio industry, like Digidesign or Sonic
->  Solutions' offerings.  At the time, your reply, parahrased, was that you were
->  a graphic artist and an X hacker, and sound wasn't your area of expertise.

it still isn't - but I know enough to get by. i have done my share of
sound coding form the Amiga to linux. I wrote a first pass at a sockets
based sound daemon myself for E. esd uses the same principles. Its
latency issues are ones of non realtime OS and buffering in sockets and
its mixing engine - the principle behind ESd is still good -
some implimentation issues are still around.

->  And when a sound daemon did appear for E, it has ended up being much more
->  analogous to Windows' old MMSYSTEM than to DAE.  This is great for playing
->  kewl sounds in response to program events, and even for things like streaming
->  audio and other consumer-level multimedia tasks.  But for film and audio work,
->  where audio has to be synchronized at the sample level, this is not
->  acceptable.

and this still has to be addressed - and over time it will be - ricdude
who maintains and writes esd does it in his spare time mostly on his
own wiht help form yosh who did esddsp and a few others - they do it
when they have a bit of time for fun. They listen - I have doen one or
two things to esd myself in an attempt to reduce latency. The real
solution for that is 1. for esd to mmap() the audio device if possible,
and to gain an mit-shm like api for mimicking of mmap()'ing of /dev/dsp
- this could then go thorugh an attempt at a low-latency mixing engine
just like the oss audio device does down at the driver level (though
it's commercial)

->  And so, once again, I'm offering my 5+ years' expertise as a tester for Opcode
->  Systems and Digidesign to provide feedback and guidance to help OpenSource
->  platforms move toward being usable, and eventually preferred, in the
->  professional audio production market.  I'm glad to speak to any developer
->  who's interested in working toward this goal.  I would think that the Gnome
->  project would have an interest in this, especially for nominally-professional
->  tools like Audiotechque that are in development.

we do - but we dont have time to impliment everything. i understand
everything you say - I actually had my hand at writing games for a
while on the amiga nd understand the issues involved -0 you need as
close to zero latency between soudn mix and sound out of speakers as
possible. thats it - raw "as close to zero latency" as posbile wiht
minimal overhead. mit-shm shared mem segments to esd form clients who
wish to deal with zero latency is the answer. it is then up to the
kernel to schedule processes like esd often enough so they can suck off
the app's buffer and mix wiht whatvere else is happening and dump itnot
eh audio devices buffer within a mater of > 1/50th of a second (whihch
is about the latency tolerable for the human audio/visual system to be
able to still keep audio and video together perceptually)

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

we woudl LIKE to. I know ricdude WANTS to - it's just a lack of time
and / or developers to do it. esd is evolving. All I'm saying is give
the developers a break and offer friendly advice then be patient.

I'ma skign anyone who undrestands what I'm talkign about wiht shmem
segments, mmaping()/dev/dsp etc. to please contribute such an api to
esd - esd is open to developemtn, addition and appending always. if you
as an aduio programmer need somehting and decide to go direct to the
drivers for the soudn card - so be it.. but if you want to actually be
nice to EVERYONE - every app developer, every app trying to make noises
etc, think abotu abstracting your api and putting it down into esd
instead and adding a protocol api to it and libesd api call so EVERYONE
can use your wonderful low-latency api to the sound device. That way
your work doesn't go to waste.

if I didnt have an imagelib to rewrite, a WM to write, a few tutitlies
and apps to maintain etc. I'd liek to take time out to look into it
myself - I really would, and I may eventually wne I have less on my
plate to do - but either ricdude does it, I add it, or someone else
wiht time on their hands can add it now whislt evereyone else is busy.

if those developers are interested in adding such abilities to esd,
please, talk to Mr Pickett - get some ideas and requirements list and
then sit down and code it.

->  I'm done, now, no more long rants like this in public, unless the rest of the
->  Gnome group is actually more interested in this topic than it would seem.
->  Private replies welcome.


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/