From caolan@metasyntax.ul.ie
Received: (qmail 16705 invoked from network); 30 Jan 1998 11:10:17 -0000
Received: from mailgate.ul.ie (136.201.1.23)
by mail2.redhat.com with SMTP; 30 Jan 1998 11:10:17 -0000
Received: from exch-staff1.ul.ie by mailgate.ul.ie with SMTP (PP)
id <03763-0@mailgate.ul.ie>; Fri, 30 Jan 1998 10:56:48 +0000
Received: from METASYNTAX by exch-staff1.ul.ie
with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7)
id DB0XSPJ9; Fri, 30 Jan 1998 11:05:01 -0000
Content-Length: 491
Message-ID: <XFMail.980130110938.Caolan.McNamara@ul.ie>
X-Mailer: XFMail 1.1 [p0] on Linux
Sender: caolan@metasyntax.ul.ie
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Fri, 30 Jan 1998 11:01:44 -0000 (GMT)
Organization: Interactive Design Center
From: Caolan McNamara <Caolan.McNamara@ul.ie>
To: gnome-list@gnome.org
Subject: sound and gnome ?
has the gnome project finalized a sound api ?, if not id like to suggest that
whatever support is included be capable of being used over a network, perhaps
using nas or rplay, so often its forgotten when sound is used in an x app that
while X has network support "open /dev/audio" has not.
C.
Real Life: Caolan McNamara * Doing: MSc in HCI
Work: Caolan.McNamara@ul.ie * Phone: +353-61-202699
URL: http://skynet.csn.ul.ie/~caolan * Sig: an oblique strategy
Its centre
From raster@redhat.com
Received: (qmail 17811 invoked from network); 30 Jan 1998 15:41:31 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 30 Jan 1998 15:41:31 -0000
Received: from trode.redhat.com (root@trode.redhat.com [199.183.24.80])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id KAA25707;
Fri, 30 Jan 1998 10:41:28 -0500
Received: from redhat.com (raster@trode [127.0.0.1])
by trode.redhat.com (8.8.7/8.8.7) with ESMTP id KAA07844;
Fri, 30 Jan 1998 10:40:34 -0500
From: raster@redhat.com
Message-Id: <199801301540.KAA07844@trode.redhat.com>
Date: Fri, 30 Jan 1998 10:40:31 -0500 (EST)
Reply-To: raster@redhat.com
Subject: Re: sound and gnome ?
To: Caolan.McNamara@ul.ie
cc: gnome-list@gnome.org
In-Reply-To: <XFMail.980130110938.Caolan.McNamara@ul.ie>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
On 30 Jan, Caolan McNamara shouted:
-> has the gnome project finalized a sound api ?, if not id like to suggest that
-> whatever support is included be capable of being used over a network, perhaps
-> using nas or rplay, so often its forgotten when sound is used in an x app that
-> while X has network support "open /dev/audio" has not.
I have, a while back investigated "decent sound subsystems" - this was
infact for Enlightenment (Dr0.14).. I looked at rplay, nas, and
sfxserver - suffice to say the latter was tossed out imediately on
reading the README and its specs. rplay didn't survive long due to the
sound cracklick like no tomorrow. Nas survived about an hour until I
gave up wondering what was broken when sometimes it refused to start or
accept milt-channel playback. I was not in a mood to read the sources
and fix it... so in a fit I went and wrote my own - it has
authentication (security) very smilar to X's Xauthority system, can
handle theoretically infinite channels of audio streams from 1 to 44100
hz playback, 8,16 bit, mono or stereo. You could register an audio
"monitors" that would be able to suck of the "mixed" output stream going
to the sound device - that was great for a waveform display program. It
also handled setting the sound device to record.
Its problems are: the sound device MUST do 44.1Khz, stereo 16bit. it
uses unix-scokets to conections. It only handles streams. The mixing
code wasn't the most optimised code I could have ever written (On my
old P120 I could play 12-15 samples at once before it started
crackling). It, also, like most sound programs had a "lag" problem due
to the audio device buffering, because it didn't mmap the device. It
assumed a simplex sound device. Ie could oly play or record. not both.
I have not seen a sound device, even for full duplex cards, that
supports both - this is a deficiency in the kernel level driver for
linux.
I have now passed this code on to someone else who is infact develping
it further. He is adding support for other sound devices (/dev/audio -
8bit, lower sampling rates, mono etc.) Also ading tcp/ip conections.
Also He sould be fixing the "lag" by mmaping the sound device to make
sure the sound monitor reading the stream is synched with the sound
going out the speakers. Also he is handling "smaple uploading, storing
and playback" mechanisms, wich left/right volume settings with optional
envelopes.
If there are any sound gurus who write hell fast mixing code, mmap
their sound devices because they can use a function call they don't use
often - and just because they can, or juts want to help out, get back to
ericmit@ix.netcom.com
he has my old code which is available at:
http://www.rasterman.com/ftp/sounD_DR-0.1.tar.gz
If you want to take a look. It also contains a small set of utilities
(souDplay, sounDmod and sounDmpg plus more (sounDplay acepts raw aduio
data and plays it - ie wav samples, sounDmod is mikmod ported to use
sounD, sounDmpg is mpg123 proted - they all work.).
->
-> C.
-> Real Life: Caolan McNamara * Doing: MSc in HCI
-> Work: Caolan.McNamara@ul.ie * Phone: +353-61-202699
-> URL: http://skynet.csn.ul.ie/~caolan * Sig: an oblique strategy
-> Its centre
->
->
--
--------------- 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 Enlightenmenthttp://www.rasterman.com/
From msf@redhat.com
Received: (qmail 27992 invoked from network); 30 Jan 1998 16:58:55 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 30 Jan 1998 16:58:55 -0000
Received: from majestic.labs.redhat.com (root@majestic.labs.redhat.com [207.175.45.4])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id LAA30155
for <gnome-list@gnome.org>; Fri, 30 Jan 1998 11:58:55 -0500
Received: from majestic.labs.redhat.com (msf@localhost [127.0.0.1])
by majestic.labs.redhat.com (8.8.7/8.8.4) with ESMTP
id MAA09258 for <gnome-list@gnome.org>; Fri, 30 Jan 1998 12:00:06 -0500
Message-Id: <199801301700.MAA09258@majestic.labs.redhat.com>
To: gnome-list@gnome.org
Subject: Re: sound and gnome ?
In-reply-to: Your message of "Fri, 30 Jan 1998 10:40:31 EST."
<199801301540.KAA07844@trode.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 Jan 1998 12:00:06 -0500
From: Michael Fulbright <msf@redhat.com>
The Sound section under the Architecture section on the gnome website
was my attempt at laying out what several people here have been
going into much greater detail about.
Raster sounded like he has done the most actually research/coding on
this problem. I'm not against using something homebrewed, but if
NAS can be made to easily do what we're wanting it might be worth
considering since it is a standard.
On the other hand, it would be cool to have a system where you
could plug in components in the stream, so you could hook an FFT
onto the final output and plot it, etc...
My concern is that for games which require control over timing of
sound events. I'll try to have a look at NAS - does anyone have a feeling
for how much latency we could expect?
Dr Mike
msf@redhat.com
From caolan@metasyntax.ul.ie
Received: (qmail 24205 invoked from network); 30 Jan 1998 17:50:09 -0000
Received: from mailgate.ul.ie (136.201.1.23)
by mail2.redhat.com with SMTP; 30 Jan 1998 17:50:09 -0000
Received: from exch-staff1.ul.ie by mailgate.ul.ie with SMTP (PP)
id <13145-0@mailgate.ul.ie>; Fri, 30 Jan 1998 17:35:42 +0000
Received: from METASYNTAX by exch-staff1.ul.ie
with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7)
id DB0XSPP2; Fri, 30 Jan 1998 17:43:02 -0000
Content-Length: 1640
Message-ID: <XFMail.980130174229.Caolan.McNamara@ul.ie>
X-Mailer: XFMail 1.1 [p0] on Linux
Sender: caolan@metasyntax.ul.ie
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199801301700.MAA09258@majestic.labs.redhat.com>
Date: Fri, 30 Jan 1998 17:26:16 -0000 (GMT)
Organization: Interactive Design Center
From: Caolan McNamara <Caolan.McNamara@ul.ie>
To: gnome-list@gnome.org
Subject: Re: sound and gnome ?
On 30-Jan-98 Michael Fulbright wrote:
>
>The Sound section under the Architecture section on the gnome website
>was my attempt at laying out what several people here have been
>going into much greater detail about.
>
>Raster sounded like he has done the most actually research/coding on
>this problem. I'm not against using something homebrewed, but if
>NAS can be made to easily do what we're wanting it might be worth
>considering since it is a standard.
>
>On the other hand, it would be cool to have a system where you
>could plug in components in the stream, so you could hook an FFT
>onto the final output and plot it, etc...
>
>My concern is that for games which require control over timing of
>sound events. I'll try to have a look at NAS - does anyone have a feeling
>for how much latency we could expect?
as for the exact latency involved i dont know, but theres is a version of
doom that using nas, thats some data in favour of the practicality of
the idea. if anyones going to look at nas id like to point out again
that nas-p5 doesnt work correctly under linux, theres a working patched
version at
http://www.csn.ul.ie/~caolan/publink/nas/
and the replacement for sndserver that unix doom uses is at
http://www.cdrom.com/pub/doom/utils/unix/nas-sndserver*
Even if nas wasnt fully up to the task to support the base protocol
might be a nice idea, and then add whatever extra functionality was
for gnome use to it.
C.
Real Life: Caolan McNamara * Doing: MSc in HCI
Work: Caolan.McNamara@ul.ie * Phone: +353-61-202699
URL: http://skynet.csn.ul.ie/~caolan * Sig: an oblique strategy
Use fewer notes
From msf@redhat.com
Received: (qmail 4359 invoked from network); 30 Jan 1998 21:12:18 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 30 Jan 1998 21:12:18 -0000
Received: from majestic.labs.redhat.com (root@majestic.labs.redhat.com [207.175.45.4])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id QAA10968;
Fri, 30 Jan 1998 16:12:17 -0500
Received: from majestic.labs.redhat.com (msf@localhost [127.0.0.1])
by majestic.labs.redhat.com (8.8.7/8.8.4) with ESMTP
id QAA10690; Fri, 30 Jan 1998 16:13:31 -0500
Message-Id: <199801302113.QAA10690@majestic.labs.redhat.com>
To: Caolan McNamara <Caolan.McNamara@ul.ie>
cc: gnome-list@gnome.org
Subject: Re: sound and gnome ?
In-reply-to: Your message of "Fri, 30 Jan 1998 17:26:16 GMT."
<XFMail.980130174229.Caolan.McNamara@ul.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 Jan 1998 16:13:30 -0500
From: Michael Fulbright <msf@redhat.com>
The Linux Game SDK group is working on a sound system of their own,
look at
http://tychonic.antioch.edu/~gsdk/
At the moment I don't see the underlying hardware abstraction layer
as the issue, its more the gnome API for sound that is more interesting
to work on. We can use NAS or something else for now to handle the mixing
of streams, and change it later if it isn't doing everything we need.
The initial goal needs to be designing the gnome API so gnome apps are
independent of the hw layer we use.
The model I see is
GNOME
Event Manager-
\
+ Gnome Sound API -> HW Abstraction (NAS?) -> Sound HW
GNOME /
Application -
The GNOME event manager will accept triggers (help me here elliot if I'm lost)
and will handle mappings to the associated action. There will be
standard triggers than applications can activate, like 'out of disk space'.
The event manager will have actions which can be user configured, perhaps
to play a 3 stooges wav file. The Gnome Sound API needs to be able to
play a standard sound file in that case.
GNOME applications, like gnoom or a mod tracker will also want to access
the sound hw, but at a much finer level than just 'play this sound'.
The ability to control the buffer size, etc will be important.
Comments?
Dr Mike
msf@redhat.com
From tromey@creche.cygnus.com
Received: (qmail 27162 invoked from network); 30 Jan 1998 23:51:24 -0000
Received: from creche.cygnus.com (192.203.188.26)
by mail2.redhat.com with SMTP; 30 Jan 1998 23:51:24 -0000
Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3)
id QAA12673; Fri, 30 Jan 1998 16:48:35 -0700
To: Michael Fulbright <msf@redhat.com>
Cc: Caolan McNamara <Caolan.McNamara@ul.ie>, gnome-list@gnome.org
Subject: Re: sound and gnome ?
References: <199801302113.QAA10690@majestic.labs.redhat.com>
X-Zippy: What I want to find out is -- do parrots know much about Astro-Turf?
X-Attribution: Tom
BCC:
Reply-To: tromey@cygnus.com
From: Tom Tromey <tromey@creche.cygnus.com>
Date: 30 Jan 1998 16:48:33 -0700
In-Reply-To: Michael Fulbright's message of Fri, 30 Jan 1998 16:13:30 -0500
Message-ID: <m1d8h9ed65.fsf@creche.cygnus.com>
Lines: 83
X-Mailer: Red Gnus v0.34/Emacs 19.34
DrMike> The initial goal needs to be designing the gnome API so gnome
DrMike> apps are independent of the hw layer we use.
Yeah. But arguably that is what something like NAS provides, right?
It is precisely an API that is independent of the hardware (and
network).
Do we really need another abstraction layer on top of this? I can see
that we might want one if we were really unsure of which protocol we
wanted to use, or if we wanted to support several protocols. I don't
know if either of these is the case.
DrMike> GNOME
DrMike> Event Manager-
DrMike> \
DrMike> + Gnome Sound API -> HW Abstraction (NAS?) -> Sound HW
DrMike> GNOME /
DrMike> Application -
I'm largely in agreement here.
I think there are two kinds of programs:
1. Programs that need sound. Games, music programs, mixers, etc fit
in here.
2. Programs that might want to use sound as an "extra".
Basically everything else fits in here: editors, xterm, etc.
Programs in category #1 need direct access to the Sound API.
Programs in category #2 don't necessarily need to know that sound
exists.
DrMike> The GNOME event manager will accept triggers (help me here
DrMike> elliot if I'm lost) and will handle mappings to the associated
DrMike> action. There will be standard triggers than applications can
DrMike> activate, like 'out of disk space'. The event manager will
DrMike> have actions which can be user configured, perhaps to play a 3
DrMike> stooges wav file. The Gnome Sound API needs to be able to play
DrMike> a standard sound file in that case.
I think we should view the event manager as a low-level bus. It
accepts events, and then redistributes them to the objects that have
registered an interest. I think the event manager shouldn't have any
direct knowledge of sound, because it is a generic service that will
be used for other things.
Instead, there should be a program that listens to the events coming
off the event manager, and translates the appropriate ones into sound.
For instance, it might see an event indicating "the build failed", and
turn that into a buzzing noise. Or it might see a "talk session
requested" event, and turn that into a phone ringing. Or whatever.
The Gnome Sound API wouldn't need to be able to play standard sound
files for this to work. That would be the job of this special program
-- it is in category #1.
More exposition on events and such: the way I see it, an "event"
should just be a string (the name) and some piece of associated data.
The names of events will be defined solely through convention. We'll
document all the ones our code generates/supports, but any program
could add a new event at any time. (Maybe this is too low-tech? I
personally like low-tech solutions, but I realize they don't match
everybody's sense of style. Feel free to chime in.)
The event->sound program can work by doing pattern matching on event
names. Maybe something more complicated would be required (e.g.,
something to actually look inside the event data to make decisions),
but that can be addressed entirely within this program.
One nice thing about removing decisions about sound from individual
applications is that we give the user more power to control the use of
sound (provided the applications generate events in all the
interesting cases). For instance, a user who doesn't like sound could
turn it off in one place.
Tom
From msf@redhat.com
Received: (qmail 8565 invoked from network); 31 Jan 1998 06:20:02 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 31 Jan 1998 06:20:02 -0000
Received: from tomservo.redhat.com (msf@tomservo.redhat.com [199.183.24.41])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id BAA00052
for <gnome-list@gnome.org>; Sat, 31 Jan 1998 01:20:01 -0500
Received: from localhost (msf@localhost)
by tomservo.redhat.com (8.8.7/8.8.4) with SMTP
id BAA08421 for <gnome-list@gnome.org>; Sat, 31 Jan 1998 01:19:59 -0500
Date: Sat, 31 Jan 1998 01:19:59 -0500 (EST)
From: Michael Fulbright <msf@redhat.com>
Reply-To: Michael Fulbright <msf@redhat.com>
To: gnome-list@gnome.org
Subject: Re: sound and gnome ?
In-Reply-To: <m1d8h9ed65.fsf@creche.cygnus.com>
Message-ID: <Pine.LNX.3.96.980131010122.530i-100000@tomservo.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 30 Jan 1998, Tom Tromey wrote:
> DrMike> The initial goal needs to be designing the gnome API so gnome
> DrMike> apps are independent of the hw layer we use.
>
> Yeah. But arguably that is what something like NAS provides, right?
> It is precisely an API that is independent of the hardware (and
> network).
>
> Do we really need another abstraction layer on top of this? I can see
> that we might want one if we were really unsure of which protocol we
> wanted to use, or if we wanted to support several protocols. I don't
> know if either of these is the case.
>
>
I think I was leaning to the side of caution and suggesting we put
almost a stub layer on top of whatever we use under Linux (NAS perhaps)
so that 1) all the GNOME apps dont have to be rewritten when we
decide NAS is broken down the line, and 2) it will be easier to
get GNOME working on a platform that doesn't use whatever sound
system we chose (like NAS).
We're stuck using something like NAS because the current Linux
sound drivers in the kernel don't do the mixing for us. Alan Cox
gave me the impression we shouldn't expect this to appear in
the kernel in the future, though I could be mistaken. And NAS
would provide a way to do sound over a network, which is interesting.
But I don't know if NAS will handle the real-time multimedia type
applications, like RealVideo stream, mpeg video, etc. Perhaps it
can be made to work - but until we're sure I recomend we hide
it from our GNOME apps so we can change to something else later and
the GNOME apps will still work fine.
I am making sense, or am I being overly caution?
>
> I think we should view the event manager as a low-level bus. It
> accepts events, and then redistributes them to the objects that have
> registered an interest. I think the event manager shouldn't have any
> direct knowledge of sound, because it is a generic service that will
> be used for other things.
>
Agreed 100%, I like the way you described this very much.
Dr Mike
msf@redhat.com