Path: utzoo!attcan!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re: X11R5 wish: better sound
Message-ID: <2653@acorn.co.uk>
Date: 8 Aug 90 10:31:31 GMT
References: <990003@hpnmdla.HP.COM> <990004@hpnmdla.HP.COM>
Reply-To: john@acorn.UUCP (John Bowler)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 63

In article <990004@hpnmdla.HP.COM> roger@hpnmdla.HP.COM (Roger Petersen) writes:
>In comp.windows.x, john@acorn.co.uk (John Bowler) writes:
>
>>...
>> The more you ask for, the less likely you are that any server can
>> do it... 
>
>True.  But *if* the server can perform these functions, it shouldn't take
>much more to perform the same function using an array for input.  And if the
>server can't deal with sound, it can ignore/alter the array commands just
>like it does the existing sound commands.

True (it is very easy, you just ignore all channels but one, or
add them together depending on how nice you want to be).  However
I had to decide where to stop - the aim of the extension is to
enhance the faciltiies for audio *feedback* to the user, I couldn't
demonstrate a need for stereo (etc) so I didn't do it.

>>                                            The extension gives
>> considerable freedom to the server (eg, the sounds won't necessarily
>> be played one after the other, the server might even stop doing
>> anything else while playing the sound, you may not get any choice
>> about sample rate and so on).
>
>I wouldn't have guessed that generating the sounds in the proper order would
>have been the main difficulty.

I didn't express this very clearly.  The server is allowed to
*merge* successive sound requests rather than delaying a second
one until the first is finished.  The definition of ``merge'' in
this context is open - the server can simply forget about the first
request and play the second in its place.  It can also discard a
second request while the first is playing.  (Nasty, but some hardware
might force either behaviour).

>                                If anything, I guessed that generating them
>in a single, fluid, continuous stream would have been the challenge.

Indeed it is.  Our current implementation can suffer from clicks in the
output if given a lot of noises to play.  What a pity :-).

>A command that accepts an array of tones for input wouldn't be required
>to generate them smoothly and synchronously.  However, a server that had
>a good, smooth XSound()/whatever command would allow for some impressive
>musical programs.
>
>So now let's talk about handling multiple voices, noise, sustain, decay... :-)

Yes, exactly - this is what the extension is *not* designed to do.  The
concession to this is that the extension (and XBell) can be switched *off* -
this causes the server to relinquish control of any sound hardware, so it
can then be used by a program which offers a higher quality interface.

The real problem is that any good musical reproduction can require a very
large amount of data.  Although many servers may be able to deal with the
overhead of such data, many may not - even though they can offer much better
sound facilities than XBell.  The Acorn-Noise extension tries to provide
sufficient facilities to enable production of useful audio feedback without
encouraging clients to attempt to play significant amounts of sound, so that
any client which chooses to use the extension is unlikely to stress it to the
point where some servers will be damaged by it.

John Bowler (jbowler@acorn.co.uk)