From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: The ALSA Situation Date: Fri, 12 Nov 2004 09:57:55 +0100 Message-ID: References: <200411102113.iAALDLUN001061@localhost.localdomain> <1100212487.2076.13.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: <1100212487.2076.13.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: Linus Torvalds , alsa-devel List-Id: alsa-devel@alsa-project.org At Thu, 11 Nov 2004 19:34:46 -0300, Manuel Jander wrote: > > Hi > > On Thu, 2004-11-11 at 10:23 -0800, 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. > > At last somebody agree :) Frankly IMHO, setting buffer sizes in a sound > application, seemed always pretty silly thing to me. Its too much > hardware dependant, to be done inside a user application; sort of out of > scope. Hmm, the minimal setting ALSA API requires is not so much: the sample format, rate, channels, access mode, buffer/period sizes. I believe these except buffer/period sizes are almost mandatory in every (native) audio API. (Of course, the system like JACK is another story. It converts everything by itself.) > > 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. > > Yes, that would be very, very nice. At most, user program should have > the ability to ask for less_latency or longer_buffering, because that > relationship obviously is a tradeoff between 2 goodnesses. But most > current "options" don't actually provide any benefit. If choosen wrong, > sound output may even not work correctly. > The less options -> the more likelyhood that it will work (just works > paradigm). Here agreed. The buffer configuration can be more simplified. Having default values for the templates ("minimal latency" or "robust playback") would be nice. 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