From: Takashi Iwai <tiwai@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Jaroslav Kysela <perex@suse.cz>,
Paul Davis <paul@linuxaudiosystems.com>,
alsa-devel@lists.sourceforge.net
Subject: Re: The ALSA Situation
Date: Thu, 11 Nov 2004 18:25:36 +0100 [thread overview]
Message-ID: <s5hhdnwfgbz.wl@alsa2.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0411110855380.2301@ppc970.osdl.org>
At Thu, 11 Nov 2004 08:58:28 -0800 (PST),
Linus Torvalds wrote:
>
> On Thu, 11 Nov 2004, Takashi Iwai wrote:
> >
> > Well, the contiguous use of a stream isn't easy as it sounds.
> > Since each app wants different buffer size, period (fragment) size,
> > sample format, sample rate etc, the configuration must be reset
> > totally at each time. This eventually requires to stop of the DMA.
>
> ... and the sane thing to do would be to let apps use default parameters,
> and _encourage_ that, so that they only have problems if they want to do
> something strange.
Oh, that's hard to tell what should be the "default" parameters.
This strongly depends on the board.
Then, the arising question is somewhat philosophical - should we
provide more functions or less functions the chip supports?
ALSA tries to provide as much function as possible. This results in
variety of configurations, i.e. the famous complexity.
If we provide the limited functions, the API would be much easier just
like OSS.
> > It's possible to check the condition and contine if it's identical
> > with the previous one, though. But I feel it's overdesigned as the
> > driver. A practical way to avoid popping would be the damping as
> > Fernando suggested (if h/w doesn't support soft-muting).
>
> The popping is just a small thing. The bigger thing is that people want to
> have a sound device open and send occasional beeps to it and things.
> Without having to wait for everybody else to close their stream.
>
> If a window manager can't send a beep because the user is listening to
> music, that's a bad thing. If the interfaces are designed so that the
> trivial case is hard, that's a bad thing. And it sounds like they are.
The cocurrent access like beep can be solved by using a certain middle
layer instead of accessing the sound device directly. For example,
most of desktop systems use a sound server like arts and esd. Or, if
all the app run using ALSA API, they can live with the ALSA softmixing
in a peaceful world.
However, when different sound systems run at the same time, the world
peace is broken. Each tries to grab the device exclusively.
I really wish that all these stuff will be based on a common library
which absorbs the difference of APIs. Also, the use of the middle
layer library reduces the difficulty of the audio programming.
Takashi
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
next prev parent reply other threads:[~2004-11-11 17:25 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-10 0:24 The ALSA Situation Eugenia Loli-Queru
2004-11-10 1:50 ` Paul Davis
2004-11-10 2:38 ` Eugenia Loli-Queru
2004-11-10 2:55 ` Paul Davis
2004-11-10 5:59 ` Lee Revell
2004-11-10 23:22 ` James Courtier-Dutton
2004-11-10 10:57 ` Jaroslav Kysela
2004-11-10 16:09 ` Lee Revell
2004-11-10 16:43 ` Linus Torvalds
2004-11-10 17:30 ` Takashi Iwai
2004-11-10 18:08 ` Linus Torvalds
2004-11-10 17:45 ` Jaroslav Kysela
2004-11-10 18:15 ` Linus Torvalds
2004-11-10 18:41 ` Paul Davis
2004-11-10 19:09 ` Linus Torvalds
2004-11-10 21:13 ` Paul Davis
2004-11-10 22:34 ` Linus Torvalds
2004-11-10 23:53 ` Fernando Pablo Lopez-Lezcano
2004-11-11 6:32 ` Jaroslav Kysela
2004-11-11 6:42 ` Linus Torvalds
2004-11-11 16:34 ` Takashi Iwai
2004-11-11 16:58 ` Linus Torvalds
2004-11-11 17:25 ` Takashi Iwai [this message]
2004-11-11 18:23 ` Linus Torvalds
2004-11-11 22:34 ` Manuel Jander
2004-11-12 8:57 ` Takashi Iwai
2004-11-12 8:51 ` Takashi Iwai
2004-11-12 15:50 ` Linus Torvalds
2004-11-12 22:06 ` Florian Schmidt
2004-11-13 1:15 ` Manuel Jander
2004-11-13 10:38 ` Jaroslav Kysela
2004-11-14 4:00 ` Manuel Jander
2004-11-20 2:16 ` Configuration system and Resource Manager. Was: " Manuel Jander
2004-11-13 10:42 ` Jaroslav Kysela
2004-11-13 12:11 ` Florian Schmidt
2004-11-13 18:01 ` Linus Torvalds
2004-12-02 1:48 ` Florian Schmidt
2004-11-12 9:07 ` Giuliano Pochini
2004-11-11 22:52 ` Manuel Jander
2004-11-12 13:44 ` Takashi Iwai
2004-11-10 22:00 ` Hannu Savolainen
2004-11-10 17:13 ` Giuliano Pochini
[not found] <20041110235502.6C8211D2B2D@sc8-sf-uberspam1.sourceforge.net>
2004-11-11 8:56 ` Andreas Mohr
2004-11-11 15:50 ` Manuel Jander
[not found] <20041112040611.8390B1D2669@sc8-sf-uberspam1.sourceforge.net>
2004-11-12 8:24 ` Andreas Mohr
2004-11-12 13:33 ` Manuel Jander
2004-11-12 15:06 ` Clemens Ladisch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hhdnwfgbz.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=paul@linuxaudiosystems.com \
--cc=perex@suse.cz \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.