From alsa-devel-owner@alsa.jcu.cz  Thu Feb  4 01:46:45 1999
Received: from hillbilly.hayseed.net (IDENT:root@dnai-207-181-249-194.dsl.dnai.com [207.181.249.194])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id BAA31139
	for <alsa-devel@alsa.jcu.cz>; Thu, 4 Feb 1999 01:43:51 +0100
Received: from mergatroid.hayseed.net (IDENT:emerson@dnai-207-181-249-211.dsl.dnai.com [207.181.249.211])
	by hillbilly.hayseed.net (8.9.1/8.8.5) with ESMTP id QAA25367;
	Wed, 3 Feb 1999 16:43:47 -0800
Date: Wed, 3 Feb 1999 16:43:47 -0800 (PST)
From: R Pickett <emerson@hayseed.net>
To: Jaroslav Kysela <perex@jcu.cz>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Writing Article Re: Linux audio;  also have new hardware support
In-Reply-To: <Pine.LNX.3.96.990203111819.1554J-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.4.04.9902031621390.19276-100000@mergatroid.hayseed.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, 3 Feb 1999, Jaroslav Kysela wrote:

> I think that designed API functions for digital audio and maybe mixer are
> enough for basic support of proffesional hardware and software. I plan
> extend this API for some sort of synchronization between audio streams
> if hardware allows that and maybe enhance support for realtime applications
> (I have still some ideas how can be improved latency between kernel and
> user space and reduce interrupts from soundcard).

That's good.  For the pro market, latency is a BIG issue.  Currently, BeOS is
on everyone's mind in the MI industry because it has < 5ms latency guaranteed.
In order for Linux to be a compelling pro audio platform, it at least needs to
approach, if not exceed, this performance.

> There isn't any problem support for example special profi MIDI hardware
> which have 16 MIDI outputs and drive this hardware which could look as one
> synthesizator with 256 MIDI channels for an application.

Most pro MIDI software will want the opposite of this kind of thing -- instead
of one big conglomerated mess of channels, the ability to access each MIDI
port separately is a must.  Most Mac MIDI software goes even farther, so that
if you have a DX7 and a Proteus on one MIDI port, you can address each of
those instruments' channels separately.  Most of that is handled by user-space
stuff, though, and might not be directly related to ALSA drivers proper.

But, conglomerating a large MIDI interface into one device with a huge mess of
channels is a Very Bad Idea, IMHO.  Consider the Opcode Studio V, which has 16
ins and outs, AND can be daisy chained several deep, for _thousands_ of MIDI
channels.

> It seems that there is some work on driver Zerofire ZA2 soundcard by
> Martin Pahl <pahl@tnt.uni-hannover.de>, but the driver isn't useable at
> this moment (mainly due to lack of good kernel side documentation for the
> ALSA driver - I know, my fault, but my free time is shorter each new
> year).

So, interested developers who want to throw time at new hardware drivers don't
have proper docs yet.  Hmmn.  I'm going to be trying to pull developers into
writing ALSA drivers for all these companies I have the attention of, but not
being the best coder myself, I'd either need (a) hand-holding docs and example
code, or (b) experienced ALSA coders with time on their hands.

> I hope that ALSA will have stable all APIs at middle of this year. I also
> hope that ALSA will be at this time included to Linux kernel.

Aha.  Is it, then, the case that ALSA _is_ going into the kernel?  As in, Linus
says it will be incorporated at some point?  I just ask for fact-checking
reasons, I want to phrase the mentions of ALSA correctly without jumping to
conclusions.

> If things will happen properly I will work on ALSA at full time job
> from May 1999 (it isn't promise, maybe something will failure). 

(*nod)  That would be nice.

> I willn't probably work on new device drivers to May 1999. I'm very busy
> with English learning. There is a lot of next guys which are working on
> lowlevel drivers now, but I think that none of them have experience with
> profi hardware.

But if given cooperation, specs, and sample hardware, is there the manpower to
work on some of these?  I have two companies ready to be contacted by a
developer right now, but at least five others that might be into it.  Maybe
more, depending.

> I will work only on the sequencer API and maybe on the synth driver for
> GUS soundcards until May 1999.
> 
> I can do some announces on alsa-devel mailing list and our WWW site.
> The important thing also seems to me hardware availability (not only specs
> are enough in most cases).

Hopefully I can act as liaison to get all of that to happen.

> Yep, we must know how can be firmware controlled from device driver,
> but we needn't know how can be firmware (code for the DSP processor)
> developed (programmed) - thus binary form with information how to download
> and initialize the firmware code to DSP is enough.

That's what I suspected, and that's excellent.  One of the two companies I
mentioned above had this exact issue as a concern -- not wanting to open their
DSP code, but more than happy to provide it as binary, and let the driver code
itself be opensource.

> Althrough developing own firmware would be nice thing, of course ;-) But
> it isn't required..

(*nod)  Just so.

> I think that 4Front is going in another (commercial) way than ALSA.

Oh, yes.  But the pro audio industry doesn't understand or care about open
source concerns the way various Linux groups do.  Some folks in MI will prefer
commercial drivers over 'free' ones.  Standard silly stuff, but I can't change
the mindset of the whole industry overnight, so I'll lead the reticent ones
into opensource by way of commercial if need be.  Hopefully, though, most will
see the benefit of opensource hardware code, and will step up to the plate
sooner than later.  We'll see.

-- 
----------------------------------------------------------------
R Pickett                Look around you. This is what the world
emerson@hayseed.net      looks like at the end of the millenium.
----------------------------------------------------------------


