From alsa-devel-owner@alsa.jcu.cz  Thu Feb  4 11:58:19 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id LAA09439;
	Thu, 4 Feb 1999 11:57:46 +0100
Date: Thu, 4 Feb 1999 11:57:46 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: R Pickett <emerson@hayseed.net>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Writing Article Re: Linux audio;  also have new hardware support
In-Reply-To: <Pine.LNX.4.04.9902031621390.19276-100000@mergatroid.hayseed.net>
Message-ID: <Pine.LNX.3.96.990204103122.8890D-100000@entry.jcu.cz>
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, R Pickett wrote:

> 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.

I don't expect very much improvement. We can currently with good hardware
(PCI soundcards) reach 1.5ms latency.

> > 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.

I wrote this example for demonstration how is flexible sequencer API.
Other things depend on sequencer drivers and user space software, of
course.

> > 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.

My problem with documentation is that responses from my volunteers
for documentation are rare. They seem to be busy. It was main reason
why 0.2.0 final of ALSA driver isn't out (and it won't be probably ever
released).

I'll try do something for kernel side documentation, but you don't expect
immediate results. The most irritating thing for me is that kernel side
ALSA API is changed day to day and things may be pretty obsolete one month
after some docs are out :-((

I can only recommend to developers reading of sources. I'm using this way
over four years and I think that this way is only way to keep things
always recent.

> > 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.

I had some positive responses from Alan Cox which is currently maintain
OSS/Lite drivers. That's all what I can say to this question. I'll fight
for kernel inclusion of ALSA driver, of course.

> > 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.

It's nice to hear that some companies are ready for this.
I cannot offer my hands until May 1999, but I moved this discussion to
alsa-devel mailing list where are other ALSA developers. I'm also asking:

Anybody have got interrest work with profi hardware and write ALSA driver?
Linux kernel coding knowledge is required.

It would be fine if you can write some small HTML document and I can put
your offer to ALSA's WWW site. Or I can give you access to some directory
on ALSA's WWW server for your pages if you want (better updating).

> > 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.

This will be fine.

> > 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.

I welcome activities from any person for ALSA, but I'm not sure if 4Front
will work on ALSA if they have own commercial drivers.

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic









