From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: The ALSA Situation Date: Fri, 12 Nov 2004 14:44:10 +0100 Message-ID: References: <200411102113.iAALDLUN001061@localhost.localdomain> <1100213567.2076.29.camel@localhost> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <1100213567.2076.29.camel@localhost> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: mjander@users.sourceforge.net Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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