Re: esound and playing mp3's ?

Back on topic guys, and RTFM mark II...

Rather than running every other program through esd and moaning about possible 
latency, try starting it as "esd -as 2" instead - either/or will do.

This tells esd to let go off the sound port if it's not been asked to do 
anything in the last 2 seconds.  2 is my own taste, chose your own if you wish.

Thus, all my old scripts and apps that try to play sounds when they do something 
still work.  I still hear "Yeah, thanks" (Chris Morris, for the Brits out there 
who know who he is) when I get email.  At *worst* this is 2 seconds behind when 
it should have played *if* I was messing with something that asked esd to play a 
sample at the exact same moment.  I wouldn't be doing that if I was playing 
Quake (I *don't* do that while I'm playing quake - the other guys here frag me 
too often when I'm *concentrating*), so I hear no latency or lag.



-------My opinion - Not sane, intelligent or necessarily useful-------
o o                             
/v\ark R. Bowyer.  mailto:Mark.Bowyer@UK.Sun.COM
`-'                                             I'm the dots in

>Date: Sat, 9 Jan 1999 18:26:25 -0500 (EST)
>Subject: Re: esound and playing mp3's ?
>X-just-a-test: testing
>On  9 Jan, R Pickett scribbled:
>->  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' 
>->  programs.  The entire concept that a single daemon is going to grab my 
>->  hardware and only allow access to esd-compliant programs seems very 
>->  to the goals of OpenSource;  it's a very "my way or the highway" attitude 
>incorrect. RTFM pay attention.
>esddsp app_name
>ooh wow it works via esd now
>esddsp x11amp
>ooh it works via sed now
>esddsp blahblah
>donest work with everything but works with quiet a few standard audio
>there's ALSO 
>esdctl off
>esdctl on
>where esd will respectively release its hold on /dev/dsp and the regain
>it if it can.
>->  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 
>->  a process or doing CLI piping.  Speaking of which....
>why? there will just be a tiny wrapper scritp to run realaudio under
>esd - it works here.
>esddsp rvplayer
>need i say more.
>->  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- 
>->  OpenSource- based music tools, and my target audience will not be tolerant 
>->  extra overhead, no matter how small, between producing sound and hearing 
>->  And so, esd isn't even on the map for mentioning in this series, unless it 
>->  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 
>->  done.
>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.
>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.
>->  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 
>->  and then let go once it's done.  That would also allow for on-the-fly 
>->  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 
>->  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 
>->  topic).  Given that esd could have the grab-and-release capability 
>->  in the previous paragraph, couldn't it also be written simply to grab the 
>->  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 
>->  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 
>->  have just the consumer soundcards with the one hardware output, where tens 
>->  milliseconds of overhead is acceptable.
>->  Just a few thoughts -- I'm meeting with my co-writer for these articles 
>->  afternoon, so this stuff is strongly on my mind.  I'd like to talk to some 
>->  the esd people off-line, if they're interested...
>->  Thanks for listening to my mostly off-topic rant.
>--------------- Codito, ergo sum - "I code, therefore I am" 
>       /\___ /\ ___/||\___ ____/|/\___
>Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
>218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
>Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 
>+1 (919) 929 9443, 801 4392   For pure Enlightenment
>              \|/ ____ \|/  For those of you unaware. This face here is in fact
>	      "@'/ ,. \@"   a Linux Kernel Error Message.
>	      /_| \__/ |_\
>		 \__U_/
>        FAQ: Frequently-Asked Questions at
>         To unsubscribe: mail with 
>                       "unsubscribe" as the Subject.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]