Re: [PATCH] More ioctls for VIA sound driver, Flash 5 now fixed

[Pavel Roskin]

Hi, Jeff!

> > Flash 5 plugin plays just fine after applying the patch (check e.g.
> > http://wcrb.com/sparks.html)
> 
> Thanks, applied.
> 
> I always thought SNDCTL_DSP_NONBLOCK was stupid and never implemented
> it, since the same can be accomplished via fcntl(2).  But not only this
> but also some soundmodem utilities require this ioctl.  Sigh.  :)

I'm more surprised that every driver should implement those ioctls
individually.  There is no common ioctl handler for non-OSS based drivers.
There is almost no code sharing between sound drivers.  As a result, every
driver comes with it's unique set of bugs and limitations :-)

I just hope that ALSA will solve this problem.  

Here's another unique limitation of of the VIA driver.  The maximal
fragment size is limited to PAGE_SIZE (scan for VIA_MAX_FRAG_SIZE).  This
is just 4k.  Flash plugin version 4 (not 5) tries to set fragment size to
8k, but doesn't check the result and plays the sound at "double speed".  
I believe that it plays the first half of every fragment.

A workaround that actually works is to replace PAGE_SIZE with 
(2*PAGE_SIZE) and PAGE_SHIFT with (PAGE_SHIFT+1).

For comparison, ymfpci.c allows fragment size up to 32k.  It also tries to 
allocate 32k first (see DMABUF_DEFAULTORDER), then 16k, 8k and finally 4k.

Perhaps the same could be done in the VIA driver.  But maybe there is some 
real reason to limit fragments to 4k?  Is there anything special with 4k 
apart from it being PAGE_SIZE on i386?

4k-sized buffers for the current chan->frag_number and chan->frag_size.  
This is very different from other drivers that try to allocate one
contiguous buffer as big as the system allows and then limit the fragment
size accordingly.

I understand that Flash 4 is obsoleted by Flash 5 that now works, but 
who knows if other programs need large fragments?  Do you think it should 
be fixed?  What do you think would be the right fix?

-- 
Regards,
Pavel Roskin