6:10 a.m.
I guess this will be the standard sound daemon soon ;)
Is someone willing to make a package for this ?
http://www.freedesktop.org/Software/Home
PS: HAL 0.2 is released
Lupus (Kristof Vansant)
6:27 a.m.
Kristof vansant wrote:
I guess this will be the standard sound daemon soon ;)
Is someone willing to make a package for this ?
http://www.freedesktop.org/Software/Home
PS: HAL 0.2 is released
Lupus (Kristof Vansant)
"None of this is "endorsed" by anyone or implied to be standard
software, remember that freedesktop.org is a collaboration forum, so
anyone is encouraged to host stuff here if it's on-topic."
I assume this means that they are giving MAS a chance to get more
exposure in the Open Source community. We all agree that a unified
sound daemon is crucial for our eventual world domination, but there are
competing implementations like gstreamer that already have heavy backing
and momentum from many of the same people who make our software (like
GNOME). It worries me if the KDE folks would accept a gstreamer
standard... if only for the emotional reason of it beginning with 'g'.
In reality I personally know nothing about the technical correctness,
completeness, license compatibility, or overall viability of any of the
options. All I know is that multiple and incompatible standards are
HURTING us. The current esd vs arts situation is poor, and we need a
better unified solution if we are ever to win.
Warren
9:56 a.m.
On December 24, 2003 07:27, Warren Togami wrote:
I assume this means that they are giving MAS a chance to get more
exposure in the Open Source community. We all agree that a unified
sound daemon is crucial for our eventual world domination, but there are
competing implementations like gstreamer that already have heavy backing
and momentum from many of the same people who make our software (like
GNOME). It worries me if the KDE folks would accept a gstreamer
standard... if only for the emotional reason of it beginning with 'g'.
We KDE folks have (and love) arts, so the process of integrating and
standardizing MAS begins in a bad shape...
In reality I personally know nothing about the technical
correctness,
completeness, license compatibility, or overall viability of any of the
options. All I know is that multiple and incompatible standards are
HURTING us. The current esd vs arts situation is poor, and we need a
better unified solution if we are ever to win.
I don't think unification is going to win us anything.
...my 2CDN¢...
--
Simon Perreault <nomis80(a)nomis80.org>
http://nomis80.org
"If voting could really change things, it would be illegal."
--Excerpt from a Diebold Election Systems internal memo.
1 p.m.
On Wed, 2003-12-24 at 07:56, Simon Perreault wrote:
On December 24, 2003 07:27, Warren Togami wrote:
> I assume this means that they are giving MAS a chance to get more
> exposure in the Open Source community. We all agree that a unified
> sound daemon is crucial for our eventual world domination, but there are
> competing implementations like gstreamer that already have heavy backing
> and momentum from many of the same people who make our software (like
> GNOME). It worries me if the KDE folks would accept a gstreamer
> standard... if only for the emotional reason of it beginning with 'g'.
We KDE folks have (and love) arts, so the process of integrating and
standardizing MAS begins in a bad shape...
Admittedly, I don't use KDE but my general impression of the "KDE folks"
feelings towards arts is not good. Yes, it's better than esd. That's
not saying much. Currently, both KDE and GNOME have *unmaintained*
sound daemons, neither of which is very good. And, while the search for
a replacement is not active, it is generally recognized by both camps
that a replacement is needed. Hopefully MAS or Jack can fill this role.
As to unification not "going to win us anything"... obviously you've
never used the excellent K12LTSP (check out the RedHat channel today
;-P). Sound is a PITA, thankfully Eric Harrison and Jim McQuillan have
done most of the hard work but some things still don't work right
(*especially with arts!*). Of the three "supported" options (NAS, ESD,
arts) esd is definitely the most stable (not saying much) and the sheer
volume of dependencies makes arts almost unusable for this situation.
Every meg you have to transfer to your thin clients (NFS root
directories, obviously) makes a difference and in order to run arts you
need a ridiculous number of libraries (not to mention a ridiculously
convoluted setup for something that is supposedly "network
transparent"). ESD requires less than half as many libraries as arts.
And that makes a huge difference.
The above paragraph was written under the assumption that Eric or Jim
have gotten arts to work at all, which may or may not actually be the
case.
--
Shahms King <shahms(a)shahms.com>
2:12 p.m.
One thing to note here: gnome uses esd but gnome's internal sound api (such as
it is) doesn't expose any esd functionality, although IMHO its missing an
accessibility hook. Sounds really need to come with a textual description where
relevant and classification information so the API really needs to look more
like
make_noise(SOUND_INFO, "postman-whizz.wav", "You have new mail");
because we want to deal with users who can't hear said audio, whether due
to physical problems or more basic things like working in a quiet office / not
having speakers.
Does MAS deal with accessibility issues ?
Alan
2:28 p.m.
Shahms King wrote:
(*especially with arts!*). Of the three "supported"
options (NAS, ESD,
arts) esd is definitely the most stable (not saying much) and the sheer
"I don't know why and I'm not yet motivated to fix it since my views on
esd are mostly unprintable."
- Alan Cox (currently at the top of http://www.xmms.org
"esound is junk. The only thing esd has is a good client API for going
boing at approximately the right time. Anything else is beyond it."
- Alan Cox (used to be on xmms.org)
Alan, is this still true? I've been always about why specifically these
quotes were there. (Yes it seems to me that esd has always been
problematic, and I am equally unhappy about arts, but I don't know
anything about the technical reasons.)
Warren
4:08 p.m.
On Wed, Dec 24, 2003 at 10:28:27AM -1000, Warren Togami wrote:
Alan, is this still true? I've been always about why
specifically these
quotes were there. (Yes it seems to me that esd has always been
problematic, and I am equally unhappy about arts, but I don't know
anything about the technical reasons.)
esd has (or had at least - I've not looked for a long time) big problems with
how it processed audio. It has very bad mixing and rate adaption code for example
which can be problematic. It also has no synchronization API with X11 and no
good general synchronization facility.
Technically artsd is much better in these areas at least.
Alan
11:16 a.m.
On Wed, 24 Dec 2003 02:27:32 -1000, you wrote:
I assume this means that they are giving MAS a chance to get more
exposure in the Open Source community. We all agree that a unified
sound daemon is crucial for our eventual world domination, but there are
competing implementations like gstreamer that already have heavy backing
From the gstreamer FAQ
http://gstreamer.net/docs/cvs/faq/html/chapter-general.html
Q:
Is GStreamer a sound server ?
A:
No, GStreamer is not a soundserver. GStreamer does however have
plugins supporting most of the major soundservers available today,
including ESD, aRTSd, and to some extent Jack. Support for MAS is also
planned.
Therefore there is no reason both Gnome and KDE couldn't move to MAS
if MAS will do the job that esd/arts currently do.
12:27 p.m.
Looking at the MAS site, it's not obvious whether it uses the DISPLAY
variable. Though it does talk a lot about it's integration with X.
If it *does* use the display variable, that would be reason enough in
itself to use it instead of esd and arts.
The first question remote desktop users ask me is why their speakers
don't work. It's embarrassing to have to say that it's because we're
using Linux. I've taken to avoiding the whole subject by not even
taking them out of the box.
12:31 p.m.
On Wed, 24 Dec 2003 12:27:22 -0600
Steve Bergman <steve(a)rueb.com> wrote:
The first question remote desktop users ask me is why their speakers
don't work. It's embarrassing to have to say that it's because we're
using Linux. I've taken to avoiding the whole subject by not even
taking them out of the box.
I'm not sure i follow you, are you saying you can't get remote sound to
work? You know that's possible right?
Sean
12:39 p.m.
On Wed, 2003-12-24 at 12:31, Sean Estabrooks wrote:
I'm not sure i follow you, are you saying you can't get
remote sound to
work? You know that's possible right?
I know it can be done. But is there a really "clean" way of doing it
that does not involve messing with every single application that uses
sound for every user on the system?
export DISPLAY=192.168.4.23:0
would be oh so much better.
12:45 p.m.
On Wed, 24 Dec 2003 12:39:12 -0600
Steve Bergman <steve(a)rueb.com> wrote:
On Wed, 2003-12-24 at 12:31, Sean Estabrooks wrote:
> I'm not sure i follow you, are you saying you can't get remote sound
> to
> work? You know that's possible right?
>
I know it can be done. But is there a really "clean" way of doing it
that does not involve messing with every single application that uses
sound for every user on the system?
export DISPLAY=192.168.4.23:0
would be oh so much better.
No need to change any application. There is more than one method but
running the esd sound daemon on the server works easily. You'll have to
configure it to accept network connections but that's a snap. Try it
out so you don't have to blame Linux anymore ;o)
HTH,
Sean
1:53 p.m.
On Dec 24, 2003, Steve Bergman <steve(a)rueb.com> wrote:
I know it can be done. But is there a really "clean" way
of doing it
that does not involve messing with every single application that uses
sound for every user on the system?
export DISPLAY=192.168.4.23:0
would be oh so much better.
Even better would be something that actually tunneled sound through
the X protocol, such that even if all you have is
DISPLAY=localhost:10.0 (set by ssh), it still works.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
1:58 p.m.
On Wed, 2003-12-24 at 12:53, Alexandre Oliva wrote:
On Dec 24, 2003, Steve Bergman <steve(a)rueb.com> wrote:
> I know it can be done. But is there a really "clean" way of doing it
> that does not involve messing with every single application that uses
> sound for every user on the system?
> export DISPLAY=192.168.4.23:0
> would be oh so much better.
Even better would be something that actually tunneled sound through
the X protocol, such that even if all you have is
DISPLAY=localhost:10.0 (set by ssh), it still works.
I have been waiting for that since 1988 or so when I remember the X guru
at school saying 'the next version will have Sound support in it.' and
the next and the next and the next.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
2:08 p.m.
On Wed, Dec 24, 2003 at 12:27:22PM -0600, Steve Bergman wrote:
If it *does* use the display variable, that would be reason enough
in
itself to use it instead of esd and arts.
esd does - but it is disabled by default.
The first question remote desktop users ask me is why their speakers
don't work. It's embarrassing to have to say that it's because we're
using Linux. I've taken to avoiding the whole subject by not even
taking them out of the box.
This isn't well documented stuff unfortunately.
esd supports remote audio, just not the way it comes out of the box. ESD
aware clients will try to connect to port 16001 on the host running esd.
The minimal setup with a trusted network and NFS home directories is to add
-tcp -public
to esd and run the command "esdctl unlock" to allow remote clients.
If you use ssh for remote X sessions then a better approach is
-tcp
and use ssh port forwarding to forward 127.0.0.1:16001 to 127.0.0.1:16001
so that the audio session is also across ssh only. In this case you will also
need NFS or to propogate ~/.esd_auth.
With multiple users you need to pick port numbers for the sessions, so
export ESPEAKER=127.0.0.1:portnum and redirect that to 16001 on the client via
ssh.
Its all rather convoluted but it is possible to wrap ssh up nicely as an
app with a name like "xremote" that runs a script the other end to set up stuff
then runs the remote app.
The port forwarding trick also works nicely with vnc - where you tunnel the vnc
session one way and the esd port back.
Alan
1:58 p.m.
Kristof vansant (de_lupus(a)pandora.be) said:
I guess this will be the standard sound daemon soon ;)
Woo, now if you want mixing, you can use:
- esound
- arts
- dmix plugin in alsa
- MAS
- and more!
If you configure it right, you can have all your sounds
mixed and resampled multiple times before they hit the
card's DMA engine. :)
Bill
7440
days inactive
7440
days old
16 comments
11 participants
participants (11)
-
Alan Cox -
Alexandre Oliva -
Bill Nottingham -
Gerald Henriksen -
lupus -
Sean Estabrooks -
Shahms King -
Simon Perreault -
Stephen Smoogen -
Steve Bergman -
Warren Togami