From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: The ALSA Situation Date: Thu, 11 Nov 2004 18:25:36 +0100 Message-ID: References: <200411102113.iAALDLUN001061@localhost.localdomain> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: 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: Linus Torvalds Cc: Jaroslav Kysela , Paul Davis , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.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