Date: Sun, 6 Mar 2005 12:10:27 -0500 From: Mathew Kanner <mat@cnd.mcgill.ca> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-multimedia@freebsd.org Subject: Re: uaudio patch, configurable buffer size Message-ID: <20050306171027.GE4237@cnd.mcgill.ca> In-Reply-To: <20050306162811.694d9c82@Magellan.Leidinger.net> References: <20050305224005.GC4237@cnd.mcgill.ca> <20050306162811.694d9c82@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 06, Alexander Leidinger wrote: > On Sat, 5 Mar 2005 17:40:05 -0500 > Mathew Kanner <mat@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050306171027.GE4237>