uaudio and Digigram UAX220

[Ariff Abdullah]

On Fri, 28 Oct 2005 22:40:49 +0900 (JST)
Kazuhito HONDA <kazuhito at ph.noda.tus.ac.jp> wrote:
> From: Alexander Leidinger <Alexander at Leidinger.net>
> Subject: Re: uaudio and Digigram UAX220
> Date: Thu, 27 Oct 2005 13:34:48 +0200
> 
> > Kazuhito HONDA <kazuhito at ph.noda.tus.ac.jp> wrote:
> > 
> > > -static struct pcmchan_caps ua_playcaps = {8000, 48000,
> > > ua_playfmt, 0}; +static struct pcmchan_caps ua_playcaps = {8000,
> > > 96000, ua_playfmt, 0};
> > 
> > You also enhanced the capabilities for playing and recording. I'm
> > not very familiar with this (sound system capabilities handling
> > and the USB audio standard), but isn't this a property of the
> > underlying hardware and should be probed?
> 
> The protocol of USB audio doesn't decides sampling rate,
> and sampling rates are various according to the devices.
> For example, I have three USB audio devices.
> One's sampling rate is 48 kHz.
> another supports 44.1 kHz and 48 kHz.
> The end can be use at 44.1 kHz, 48 kHz and 96 kHz.
> 
> So Sampling rate should be probed.
This is indeed an absolute mandatory. Whether it discrete or
continuous, the uaudio is responsible to probe and do the bookkeeping.

> Though I don't know a correct method for sending 
> the sampling rate to the sound system,
ua_chan_getcaps() and ua_chan_setspeed() are both responsible to tell
the general sound system the format and rate properties.
ua_chan_getcaps() don't have to worry about the discrete / continuous
sampling rate nature of the underlying uaudio. It is
ua_chan_setspeed() that need a serious attention. It _MUST_ set
and return the _exact_ value supported, not an approximation. The rest
will be decided by the upper layer whether any sort of rate
or format conversion ever needed.

> Mathew KAnner has already written the patch for this problem.
> 
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3877+0+archive/2005/freebsd-multimedia/20050424.freebsd-multimedia
> 
> This patch includes solutions for other problems. 
> Because it is old, it must be changed along recent codes.
> 
Could you please do the cleanup? :) The only thing is that Julian
already said that those patch break his USB microphone, so this must
undergo some serious regression test to be accepted.

I had to comment on your previous 24bit format diff. Sometimes it can
be a 24bit audio within 32bit container, so in this case
AFMT_{U,S}32_{L,B}E also must be put under consideration. Anyway, the
diff looks fine although I have no chance to verify its functionality.


--
Ariff Abdullah
MyBSD

http://www.MyBSD.org.my (IPv6/IPv4)
http://staff.MyBSD.org.my (IPv6/IPv4)
http://tomoyo.MyBSD.org.my (IPv6/IPv4)