--Boundary-02=_4U0HBH0IxWEs+Du
Content-Type: text/plain;
  charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday, 14. August 2004 20:45, Charles Samuels wrote:
> On Saturday 14 August 2004 5:37 am, Matthias Welwarsky wrote:
> > Why do you think that mixing in kernel consumes less cpu, produces less
> > latency? It does not matter if the cycles for resampling filters are
> > executed in kernel or user context. Plus, you cannot utilize floating
> > point arithmetics from kernel context, which makes any resampling filter
> > apart from simple, low-quality linear interpolation a big hassle.
>
> Oh, I never said resampling filters would be faster in the kernel.
>
> Additionally, if resampling in the kernel is a "big hassle" then why does
> linux already do it?:
>
> 	http://lxr.linux.no/source/sound/core/oss/rate.c?v=3D2.6.5
>

Looking at the code, the implemented resampling filter is just a simple lin=
ear=20
interpolation, which is likely to produce signal distortion. This is exactl=
y=20
my point.

> Anyway, since hardware these days often only supports a single samplerate,
> you don't need a resampler, you just allow the driver to only support a
> single samplerate.

48 kHz that would be, so I'd have to upsample for playback of each of my MP=
3s.=20
But of course I'd like to listen to my music with best possible quality. So=
 I=20
probably use a decent soundcard that directly supports 44.1 kHz, and I'd be=
=20
quite disappointed if the driver forced the card to 48 kHz and used an=20
inferior resampling method to upsample my music.

> If the methodology for linux were to make "the kernel as small as
> possible," then I bet a lot of *hardware* drivers would end up in user
> space.  And may I mention that I seem to remember a web server in Linux as
> well.... hmm...

Yes, but it's basically dead, since people found they could achieve the sam=
e=20
performance in userspace. And yes, the linux kernel has hooks for filesyste=
ms=20
implemented in userspace, and the same goes for USB protocol drivers...

The amount of work done in kernel is just a matter of what the agreed-upon=
=20
interface requires and what the hardware directly supports.

> > Applying pressure to Linus, (*ROTFLMAO*) or anybody else to provide this
> > functionality in kernel is just not going to work, since policy on linux
> > kernel development is "show me the code", like on KDE. When did you last
> > time "pressure" a fellow KDE developer to implement a feature you
> > absolutely wanted but were to lazy to implement yourself? Did it work?
>
> If I've ever mentioned we should pressure him to *code* it, I apologize, I
> meant to say we would pressure him to *allow* it.

The magic word is "pressure". Pressure comes with politics, and it wasn't=20
necessery if the idea was technically and architecturally clean. Of course=
=20
there are already some sound drivers that support multiple opening=20
of /dev/dsp and do mixing and resampling, but it's not a requirement. It's=
=20
just not specified, so you cannot rely on it.

regards,
	matthias

=2D-=20
Matthias Welwarsky
=46achschaft Informatik FH Darmstadt
Email: matze@stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"

--Boundary-02=_4U0HBH0IxWEs+Du
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBH0U4ANO+fpRuZ2IRAlHBAJ4kDtuWgjlWfTC4QFW8KnTfcEJjxQCg0B47
tBNbAIjvU4d3aPdABOwzSsw=
=cdxx
-----END PGP SIGNATURE-----

--Boundary-02=_4U0HBH0IxWEs+Du--