uaudio patch, capabilities

Mathew Kanner mat at cnd.mcgill.ca
Sun Mar 13 09:58:01 PST 2005


On Mar 13, Alexander Leidinger wrote:
> Mathew Kanner <mat at cnd.mcgill.ca> wrote:
> 
> >>I expected that only one sampling rate (when discrete) or
> >>one sampling rate range (when continuous) must be set in caps.
> >>
> >>I guess that there are two solutions.
> >>1) use only one sampling rate or rage, neglect others.
> >>2) select one rate along a speed of a sound source
> >>         when the channel is initialized.
> >>
> >>When I challenged it slightly, I aimed at 2).
> >>It had no problem that I changed the caps at ua_chan_init() in 
> >>uaudio_pcm.c.
> >
> >	Hi,
> >	I'm not sure I know exaclty what you mean, but there were
> 
> I think he means:
> The audio device doesn't supports a range, it only supports discrete
> sampling rates: 44100, 48000 and 96000. I'm not sure what the second
> proposal is, but my proposal is (without looking at any code, since I don't
> have much time ATM) to provide the posibility to specify multiple
> capabilities. So if the device is able to 22500 and 48000 but not 44100, it
> should have 2 discrete sampling rates set in the capabilities.

	Sadly this is what the channel interface returns:

struct pcmchan_caps {
        u_int32_t minspeed, maxspeed;
        u_int32_t *fmtlist;
        u_int32_t caps;
};

	which maps to what OSS can get out of the IOCTL. 
	One of the things fixed in the patch that we no support *not*
switching to a speed if it is unsupported :)  Applications are supposed
to request a particular speed and see what they get.  I can now run
mplayer without extra options and it works.

	If only I could get sound recording to work with uaudio...

	--Mat


More information about the freebsd-multimedia mailing list