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.

Solution?

Ta,

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

>From: raster@redhat.com
>Date: Sat, 9 Jan 1999 18:26:25 -0500 (EST)
>Subject: Re: esound and playing mp3's ?
>To: emerson@hayseed.net
>cc: hekate@intergate.bc.ca, phrog@cmn.net, gnome-list@gnome.org
>Resent-From: gnome-list@gnome.org
>X-just-a-test: testing
>X-URL: http://www.gnome.org
>
>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' 
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
>
>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.
>
>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 
killing
>->  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- 
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.
>
>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 
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.
>->  
>
>-- 
>--------------- 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_/
>							   
>
>
>-- 
>        FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>         To unsubscribe: mail gnome-list-request@gnome.org with 
>                       "unsubscribe" as the Subject.
>



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