Date: Sun, 6 Mar 2005 15:49:08 -0500 From: Mathew Kanner <mat@cnd.mcgill.ca> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Mathew Kanner <mat@cnd.mcgill.ca> Subject: Re: uaudio patch, configurable buffer size Message-ID: <20050306204908.GF4237@cnd.mcgill.ca> In-Reply-To: <20050306184416.5603976c@Magellan.Leidinger.net> References: <20050305224005.GC4237@cnd.mcgill.ca> <20050306162811.694d9c82@Magellan.Leidinger.net> <20050306171027.GE4237@cnd.mcgill.ca> <20050306184416.5603976c@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 06, Alexander Leidinger wrote: > On Sun, 6 Mar 2005 12:10:27 -0500 > Mathew Kanner <mat@cnd.mcgill.ca> wrote: > > > > 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 > > I don't think we should clutter the boot process with this output. If > it's interesting for someone, he shouldn't need to look at those > messages. That's the reason I proposed to add the information to > sndstat. > > > output I think is wrong as it duplicates sndstd itself (though a > > little prettier). > > Do we have a way to extend sndstat? If not, we should add it, since a > device may have to say something interesting about its capabilities > (read: it would be nice if every device would tell the use about its > capabilities in sndstat). > > > 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 > > Why? As I say below, he probably needs this because uaudio (the pcm bridge of it at least) wrongly reports it's capabilities. I would be that his first solution and second solution don't even yield the same results. > > > 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). > > So either we need a format converter in the kernel (looks ugly to me, it > belongs IMHO into the userland, but NetBSD seems to have this > possibility in the kernel), or we need to reject incompatible use. It does belong is userland. We could get the same effect by having the something probe capabilities via ioctls but we need to fix the reporting of caps first. --Mat > > Bye, > Alexander. > > -- > To boldly go where I surely don't belong. > > http://www.Leidinger.net Alexander @ Leidinger.net > GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050306204908.GF4237>