ANNOUNCE: HEAD is open for development again

[Matthias Welwarsky]

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=2.6.5
>

Looking at the code, the implemented resampling filter is just a simple linear 
interpolation, which is likely to produce signal distortion. This is exactly 
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 MP3s. 
But of course I'd like to listen to my music with best possible quality. So I 
probably use a decent soundcard that directly supports 44.1 kHz, and I'd be 
quite disappointed if the driver forced the card to 48 kHz and used an 
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 same 
performance in userspace. And yes, the linux kernel has hooks for filesystems 
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 
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 
necessery if the idea was technically and architecturally clean. Of course 
there are already some sound drivers that support multiple opening 
of /dev/dsp and do mixing and resampling, but it's not a requirement. It's 
just not specified, so you cannot rely on it.

regards,
	matthias

-- 
Matthias Welwarsky
Fachschaft Informatik FH Darmstadt
Email: matze at stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040815/b7089e49/attachment.sig>