documentation - yeah right!

documentation - yeah right!

[Cliff Bradshaw]

If alsa is supposed to be so profesional, why does it have no decent documentation?

I have searched the whole internet and still cant find any proper documentation on how to use the fscking sequencer interface!

sure there is the howto by Matthias Nagorni, (thank god *someone* is writing docs for the seuqncer!) but I want to see a proper API reference

doxygen is just an excuse to avoid writing documentation and should be banned from all projects. If I want a list of all the damn globals I'll look in the source code thankyou.

seriously though. Alsa is great, but is not going to suceed unless we know how to use it.  OSS has pretty good documentation and it will continue to be the standard linux audio api unless we tell people how to use alsa!!!!!!!!!


___________________________________________________ 
What does an anemometer measure? 
Find out at postmaster.co.uk

http://www.postmaster.co.uk/cgi-bin/meme/quiz.pl?id=200


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Jaroslav Kysela]

On Tue, 20 May 2003, Cliff Bradshaw wrote:

> If alsa is supposed to be so profesional, why does it have no decent
> documentation?
> 
> I have searched the whole internet and still cant find any proper
> documentation on how to use the fscking sequencer interface!
> 
> sure there is the howto by Matthias Nagorni, (thank god *someone* is
> writing docs for the seuqncer!) but I want to see a proper API reference
> 
> doxygen is just an excuse to avoid writing documentation and should be
> banned from all projects. If I want a list of all the damn globals I'll
> look in the source code thankyou.
> 
> seriously though. Alsa is great, but is not going to suceed unless we
> know how to use it.  OSS has pretty good documentation and it will
> continue to be the standard linux audio api unless we tell people how to
> use alsa!!!!!!!!!

Sit down. Read the available reference. If something is unclear, ask us in
this list and repair the comments / write more documentation for other
people. Then send us patches to include your changes into main source
tree. I am sure that everybody will enjoy this step. Only crying does not
help.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Josh Green]

On Tue, 2003-05-20 at 13:10, Cliff Bradshaw wrote:
> If alsa is supposed to be so profesional, why does it have no decent documentation?
> 
> I have searched the whole internet and still cant find any proper documentation on how to use the fscking sequencer interface!
> 
> sure there is the howto by Matthias Nagorni, (thank god *someone* is writing docs for the seuqncer!) but I want to see a proper API reference
> 
> doxygen is just an excuse to avoid writing documentation and should be banned from all projects. If I want a list of all the damn globals I'll look in the source code thankyou.
> 
> seriously though. Alsa is great, but is not going to suceed unless we know how to use it.  OSS has pretty good documentation and it will continue to be the standard linux audio api unless we tell people how to use alsa!!!!!!!!!
> 

Perhaps you are being confused with how to navigate the doxygen
reference (a rather easy thing to do). If this is the case, try going to
the "File List" link at the top of the ALSA library reference and then
click on seq.c in the list and you will see all the routines used for
the sequencer. Clicking on one will give you more details. The only
thing I find a little annoying by the reference docs is that the pages
are so huge (perhaps because most routines are documented :).

Another good source of reference would be to take a look at some example
programs (there are some in the "test" directory in the alsa-lib
source).

Your request for help is less likely to succeed with the tone in which
you are writing, though. Keep in mind that many of the individuals
working on this are doing so in their spare time, because they like
doing it. Its people that bad mouth this that are more likely to cause
it to not succeed than anything else, free software developers like to
be appreciated for their work. Cheers.
	Josh Green



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Kai Vehmanen]

On Tue, 20 May 2003, Cliff Bradshaw wrote:

> doxygen is just an excuse to avoid writing documentation and should be
> banned from all projects. If I want a list of all the damn globals I'll
> look in the source code thankyou.

That's just not true at all. Existing ALSA API reference documentation
(written using the Doxygen notation) provides far more info than just a
list of globals. It's not perfect, but still, making false claims like
that is not a very good way to start a discussion.

FWIW, I've seen Doxygen used very succesfully in many large-scale
projects. It's not a replacement for higher level documentation of course,
but it's absolutely brilliant replacement for those overly verbose
function/class reference docs (ugh, think of huge word/pdf docs that list
each and every variable and function, which in addition to providing
little extra value, require different tools to read and edit, are
versioned with different tools, are not in sync with the source-code, etc,
etc).

PS I'd suggest making a pdf, generated from the doxygen ALSA docs, and put 
   it on the ALSA website (automatically generated or at each major 
   release). As we all know, if it's not a pdf/doc, it's not 
   real documentation. ;)

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[David Stuart]

On Tue, 2003-05-20 at 16:52, Kai Vehmanen wrote:
> On Tue, 20 May 2003, Cliff Bradshaw wrote:
> 
> > doxygen is just an excuse to avoid writing documentation and should be
> > banned from all projects. If I want a list of all the damn globals I'll
> > look in the source code thankyou.
> 
> That's just not true at all. Existing ALSA API reference documentation
> (written using the Doxygen notation) provides far more info than just a
> list of globals. It's not perfect, but still, making false claims like
> that is not a very good way to start a discussion.

Agreed, but he's probably simply frustrated and prone to exaggeration..

Being a newbie myself, I agree that doxygen is certainly useful (since I
come from java where javadoc rules and is very similar), but I guess
what's missing is more of the high-level picture. Some discussions about
the main objects/concepts of the system, why they exist, what their
responsibilities are, how they interact, etc..

There is of course, some of this in the doxygen docs, but there could be
more.

These kinds of things really help ease the learning curve. Right now,
the only thing you can do in some cases is flip around and try to glean
the higher level purpose of a section from its methods.

-- 
David Stuart, SIPQuest
phone: 254-8886 x234 web: http://www.sipquest.com/



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Paul Davis]

>seriously though. Alsa is great, but is not going to suceed unless we know how
> to use it.  OSS has pretty good documentation and it will continue to be the 
>standard linux audio api unless we tell people how to use alsa!!!!!!!!!

its no longer the standard for kernel 2.5 and above, where ALSA has
taken its place. and if you take a look at this list
(http://jackit.sourceforge.net/apps/) you'll see that as far as actual
music/pro-audio apps go, neither OSS nor ALSA are "the standard" :)

oh, by the way, welcome to ALSA ...

--p


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Drake Wilson]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

Quoth Cliff Bradshaw <cliff@postmaster.co.uk>, on Tue 20 May 2003:
> 
> If alsa is supposed to be so profesional, why does it have no decent
> documentation?

I find most of the documentation to be quite decent, actually.

> I have searched the whole internet and still cant find any proper
> documentation on how to use the fscking sequencer interface!

This is a lacuna, albeit one which may be remediable by
non-ALSA-developers.  I am researching the sequencer interface for a
program I am writing; afterwards, I plan to attempt some better
tutorial-level documentation for it, assuming I am able to with
respect to logistics and knowledge organization.

Developers -- I assume the sequencer alsa-lib interface is not
planning to be radically changed in the near future?

> doxygen is just an excuse to avoid writing documentation and should
> be banned from all projects. If I want a list of all the damn
> globals I'll look in the source code thankyou.

This is overreaction, in my opinion.

> seriously though. Alsa is great, but is not going to suceed unless
> we know how to use it.  OSS has pretty good documentation and it
> will continue to be the standard linux audio api unless we tell
> people how to use alsa!!!!!!!!!
(footer snip)

Your punctuation and pseudo-zeal do not help your argument any.
Please read <http://www.catb.org/~esr/faqs/smart-questions.html>.

   ---> Drake Wilson

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: documentation - yeah right!

[Patrick Shirkey]

Drake Wilson wrote:

> 
> This is a lacuna, albeit one which may be remediable by
> non-ALSA-developers.  I am researching the sequencer interface for a
> program I am writing; afterwards, I plan to attempt some better
> tutorial-level documentation for it, assuming I am able to with
> respect to logistics and knowledge organization.
> 

Yes please. We have been waiting for someone to take this up for a 
while. It appears that the people who do work with the sequencer 
interface are either too busy or too shy to write something which 
everyone can reference.

It would be the last arrow in the quiver IMO.

You will get a lot of support for anything you submit BTW.

-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

RE: documentation - yeah right!

[Giuliano Pochini]

On 20-May-2003 Cliff Bradshaw wrote:
> If alsa is supposed to be so profesional, why does it have no decent
> documentation?

It's 0.9.3. Do you see the leading "0" ?  ALSA is still incomplete.

> I have searched the whole internet and still cant find any proper documentation
> on how to use the fscking sequencer interface!

Other docs are missing too.  e.g. the hctl interface.

> doxygen is just an excuse to avoid writing documentation and should be banned
> from all projects. If I want a list of all the damn globals I'll look in the
> source code thankyou.

Hey, ALSA developers are not your slaves. What about to contribute ?  Use the
sources and the list, and while you learn to use the seq interface, you write
the documentation.


Bye.



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Richard Cochran]

On Wed, May 21, 2003 at 09:34:56AM +0200, Giuliano Pochini wrote:
>> doxygen is just an excuse to avoid writing documentation and should be
>> banned from all projects. If I want a list of all the damn globals
>> I'll look in the source code thankyou.

I must agree with the sentiment of the original poster. Even if you
document every last API function, you still have not explained the
API. One would need a written (human language, not source code)
document to describe the goals of the architecture and how to use the
API on the large scale. OSS has a short, readable document that does
this.

I am a talented programmer with some (little) free time to spend on
linux audio drivers/apps. I evaluated Alsa and OSS and concluded that
I would avoid Alsa for the following reasons:

1. After two attempts, I could not get the existing Alsa drivers to
work with my own sound cards at all. The installation seems very
complex, even for linux drivers! For example consider the multitude of
sources (five different tarballs to download) and different kernel
modules. When it comes to linux, I don't give up easily. I tried to
install Alsa because I read that Alsa was "more advanced", but I found
it only to be "more complex". In contrast, the OSS modules work with
a simple 'insmod' command. In fairness, I expect this problem to go
away with kernel 2.6, now that Alsa is part of the kernel.

2. The OSS drivers for my cards lacked some features, but reading the
Alsa sources revealed that the Alsa drivers had the same limitations,
and indeed shared the same code (I'm talking about i810_audio and
usb-audio).

3. The Alsa API seems overly complex. OSS has a pretty straightforward
interface, like other drivers, using open, read, write, and mmap. All
things being equal, I aways prefer the simpler way.

4. I could not find a design document for the Alsa way. "Architecture"
is in the name, but what is the architecture? Is it only apparent in
the driver sources? Alsa promises to deliver better audio performance
and more functionality, but how will the Alsa architecture provide
this?

> Hey, ALSA developers are not your slaves. What about to contribute ?
> Use the sources and the list, and while you learn to use the seq
> interface, you write the documentation.

5. I've gleaned from the list that the Alsa API is still in a state of
flux. Am I correct? If so, then this troubles me. The "code first,
figure the design out later" approach is sometimes needed, but for an
ambitious idea like Alsa, with long term goals, it would be good to
have some kind of design thought out, and spelled out in black and
white.

It seems to me that the main problem with OSS is the uneven quality of
the drivers, not the overall design. OSS would only need better
drivers and a user space library like alsa-lib, for rate/format
conversion and mixing.

I don't mean to flame the good work of the Alsa contributors. I follow
the list, and I would like to learn the Alsa way. I am skeptical,
however, and would like to see a discussion of how Alsa delivers what
OSS cannot.

Thanks in advance for your helpful comments...

Richard

PS I looked (again) at the stuff on the Alsa "documents" page, and I
found two broken links:

 Howto use the ALSA API - Paul Davis has also written a brief explanation.
 http://www.op.net/~pbd/alsa-audio.html

 http://www.alsa-project.org/alsa/cvs/alsa-driver/INSTALL

There does not seem to be an "installation guide" available from the
Alsa site.



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Paul Davis]

>I must agree with the sentiment of the original poster. Even if you
>document every last API function, you still have not explained the
>API. 

Nobody disagress with the sentiment of the original poster. At least a
half-dozen to a dozen people have wandered onto this list and said
they would write documentation. It hasn't happened. Why? Its not
because its considered to be useless. It hasn't happened because
nobody has the time or inclination to write it. So far. Thats
all. There is no opposition to higher level documentation, only a lack
of time or motivation.

>it only to be "more complex". In contrast, the OSS modules work with
>a simple 'insmod' command. In fairness, I expect this problem to go
>away with kernel 2.6, now that Alsa is part of the kernel.

in fairness, that whole paragraph was unfair for exactly that reason.

>3. The Alsa API seems overly complex. OSS has a pretty straightforward
>interface, like other drivers, using open, read, write, and mmap. All
>things being equal, I aways prefer the simpler way.

as i was just writing to the guys from 4Front (who get irritated by my
constant complaints about OSS), while OSS may have a simple API for
the i/o side of things, the OSS API for configuring the parameters is
inadequate, and moreover, one cannot interpose between the app and the
driver, requiring lots of things to be put into the kernel that don't
belong there (format conversion, SR conversion, etc. etc.). that's why
ALSA doesn't look like read/write/open/close: if you use those calls,
then everything on the other side of them has to be in the kernel.

>4. I could not find a design document for the Alsa way. "Architecture"
>is in the name, but what is the architecture? Is it only apparent in
>the driver sources? Alsa promises to deliver better audio performance
>and more functionality, but how will the Alsa architecture provide
>this?

it already has provided it. it offers generic ways to do things that
were simply impossible or at best very tricky with OSS. the plug_hw
layer in ALSA has no equivalent for OSS, anywhere.

>5. I've gleaned from the list that the Alsa API is still in a state of
>flux. Am I correct? If so, then this troubles me. The "code first,

no, that's wrong. the API is not 100% frozen, but its definitely in flux.

>figure the design out later" approach is sometimes needed, but for an
>ambitious idea like Alsa, with long term goals, it would be good to
>have some kind of design thought out, and spelled out in black and
>white.

actually, many people disagree with this. there were many changes to
the design of ALSA that occured over the last 2 years and were
prompted by coming to terms with what the requirements actually were,
which in turn occured because of new types of audio interfaces
appearing that challenged the assumptions on which OSS and earlier
versions of ALSA were built.

>It seems to me that the main problem with OSS is the uneven quality of
>the drivers, not the overall design. OSS would only need better
>drivers and a user space library like alsa-lib, for rate/format
>conversion and mixing.

there is no such library, and the programmer would have to use it
explicitly (because of the lack of redirection i mentioned above),
rather than implicitly. its the overall design of OSS that is the
problem - the quality of the drivers is generally very good.

> Howto use the ALSA API - Paul Davis has also written a brief explanation.
> http://www.op.net/~pbd/alsa-audio.html

this link is not broken. it points to the new location (my ISP changed).



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Paul Davis]

Correction:

>>5. I've gleaned from the list that the Alsa API is still in a state of
>>flux. Am I correct? If so, then this troubles me. The "code first,
>
>no, that's wrong. the API is not 100% frozen, but its definitely in flux.

							        ^^^^
								NOT



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Richard Cochran]

On Wed, May 21, 2003 at 11:24:35AM -0400, Paul Davis wrote:
> >it only to be "more complex". In contrast, the OSS modules work with
> >a simple 'insmod' command. In fairness, I expect this problem to go
> >away with kernel 2.6, now that Alsa is part of the kernel.
> 
> in fairness, that whole paragraph was unfair for exactly that reason.

Unfair, perhaps, yet true. Getting alsa to work with a 2.4.x kernel
today is not exactly easy.

> the i/o side of things, the OSS API for configuring the parameters is
> inadequate, and moreover, one cannot interpose between the app and the
> driver, requiring lots of things to be put into the kernel that don't
> belong there (format conversion, SR conversion, etc. etc.).
> ALSA doesn't look like read/write/open/close: if you use those calls,
> then everything on the other side of them has to be in the kernel.

I don't agree that OSS conversion would have to be in the kernel. You
could simply pipe all of your audio through sox using simple shell
commands! Clunky, yes, but it would work.

More to the point, I can imagine a user library to provide:

  write_conversion(int fd, //open file descriptor
                   void* buf, //samples to write
                   int buflen, //length of buffer
                   sometype fmtin, //format of buffer
                   sometype fmtout, //desired conversion
                   sometype alg //desired conversion algorithm
                   );

  read_conversion() //you get the idea

Mixing can be done using a fifo. It would not be hard to shadow the
OSS ioctl with similar library routines for apps that need to mix with
other apps (like desktop beeps and so forth). Serious audio apps
probably want exclusive DSP access, anyhow.

> >4. I could not find a design document for the Alsa way. "Architecture"
> >is in the name, but what is the architecture? Is it only apparent in
> >the driver sources? Alsa promises to deliver better audio performance
> >and more functionality, but how will the Alsa architecture provide
> >this?
> 
> it already has provided it. it offers generic ways to do things that
> were simply impossible or at best very tricky with OSS. the plug_hw
> layer in ALSA has no equivalent for OSS, anywhere.

Where is this 'it'. Where can I read the document?

I don't know what "plug_hw" is or what it provides. I would _love_ to
read about it. I would like to know what is impossible with OSS that
is easy with Alsa, specifically.

> >figure the design out later" approach is sometimes needed, but for an
> >ambitious idea like Alsa, with long term goals, it would be good to
> >have some kind of design thought out, and spelled out in black and
> >white.
> 
> actually, many people disagree with this. there were many changes to
> the design of ALSA that occured over the last 2 years and were
> prompted by coming to terms with what the requirements actually were,
> which in turn occured because of new types of audio interfaces
> appearing that challenged the assumptions on which OSS and earlier
> versions of ALSA were built.

Yes, sometimes you need to go back to the drawing board. I cannot say
whether Alsa needs this or not. I do find that "ever adapting" the old
code to new problems eventually finds a limit.

> >It seems to me that the main problem with OSS is the uneven quality of
> >the drivers, not the overall design. OSS would only need better
> >drivers and a user space library like alsa-lib, for rate/format
> >conversion and mixing.
> 
> there is no such library, and the programmer would have to use it
> explicitly (because of the lack of redirection i mentioned above),
> rather than implicitly.

The same may be said of Alsa: every app needs to use it. I have no
problem with this idea. I only wonder what the design of Alsa is.

If we have a good, standard, user library, then everyone will use it!

> its the overall design of OSS that is the problem - the quality of
> the drivers is generally very good.

Really? Why does not i810 offer duplex audio, then?

> > Howto use the ALSA API - Paul Davis has also written a brief explanation.
> > http://www.op.net/~pbd/alsa-audio.html
> 
> this link is not broken. it points to the new location (my ISP changed).

I followed the link to the new location, but I could not locate "Howto
use the ALSA API".

Thanks,

Richard




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Kai Vehmanen]

On Wed, 21 May 2003, Richard Cochran wrote:

> Unfair, perhaps, yet true. Getting alsa to work with a 2.4.x kernel
> today is not exactly easy.

It's not that hard either, but yes, it could be easier.
But this is true for practically all kernel subsystems
that are not yet part of the standard kernel. And for 
a reason. ALSA developers cannot change how the Linux 
kernel development works.

> I don't know what "plug_hw" is or what it provides. I would _love_ to
> read about it. I would like to know what is impossible with OSS that
> is easy with Alsa, specifically.

We'd all love to, but someone has to write it. If you can't
live without better documentation, and don't want or cannot
help, then I guess you just have to come back later when
it's ready. I'd say once ALSA is bundled by all the major
distros (some of them already do), we'll see more documentation.

This is just the same with all kernel subsystems. Very few kernel
subsystems (or specific features/modules) have very detailed architecture
descriptions available, although most of them have some docs (usually at
least a HOWTO). Even fewer have these docs _before_ they are included to
stable kernel.

Comparing to OSS is not entirely fair, as the architecture
document you are talking about documents the commercial 
OSS API, not the OSS/kernel API. It's mostly the same, but
not all OSS kernel drivers behave as the commercial OSS 
drivers, so it's not really the same (for instance the
everlasting problem with different ways to implement full-duplex).

> Mixing can be done using a fifo. It would not be hard to shadow the

Simply does not work nor scale if you want low latency and support
multichannel configurations. See the numerous discussions during the last
four to five years here, linux-audio-dev and other related mailing lists.
For real solutions, see ALSA's dmix feature (check mailing list arhives)
and/or JACK (http://jackit.sf.net).


-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Richard Cochran]

On Wed, May 21, 2003 at 07:52:46PM +0300, Kai Vehmanen wrote:
> > Mixing can be done using a fifo. It would not be hard to shadow the
> 
> Simply does not work nor scale if you want low latency and support
> multichannel configurations.

One interest of mine is real-time automatic accompaniement by
computer. I am very interested in low latency for this purpose. I
cannot imagine that a generic mixing library would reduce latency over
using a dedicated write to a dsp device! Thus I favor simple access to
the dsp hardware over using any conversion layers.

If you want generic mixing, then you must sacrifice latency. The most
efficient mixer can be achieved if the app handles the channels
itself.

Also, regarding latency, can someone point to any benchmarks/studies
contrasting OSS drivers with the corresponding Alsa drivers?

Thanks,
Richard


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Kai Vehmanen]

On Wed, 21 May 2003, Richard Cochran wrote:

> If you want generic mixing, then you must sacrifice latency. The most
> efficient mixer can be achieved if the app handles the channels
> itself.

That's just not true. Both ALSA's dmix (which is really very
very clever) and JACK provide generic mixing without increasing 
latency.

> Also, regarding latency, can someone point to any benchmarks/studies
> contrasting OSS drivers with the corresponding Alsa drivers?

Gladly, see:

http://dkc.mse.jhu.edu/~karlmac/publications/latency-icmc2001.pdf

In addition there're some notes about JACK (then known as
LAAGA). They tested OSS, but only once, as, directly 
quoting the paper:
""Only one test was done under Linux using the OSS (Open Sound System)
(www.opensound.com/oss.html) because of a lack of
reliable support for full duplex with the test system
hardware.""

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Jaroslav Kysela]

On Wed, 21 May 2003, Richard Cochran wrote:

> On Wed, May 21, 2003 at 07:52:46PM +0300, Kai Vehmanen wrote:
> > > Mixing can be done using a fifo. It would not be hard to shadow the
> > 
> > Simply does not work nor scale if you want low latency and support
> > multichannel configurations.
> 
> One interest of mine is real-time automatic accompaniement by
> computer. I am very interested in low latency for this purpose. I
> cannot imagine that a generic mixing library would reduce latency over
> using a dedicated write to a dsp device! Thus I favor simple access to
> the dsp hardware over using any conversion layers.
> 
> If you want generic mixing, then you must sacrifice latency. The most

Not really. We use a lock-free algorithm inside the dmix plugin which 
ensures that data from all clients are added independently. The latency
is equal as if you use exclusive access. Sure, there is some computing 
overhead.

> efficient mixer can be achieved if the app handles the channels itself.

Yes, that's right.

> Also, regarding latency, can someone point to any benchmarks/studies
> contrasting OSS drivers with the corresponding Alsa drivers?

If you use mmap, the both drivers will have probably same results.
The latency does not depend on used driver (if your application is 
correctly written) but much more on kernel tunning and scheduler 
behaviour.

Our aim is to describe hardware as close as possible in drivers, but in 
userspace, the alsa-lib covers the hardware differences (if required) or 
application may control all hardware features.

In other words: Do you want to play a stereo stream on some multichannel 
device? Yes, it is possible. Do you want to use all channels together?
Yes, it is possible. Do you want to separate multichannel device to mono 
devices? Yes, it is possible. Do you want to run devices from multiple 
cards in sync? Yes, it is possible (when the hardware clock is shared).

We are trying to be flexible as much as possible. I am afraid, that our
documentation is not great. My opinion is that someone other (than code
developers) should write proper documentation, because we ommit the 
fundamental details, because we think that they are obvious. 
(Un)fortunately, it is free software. We cannot force anyone to do it.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Paul Davis]

>One interest of mine is real-time automatic accompaniement by
>computer. I am very interested in low latency for this purpose. I
>cannot imagine that a generic mixing library would reduce latency over
>using a dedicated write to a dsp device! Thus I favor simple access to
>the dsp hardware over using any conversion layers.

with all due respect, i don't think you understand what causes
latency. it has much less to do with "code speed" and much more to do
with "code design".

>If you want generic mixing, then you must sacrifice latency. The most
>efficient mixer can be achieved if the app handles the channels
>itself.

you are seem to be using two different definitions of mixing: you
originally talked about using FIFOs in the context of multi-app
mixing, now you appear to be talking about mixing within an
application.

obviously, an app that does its own mixing should do its own
mixing. this is a totally different problem from how to get N apps to
route their output to a given audio interface.

>Also, regarding latency, can someone point to any benchmarks/studies
>contrasting OSS drivers with the corresponding Alsa drivers?

there is no significant difference if the drivers are both written
correctly. thats again because latency isn't about code but the
parameters the device is set up with. 

--p


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Paul Davis]

>Unfair, perhaps, yet true. Getting alsa to work with a 2.4.x kernel
>today is not exactly easy.

would you like the two people who work on ALSA to write documentation,
or to work on this aspect of things?

>I don't agree that OSS conversion would have to be in the kernel. You
>could simply pipe all of your audio through sox using simple shell
>commands! Clunky, yes, but it would work.

clunky? i thought you were interested in serious audio programming!

>More to the point, I can imagine a user library to provide:
>
>  write_conversion(int fd, //open file descriptor
>                   void* buf, //samples to write
>                   int buflen, //length of buffer
>                   sometype fmtin, //format of buffer
>                   sometype fmtout, //desired conversion
>                   sometype alg //desired conversion algorithm
>                   );
>
>  read_conversion() //you get the idea

i don't think you don't get the point. this means that you are now
required to use these calls, rather than write() and read(), unless
you first query the device to see what it can do (for example, my
favorite interfaces support *only* 24-in-32-bit non-interleaved
samples. why should you have to know this? why not just write the same
code regardless of what the hardware can do? thats what ALSA allows
for. 

also, you seemed to like the idea of using read and write, and now
you're already moving away from it. where you'll end up with this
approach is probably going to be a lot like snd_pcm_read() and
snd_pcm_write() (although be sure to consider how to handle
interleaved and non-interleaved samples, writing to just one channel, etc).

>Mixing can be done using a fifo. 

no disrespect intended, but you are obviously new to audio
programming. FIFO's hold 5kB of data, which for a 26 channel interface
using 32 bit samples is about 0.5msecs worth of audio. even my
carefully tuned system could not possibly use such a model.

>				  It would not be hard to shadow the
>OSS ioctl with similar library routines for apps that need to mix with

ah, shadowing again. so you end up with snd_pcm_ioctl() ... but what
ioctl calls are there? why should you even care? you have data to
write, you should write it, and let someone/something else care about
the low level details.

>other apps (like desktop beeps and so forth). Serious audio apps
>probably want exclusive DSP access, anyhow.

see http://jackit.sf.net/apps. these are all serious audio apps and
when they use JACK, none of them even know whether there a real audio
interface involved. you can run any number of them at once (within
system-imposed limits).

>> it already has provided it. it offers generic ways to do things that
>> were simply impossible or at best very tricky with OSS. the plug_hw
>> layer in ALSA has no equivalent for OSS, anywhere.
>
>Where is this 'it'. Where can I read the document?

"it" is ALSA. and there is no such document.

>Yes, sometimes you need to go back to the drawing board. I cannot say
>whether Alsa needs this or not. I do find that "ever adapting" the old
>code to new problems eventually finds a limit.

precisely, and thats OSS problem, not ALSA's. ALSA has been
significantly redesigned twice during its development, with much more
change than OSS has seen in its entire life. is that a good feature of
OSS? perhaps, but for most of us, we'd prefer useful functionality
from a capable API, even if we've had to wait for a couple of years to
get it.

>If we have a good, standard, user library, then everyone will use it!

not necessarily. none of my audio apps use ALSA at all. they all route
via JACK ....

>> its the overall design of OSS that is the problem - the quality of
>> the drivers is generally very good.
>
>Really? Why does not i810 offer duplex audio, then?

i said the OSS drivers were generally very good.

>> > Howto use the ALSA API - Paul Davis has also written a brief explanation.
>> > http://www.op.net/~pbd/alsa-audio.html
>> 
>> this link is not broken. it points to the new location (my ISP changed).
>
>I followed the link to the new location, but I could not locate "Howto
>use the ALSA API". 

your browser should have taken you there. unfortunately, there was a
bug in the script that converted all my old HTML documents to the
redirect docs, and i no longer can access files at www.op.net, so the
final link that appears to go to the document doesn't go directly there.

if you did go there (http://equalarea.com/paul/alsa-audio.html), then
we i guess disagree on what a "brief explanation" is.

--p



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Richard Cochran]

On Wed, May 21, 2003 at 01:03:54PM -0400, Paul Davis wrote:
> would you like the two people who work on ALSA to write documentation,
> or to work on this aspect of things?

Are there really only two? That's too bad.

> your browser should have taken you there. unfortunately, there was a
> bug in the script that converted all my old HTML documents to the
> redirect docs, and i no longer can access files at www.op.net, so the
> final link that appears to go to the document doesn't go directly there.
> 
> if you did go there (http://equalarea.com/paul/alsa-audio.html), then
> we i guess disagree on what a "brief explanation" is.

Thanks for the link,

Richard





-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Patrick Shirkey]

I have made some changes to the documentation page based on info in this 
thread.

updated dead links and added more info for developers.

HTH.

-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Richard Cochran]

On Wed, May 21, 2003 at 11:24:35AM -0400, Paul Davis wrote:
> Nobody disagress with the sentiment of the original poster. At least a
> half-dozen to a dozen people have wandered onto this list and said
> they would write documentation. It hasn't happened. Why? Its not
> because its considered to be useless. It hasn't happened because
> nobody has the time or inclination to write it. So far. Thats
> all. There is no opposition to higher level documentation, only a lack
> of time or motivation.

It is really hard to write higher level documentation after the
project is finished!

With a name like "Advanced Linux Sound Architecture", I would expect
to be able to read about:

1. What is advanced (over OSS) in Alsa?

2. What is the architecture?

Any pointers (white papers, articles, email postings, anything!) to
material on these questions would be appreciated.

Thanks again,

Richard





-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Paul Davis]

>With a name like "Advanced Linux Sound Architecture", I would expect
>to be able to read about:

why? why do you think it is possible to design a system like ALSA
ahead of time? we didn't even know what was necessary at the
beginning. we still don't entirely know that the API is "complete",
but given that we have some fairly sophisticated apps (Rosegarden,
MusE, Ardour) using it, and a wide range of audio interfaces
supported, there is some reasonable level of confidence that its
right. 

If you had been reading alsa-devel during the period of the initial
development of Ardour and then later JACK, you would have seen that
many architectural decisions in ALSA reflect real-world experience
writing audio applications, rather than guessing at what might be
useful in the absence of such applications.

>1. What is advanced (over OSS) in Alsa?

* kernel-space supports only h/w-level capabilities
* multi-thread safe design
* transparent use of plugin architecture to handle
      format,rate,channel cnt and many other conversions
* support for non-interleaved interfaces
* user-space software mixing (dmix)
* user-space "loopback/snoop" capabilities
* merging multiple cards into a single virtual device
* hiding non-ALSA-drivers behind a consistent
     user-space API (e.g. IEEE1394 drivers, or JACK)
* consistent and generic control API for managing h/w controls
* sufficiently flexible mixer architecture to handle modern
     audio interfaces fully (rather than reducing them to 
     a simplistic device)
* consistent support for multiple instances of the same card
* linked operations of multiple cards

and more.

>2. What is the architecture?
>
>Any pointers (white papers, articles, email postings, anything!) to
>material on these questions would be appreciated.

AFAIK, there is no such material. 


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

PCI write barrier

[Giuliano Pochini]

I was reading this: http://people.redhat.com/arjanv/olspaper.pdf. It
says (page 4, par5.1) the PCI controller is allowed to delay writes
as long as it likes and a read operation flushes all pending writes.
Is it true ?  I had a quick look at some ALSA drivers, but I couldn't
find any barrier or any apparent useless read after a write.


Bye.



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: PCI write barrier

[Takashi Iwai]

At Thu, 22 May 2003 15:16:44 +0200 (CEST),
Giuliano Pochini wrote:
> 
> 
> I was reading this: http://people.redhat.com/arjanv/olspaper.pdf. It
> says (page 4, par5.1) the PCI controller is allowed to delay writes
> as long as it likes and a read operation flushes all pending writes.
> Is it true ?  I had a quick look at some ALSA drivers, but I couldn't
> find any barrier or any apparent useless read after a write.

you are right.
this issue is not taken into account in most of drivers codes, in the
case of non-memory-mapped access.

i think this should be solved in the kernel core side, e.g. providing
special pci access functions set, though.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Takashi Iwai]

At Wed, 21 May 2003 12:09:28 -0400,
Richard Cochran wrote:
> 
> On Wed, May 21, 2003 at 11:24:35AM -0400, Paul Davis wrote:
> > Nobody disagress with the sentiment of the original poster. At least a
> > half-dozen to a dozen people have wandered onto this list and said
> > they would write documentation. It hasn't happened. Why? Its not
> > because its considered to be useless. It hasn't happened because
> > nobody has the time or inclination to write it. So far. Thats
> > all. There is no opposition to higher level documentation, only a lack
> > of time or motivation.
> 
> It is really hard to write higher level documentation after the
> project is finished!
 
oh, already finished?  i didn't know.
version 1.0 is the "starting point", i'd like to call :)

> With a name like "Advanced Linux Sound Architecture", I would expect
> to be able to read about:
> 
> 1. What is advanced (over OSS) in Alsa?
> 
> 2. What is the architecture?

many people already explained about the first point, so i won't say
much.  the following points are however still noteworthy:


- ALSA is not only the driver.

  ALSA consists of ALSA drivers, ALSA libraries and some utilities.
  that's why ALSA stands for "architecture".

  hence, comparison only the ALSA driver with OSS makes no sense at
  all.  as you know, OSS is only the driver.  (i know there is liboss,
  but AFAIK, no one uses it.)

  using sox or your own library is, of course, a workaround for OSS.
  but then you need extra things apart from the standard -- that is,
  it's no longer OSS itself.


- ALSA model is still Unix style (somehow).

  it's still based on open/close/read/write style (except for mmap).
  you'll need ioctl additionally to set up, but it's anyway necessary
  for "normal" OSS apps.
  

- ALSA library is the low-level library.

  ALSA-lib is written to cover the whole functionality of ALSA
  kernel drivers, plus the user-space extensions (such as plugins) and
  user-drivers.

  sure, OSS API is much simpler and easier to understand.
  it's because OSS API provides only too simple models and functions,
  which are not applicable to professional audio software.

  the ALSA-lib is not what makes programming easier but provides you
  the fundamental to access the ALSA system.  there are so many
  functions which are usually not necessary.
  you can see some analogy to Xlib -- you can write apps with it, but
  it's not easy as you think (although the minimal codes wouldn't be
  too difficult).


i personally do NOT recommend to write EVERYTHING with ALSA-lib.
it would be much better to have a higher-level abstraction library,
just like many graphic toolkit libraries do.  then you can hide the
complex things in a higher library without knowing the detail of
lowlevel implementations.

so, to my eyes, the real problem is that there are not many such
libraries yet.  of course, the documentation is inevitablly
necessary -- i mean apart from that.


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Jaroslav Kysela]

On Thu, 22 May 2003, Takashi Iwai wrote:

> i personally do NOT recommend to write EVERYTHING with ALSA-lib.
> it would be much better to have a higher-level abstraction library,
> just like many graphic toolkit libraries do.  then you can hide the
> complex things in a higher library without knowing the detail of
> lowlevel implementations.
> 
> so, to my eyes, the real problem is that there are not many such
> libraries yet.  of course, the documentation is inevitablly
> necessary -- i mean apart from that.

The question is, if we have to create another library or integrate "basic" 
API for simple applications inside alsa-lib.

I think that most of applications are simple players or recorders. Then we 
might design very simple API which can have some similar functionality as 
OSS for developers recoding the OSS applications or for developers 
expecting very simple API.

I see three groups of applications:

1) players (expecting mostly stereo output, maybe 4.0 and 5.1 or simple multichannel)
2) recorders (expecting mostly stereo input - might be enhanced to any number of channels)
3) full-duplex (same requirements as players or recorders)

All groups also usually want to control the mixer settings. We have 
already requests from audio conference tool developers to integrate
such feature to our API. Actually, there is no direct connection between 
PCM outputs and mixer settings. These applications don't want to handle 
many controls. I think that these will be quite sufficient:

1) Master Playback Volume
2) PCM Playback Volume
3) Capture Gain
4) Capture Source (Mic, Line, Aux - might be enumerated)
5) Playback -> Capture Loopback Switch (to disable echo for conferences 
   and other tools)

All these controls are quite abstract and some hardware might have 
missing some of them or the routing might be very complex.

The main goals for simple interfaces should be:

1) offer unified simple abstract way
2) offer to describe (user might change it) the relations 
   between simple abstract and HAL (current alsa-lib)

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Pieter Palmers]

Jaroslav Kysela wrote

>The question is, if we have to create another library or integrate "basic" 
>API for simple applications inside alsa-lib.
>
>I think that most of applications are simple players or recorders. Then we 
>might design very simple API which can have some similar functionality as 
>OSS for developers recoding the OSS applications or for developers 
>expecting very simple API.
>
>I see three groups of applications:
>
>1) players (expecting mostly stereo output, maybe 4.0 and 5.1 or simple multichannel)
>2) recorders (expecting mostly stereo input - might be enhanced to any number of channels)
>3) full-duplex (same requirements as players or recorders)
>
>All groups also usually want to control the mixer settings. We have 
>already requests from audio conference tool developers to integrate
>such feature to our API. Actually, there is no direct connection between 
>PCM outputs and mixer settings. These applications don't want to handle 
>many controls. I think that these will be quite sufficient:
>
>1) Master Playback Volume
>2) PCM Playback Volume
>3) Capture Gain
>4) Capture Source (Mic, Line, Aux - might be enumerated)
>5) Playback -> Capture Loopback Switch (to disable echo for conferences 
>   and other tools)
>
>All these controls are quite abstract and some hardware might have 
>missing some of them or the routing might be very complex.
>
>The main goals for simple interfaces should be:
>
>1) offer unified simple abstract way
>2) offer to describe (user might change it) the relations 
>   between simple abstract and HAL (current alsa-lib)
>
>						Jaroslav
>  
>
Totally unproductive remark: this is a great idea.

More productive (mabye): In my opinion it should also be possible to mix 
both simple API & complex API. Sometimes all you need is the simple API 
functionallity, but for one function/method/action that isn't included 
in this simple API. It would be a pitty if this one thing should prevent 
developers to use the complex API for all of the work. Maybe this is an 
obvious remark, but nevertheless I think it's important.

Pieter




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Richard Cochran]

Thanks to all who wrote about how Alsa works. If you collect these
facts together, you have the beginnings of a design document! When I
finally undertake to understand Alsa (a daunting task), I will be
happy to reconstruct an architecture description for Alsa.

Let me summarize what I have learned (please comment if needed):

1. Alsa has clearly stated feature and performance goals. However,
there is no overall design document (block diagram, notes on a napkin,
etc) describing how the architecture will reach these goals. Some of
the design may be gleened from the list archives, or from reading
example programs and Alsa sources.

2. Alsa is being developed by a very small number of people (a good
thing, IMHO). These same people are actively involved in major audio
software projects for this platform. The actual direction of the Alsa
development comes from practical experience with these apps.

3. Alsa has gone through substantial rewrites. The latest version is
fairly stable, however.

4. One of the major advantages of Alsa is the transparent conversion
and mixing library. The same functionality is provided in a different
way by JACK.

5. The latency (time from write() to DAC, or from ADC to read()) is
not worse using the Alsa API and drivers as compared with OSS API and
drivers.

I have two additional questions:

On Thu, May 22, 2003 at 02:47:27PM +0200, Takashi Iwai wrote:
> - ALSA is not only the driver.
> - ALSA model is still Unix style (somehow).
> - ALSA library is the low-level library.

Are the calls snd_pcm_* kernel calls or library calls? If the latter,
where is the library-kernel API?

When using the Alsa OSS compatibility layer, is there a performace
penalty in terms of latency?

Will OSS support likely be dropped in kernel 2.6?

How are the OSS drivers "thread unsafe", or rather, what are the
thready safety issues that Alsa addresses?

Thanks,

Richard


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Takashi Iwai]

At Thu, 22 May 2003 10:18:23 -0400,
Richard Cochran wrote:
> 
> I have two additional questions:
> 
> On Thu, May 22, 2003 at 02:47:27PM +0200, Takashi Iwai wrote:
> > - ALSA is not only the driver.
> > - ALSA model is still Unix style (somehow).
> > - ALSA library is the low-level library.
> 
> Are the calls snd_pcm_* kernel calls or library calls?

they are library calls.

> If the latter,
> where is the library-kernel API?
 
this is not documented.
and you should not communicate directly with the drivers.

the kernel API might be changed in future because of further
extensions.  in that case, the alsa-lib will absorb the change of
kernel API, so that the ALSA library API keeps unchanged.

hence, it's not necessary for audio application programmers to know
the kernel API (except for the curiosity :)


btw, i forgot to mention that there are some slides of my talk in LAD
meeting:
	http://www.alsa-project.org/~iwai/lad2003/lad.html


> When using the Alsa OSS compatibility layer, is there a performace
> penalty in terms of latency?

usually, no.

> Will OSS support likely be dropped in kernel 2.6?

no.  very unlikely.

> How are the OSS drivers "thread unsafe", or rather, what are the
> thready safety issues that Alsa addresses?

well, i don't think the OSS drivers are "thread unsafe" but might be
SMP unsafe or ineffective.  some OSS drivers are written on the
assumption of UP (and some are not).

ALSA has the common middle layer, and it is written carefuly to
support SMP systems.


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Jack O'Quin]

Takashi Iwai <tiwai@suse.de> writes:

> btw, i forgot to mention that there are some slides of my talk in LAD
> meeting:
> 	http://www.alsa-project.org/~iwai/lad2003/lad.html

These are very good, Takashi-san.  

Someone wanting to contribute documentation would do well to use your
slides as the basis for an Architecture Document.  They have good
diagrams.
-- 
  Jack O'Quin
  Austin, Texas, USA


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Patrick Shirkey]

Takashi Iwai wrote:

> 
> btw, i forgot to mention that there are some slides of my talk in LAD
> meeting:
> 	http://www.alsa-project.org/~iwai/lad2003/lad.html
> 
> 


I added a new section for presentations which is currently linked to the 
LAD page for the Karlsruhe meeting.

This also provides notes, pics and .ogg files.

Should've clicked about this earlier. Doh.

-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: documentation - yeah right!

[Richard Cochran]

On Thu, May 22, 2003 at 05:33:12PM +0200, Takashi Iwai wrote:
> btw, i forgot to mention that there are some slides of my talk in LAD
> meeting:
> 	http://www.alsa-project.org/~iwai/lad2003/lad.html

Thanks, these answer a good deal of my questions!

Richard


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

i810 - no sound from cvs snapshot

[Richard Cochran]

I post this here because I _want_ to contribute to alsa development,
but I never can get alsa working to even begin. And no, I'm not a
moron (I hope). Here is what I did:

1. I got the 2003-06-29.tar file, and I was pleased and suprised when
it compiled without errors (except alsa-tools, but that looks
unimportant).

2. I ran alsa-driver/snddevices.

3. I loaded the modules:  lsmod |grep snd
snd-intel8x0           17888   0 
snd-mpu401-uart         3584   0  [snd-intel8x0]
snd-rawmidi            14304   0  [snd-mpu401-uart]
snd-seq                41580   0  (unused)
snd-seq-device          4212   0  [snd-rawmidi snd-seq]
snd-ac97-codec         36368   0  [snd-intel8x0]
snd-pcm                66080   0  [snd-intel8x0]
snd-page-alloc          6116   0  [snd-intel8x0 snd-pcm]
snd-hwdep               5280   0 
snd-timer              16448   0  [snd-seq snd-pcm]
snd                    35424   0  [snd-intel8x0 snd-mpu401-uart snd-rawmidi snd-seq snd-seq-device snd-ac97-codec snd-pcm snd-hwdep snd-timer]

4. Installed alsa-lib into /usr/local.

5. Ran 'aplay -D hw:0,0 alone.wav', this produces:

ALSA lib pcm_hw.c:1055:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Invalid argument
aplay: main:484: audio open error: Invalid argument

What am I doing wrong? Thanks,

Richard

Other diagnostics:

ls -l /dev/snd/pcmC0D0p
crw-rw----    1 root     audio    116,  16 Jul  5 07:34 /dev/snd/pcmC0D0p

tail syslog
Jul 10 20:10:59 muse kernel: PCI: Enabling device 00:1f.5 (0000 -> 0001)
Jul 10 20:10:59 muse kernel: PCI: Setting latency timer of device 00:1f.5 to 64
Jul 10 20:10:59 muse kernel: intel8x0: clocking to 48000
Jul 10 20:11:36 muse kernel: ALSA pcm_native.c:1789: BUG? (err >= 0) (called from d8922afa)
Jul 10 20:11:36 muse kernel: ALSA pcm_native.c:1923: snd_pcm_hw_constraints_complete failed

cat /proc/asound/cards   
0 [I82801CAICH3   ]: ICH - Intel 82801CA-ICH3
                     Intel 82801CA-ICH3 at 0x1c00, irq 9

cat /proc/asound/pcm     
00-00: Intel ICH : Intel 82801CA-ICH3 : playback 1 : capture 1



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1