Subject: Re: Ideas on the audio framework
To: None <tech-kern@NetBSD.org>
From: TAMURA Kent <kent@NetBSD.org>
Date: 01/05/2005 14:40:48
Content-Type: text/plain; charset=US-ASCII
In message "Re: Ideas on the audio framework"
on 04/12/11, TAMURA Kent <kent@NetBSD.org> writes:
> > > i have one concern about removing the current 6 mulaw functions
> > > and replacing them wih almost certainly slower sequences of
> > > functions? the platforms that matter are likely those that
> > > will never need anything but these (eg, sparc.)
> > Now that you mention it, me too. I'd like to see a benchmark on a slow
> > machine at a high sample rate.
> Ok, I'll show a benchmark result. (or a benchmark program?)
I have decided not to decompose mulaw/alaw functions.
In the filter pipeline framework, filter implementations become
more complex code than the current sw_code implementations. So,
I was afraid many mulaw/alaw functions brought big increase in
the kernel size. That was one of the reasons why I wanted to
decompose and reduce the number of functions.
I have reduced the number of functions by another approach. A
filter implementation can know source/destination audio formats,
and I have unified similar conversions to one filter
sw_code impls Unified to a filter
TAMURA Kent <kent_2005 at hauN.org> <kent at NetBSD.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
-----END PGP SIGNATURE-----