ANNOUNCE: HEAD is open for development again

[Charles Samuels]

On Sunday 15 August 2004 4:12 am, Matthias Welwarsky wrote:
> On Saturday, 14. August 2004 20:45, Charles Samuels wrote:
> > On Saturday 14 August 2004 5:37 am, Matthias Welwarsky wrote:
> > 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.

So if your sound card supports 44.1kHz, then set the kernel to 44.1kHz.  The 
point is that anyone who needs complete and utter quality will either be 
using a good soundcard (with multiple inputs), or will know they need the 
quality, won't be using Linux on the desktop, and will turn this off anyway. 
The point is that we're not targeting these users anyway.

A linear resampler won't distort as much as the mp3 codec itself!

>
> > 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...

So once you can get a scheduler that can guarantee the the latency of 
user-space-mixed audio, then maybe you'd have a point.

> > > 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.

Well, it is architecturally clean, they just are religiously set against it, 
it's quite clear The Desktop is not their primary concern.

-Charles

-- 
Charles Samuels <charles at kde.org>
 Don't change horsemen in the middle of an apocalypse!