From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: The ALSA Situation Date: Fri, 12 Nov 2004 09:51:52 +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 10:23:44 -0800 (PST), Linus Torvalds wrote: > > On Thu, 11 Nov 2004, Takashi Iwai wrote: > > > > Oh, that's hard to tell what should be the "default" parameters. > > This strongly depends on the board. > > Which is exactly why apps should not even try to set them. > > My point is that the driver can select some default parameters, and then > users just use them by default, and thus there are no issues of > synchronizing between them. The parameters a board supports are not unique. For example, suppose a card supporting 8bit and 16bit samples. An app using 8bit format ran once, then you want to play an mp3 after that. Should the driver keep the last 8bit format? Or, the driver shouldn't have accepted 8bit (thus convert it in software - i.e. no mmap) even though it's natively supported? So, the minimal setting such as the sample format, rate, channels, etc are still required to be set by applications although I agree that the configuration of buffer/period sizes can be more simplified. > > ALSA tries to provide as much function as possible. This results in > > variety of configurations, i.e. the famous complexity. > > That may or may not be a valid excuse. Agreed :) > Complexity also often arises from bad decisions. And the decision to only > have one user open at a time appears like a pretty fundamentally bad one. If you mean the blocking behavior, I agree. I myself don't like it, too. But, solving the concurrent access in another way in the *driver level* (the intermediate buffer or the soft-mixing) doesn't sound good to me. It brings more complexity than the simple -EBUSY strategy. 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