Date: Sat, 29 Oct 2005 09:48:31 +0800 From: Ariff Abdullah <skywizard@MyBSD.org.my> To: Kazuhito HONDA <kazuhito@ph.noda.tus.ac.jp> Cc: freebsd-multimedia@freebsd.org, Alexander@Leidinger.net Subject: Re: uaudio and Digigram UAX220 Message-ID: <20051029094831.1c6c785d.skywizard@MyBSD.org.my> In-Reply-To: <20051028.224049.343190967.kazuhito@ph.noda.tus.ac.jp> References: <435B4EBE.5030502@intersonic.se> <20051027.040902.343165902.kazuhito@ph.noda.tus.ac.jp> <20051027133448.vptim01kwoco8wcw@netchild.homeip.net> <20051028.224049.343190967.kazuhito@ph.noda.tus.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Oct 2005 22:40:49 +0900 (JST)
Kazuhito HONDA <kazuhito@ph.noda.tus.ac.jp> wrote:
> From: Alexander Leidinger <Alexander@Leidinger.net>
> Subject: Re: uaudio and Digigram UAX220
> Date: Thu, 27 Oct 2005 13:34:48 +0200
>
> > Kazuhito HONDA <kazuhito@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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051029094831.1c6c785d.skywizard>