uaudio patch, configurable buffer size

[Mathew Kanner]

On Mar 06, Alexander Leidinger wrote:
> On Sat, 5 Mar 2005 17:40:05 -0500
> Mathew Kanner <mat at cnd.mcgill.ca> wrote:
> 
> > Hi All,
> > 	I couldn't use my usb device because the default buffer size
> > (16*1024 bytes) was too much to be allocated (dma changes that
> > happened a while ago).  The following is a patch to make it a tunable:
> > 
> > http://www.cnd.mcgill.ca/~mat/uaudio-HEAD-buffersize-tunable.diff.gz
> 
> There's an open PR about it. It changes the buffer size. AFAIR it also
> talks about changing the value of a parameter to a busdma call instead.
> I've patched the busdma call and now the device is detected here (but I
> don't hear any output...).
> 
> I think you should add another set of validation code: The buffer size
> is divided by 2 in the code, so I think it should at least print a
> warning if "buffsize % 2 != 0".

	ok, it now rejects odd sizes.

> 
> > 	Would love to hear if this works for anybody else,
> 
> I haven't tried it yet, maybe I get time to test it in the next days.
> 
> Can you also please have a look at PR usb/78028? It adds some info to
> /dev/sndstat.

	For now I don't object to his first try that always producing
verbose output for format discovery.  The second part that adds sndstd
output I think is wrong as it duplicates sndstd itself (though a
little prettier).  
	However in the long term I don't think it's the right thing.
The reason (I'm guessing) he wants the verbose output all the time is
to be able to choose according the devices capabilities.  The problem
is we always reports supporting speeds in between [4000,48000], so for
example on my device which only supports 48000hz, mplayer will happily
try 44100hz and produce no output.  Forcing resample to 48000 (mplayer
-af resample=48000 ...) works.  The situation is even worse in regards
to reporting soft formats as you might not get a vote in what speed
the hardware device gets set at.  (All the same applies to formats as
well).
	I tried to solve this once a while ago with less that perfect
results, a better solution suddenly seems more obvious, which is to
pass a blank pcm_caps to a new function uaudio_queury_formats.
	I'll see if I can come up with anything.

	Thanks,
	--Mat