At Tue, 18 May 2004 09:30:54 -0400, Manuel Jander wrote: > > Hi, > > On Tue, 2004-05-18 at 15:46 +0200, [EMAIL PROTECTED] wrote: > > On Thu, 13 May 2004, Adam Tla/lka wrote: > > > > > On Wed, May 12, 2004 at 05:40:55PM +0200, Clemens Ladisch wrote: > > > > > > ALSA is complicated and we have no good manual describing proper use > > > of its api. You can easily prove this: many programs have ALSA output > > > modules but they are working worse then when using OSS. > > > For example mplayer with OSS synchronizes video and sound much faster > > > in case of network streaming. XMMS is broken too. > > ?? mplayer isn't broken in any way with alsa. it supports alsa since the > > early days and also current versions very well. please don't talk > > bullshit. > > it probably does av-sync faster at some particular streams (what ever you > > mean with that) with oss, but i never ever saw some significant > > performance differences compared to oss. > > at least it supports real mmaped-io for up to 2 channels. > > > > Unfortunately i have to agree with Clemens. In my opinion the ALSA API > is giving the applications too much freedom in choosing parameters and > does not enforce any restrictions on hardware that can't support them.
basically, such a restriction is up to the driver. in the ideal world, hw_constraints should be able to handle these cases properly... > As the main author of the Aureal Vortex driver, its very stupid having > to handle arbitrary period sizes, introducing a lot of overhead and > complexity in the driver, while the hardware just is not designed to > handle period sizes that are not powers of two, due to page boundary > overlapping trouble. Obviously as a result, OSS works much better, since > it almost ever chooses the biggest buffer possible, resulting in a sane > period size. Period sizes of 314.15.14 bytes are just silly, plain > stupid. The user won't notice any difference if its 256 instead, but > since the app insist in such period sizes it just fails, and the user > gets no sound all. The behaviour of the user application in the end > depends too much on the hardware it is running on. first, the power of two is not a golden rule for every sound chip. for some chips, it's difficult to handle such period/buffer sizes. in theory, we can set the hw_constraint for the buffer/period sizes in power of two. yes, i tried it, but it failed. this is because ALSA handles the buffer/period sizes in two different units, frames and time in msec. IMO, it was a wrong decision to use different units for the single purpose. maybe we need a workaround not to mix up these units in the configurator. > AFAIK, the ICE1712 has exactly the same hardware restriction. I know > that the via driver does cope with this, but that particular hardware > has special hardware resources for such a thing, where other hardware > don't. ICE1712 has no problem regarding this. its problem is that the max. buffer size is 64k even though it always uses 32bit x 10 channels. > The cost of allowing any parameter value is not worth it in my opinion. > Its actually causing a lot of trouble. not all parameters are accepted. it depends on the driver implementation. please don't misunderstand: i don't mean that the current ALSA design is perfect. it's not at all, as you know :) however, the basic design of ALSA is that it leaves such a reststriction purely to the driver implementation. if your driver allows everyhing, it's the driver's responsibility to support everyhing. unfortunately, the power-of-two restriction doesn't work well because of the failure of configurator. it's an exceptional case. Takashi ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
