Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Adam Olsen (adamolsen_AT_technologist.com)
Date: Wed May 09 2001 - 01:43:29 EEST


On Tue, May 08, 2001 at 12:51:16PM -0700, Jay Ts wrote:
> Paul Barton-Davis wrote:
> > I've tried to be as fair as I can in presenting these summaries. What
> > do you think?
>
> Paul, first of all, thanks very much for writing up your summary! Like
> others reading this list, I'd gotten more than a little lost in the
> discussion, and it was to the point of not really having a handle on
> what people have been writing.

I agree, although I'm still a bit lost ;)

>
> During this time, I've been thinking, when they first started developing
> internet protocols, maybe the development groups went through similar
> confusion until someone came up with the idea of RFCs (?) In any case,
> I think that a similar process would be hugely beneficial to all of us -
> that way anyone would be able to post their own ideas, including proposed
> APIs, white papers (even poetry :) in a more formalized (that is, more
> clearly thought out and expressed) way, all put into one focused document.
> And then others could go to the source and "tune in" or "catch up" with
> the discussion.
>
> I'm sure (or am I? :) there are documents like this, or at least along
> similar lines, on LADSPA, ALSA and others, but I'd like to see them
> done in a "white paper" or RFC sort of way, so I can access them in
> a group and search and read through them. For example, it was a pleasure
> for me to read Steinberg's documents on ASIO and VST 2.0. Once I downloaded
> them, it just took me a few minutes to understand the fundamentals of VST
> and be able to think about it in an intelligent manner.
>
> Let me know - is this a dumb idea, or should I write up an RFC on it? :-)

I think it's worthwhile, although I don't think we need things to be
quite as formal as an RFC :)

To start things off, might I suggest a specific realworld example to
be demonstrated for each proposal? I'm thinking that of a typical
(3d) game. You have it loading the samples of various rates, applying
various distance and direction effects to them, mixing them together,
and outputing them. The output could go to various things - a
soundcard, the harddisk, the network for remote use, or even several
things at once. And in the case of the soundcard, there may be two
apps outputting sound at once (requiring mixing).

And while I'm at it, why don't I give my own ideas on how things
should be organized? I would split the components into two types -
symmetric and asymmetric. Symmetric components take a given amount of
input from the engine, and return an identical amount of data to it
(probably using the same buffer). Asymmetric (not surprisingly) do
the opposite, take a given amount of input from the engine (possibly
none), and a different amount of data. This could be from changing
the rate for the sample, reading in from a microphone, or outputting
to the soundcard.

Another distinction that could be made is internal vs external. The
game may be able to do all it's internal mixing and sound effects in a
single thread, but once it outputs it (to the soundcard or wherever),
another process would have to handle it. Unless of course it's
outputting directly to the card, then there's just the kernel-level
hardware api.

Thoughts? I've probably showed great naivety, but oh well :)

-- 
Adam Olsen, aka Rhamphoryncus


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 09 2001 - 02:24:01 EEST