From: Takashi Iwai <tiwai@suse.de>
To: mjander@users.sourceforge.net
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: The ALSA Situation
Date: Fri, 12 Nov 2004 14:44:10 +0100 [thread overview]
Message-ID: <s5hy8h7dvx1.wl@alsa2.suse.de> (raw)
In-Reply-To: <1100213567.2076.29.camel@localhost>
At Thu, 11 Nov 2004 19:52:47 -0300,
Manuel Jander wrote:
>
> Hi,
>
> On Thu, 2004-11-11 at 17:34 +0100, Takashi Iwai wrote:
> > At Wed, 10 Nov 2004 22:42:20 -0800 (PST),
> > Linus Torvalds wrote:
> > >
> > > On Thu, 11 Nov 2004, Jaroslav Kysela wrote:
> > > >
> > > > Unfortunately, the application will have to settle other real-time
> > > > parameters (including stream parameters, i/o chunk sizes etc.), so we must
> > > > drain on close() the complete stream and not allow intermixing requests
> > > > from applications.
> > >
> > > That seems to be a misdesign of the interfaces, but whatever.
> >
> > 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.
>
> There 2 situations (AFAIK):
>
> 1) * Stinking intel8x0 or similar card with only one stereo stream:
> - Device should be accessed as 48KHz 16 bit stereo (highest quality
> available), since it most probably does not even have a samplerate
> converter.
No, most of boards have SRC (on AC97 chip). The board without SRC is
rare nowadays.
> There should be no concern about latency/buffer size, thats
> just silly in such a kind of device. Just use the most efficient DMA
> setup.
> - All applications using the device should be softmixed. It does not
> make any sense to give direct access to applications.
IMO, it's too narrow-sighted. You can't say that no user wants the
low-latency system like JACK for an onboard chip. There definitely
are (imagine laptop users).
But for _normal_ apps, yes, they should all use the softmix.
> 2) * Multichannel card:
> - Use one channel for softmixing (reserved for ever for that purpose,
> at highest audio quality). Just the same as for the single channel card.
> - Use a "Resource Manager" that assigns hardware channels as are
> available, and choose the softmixing engine coupled to the reserved
> channel when we get out of hardware channels.
> - If we want to make this even nicer, and thinking in the future
> where hardware channels may have (they actually have, but are not
> supported) advanced processing features, the "Resource Manager" could
> assign hardware channels on behalf of the features the applications asks
> for. For example if a application does not ask for HRTF processing, give
> it a softmixing channel, or a hardware channel lacking that feature.
The multichannel cards have usually no hardware mixing. They provide
one DMA for all channels, either interleaved or non-interleaved.
So, decoupling these channels means that one has to grab all channels
exclusively and distribute them. The situation is pretty similar like
the first case, anyway.
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-12 13:44 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
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 [this message]
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=s5hy8h7dvx1.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=mjander@users.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox