If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

You know...PulseAudio I despise the extra daemon running in the background. Oh.. *Idea* lets hide the whole shebang in the kernel! that way they can't see it right off... You know it really would be better if the parts that have to be running all the time got merged into the kernel and the parts that don't stayed in userspace. The problem with this is audio problems are now harder to fix as it increases the likelihood of requiring a kernel recompile.

yeah, its certainly true that the OS X world is full of people who despise the extra daemon runnin gin the background.

apparently, you're not familiar with the linux engineering dictum that the kernel provides mechanism not policy. putting mixing, sample rate conversion and sample format conversion into the kernel would completely violate that policy. and if you insist, like KLANG (and OSS) on using open/read/write/ioctl, then all those things MUST be in the kernel.

This thing is just stupid. It's like going on a 500 mile trip in the car, traveling 498 miles to your destination, then say "oh $@(# I meant to take a train, not a car, this sucks", then drive all the way back home and get on a train to go there again. What a terrible waste of manpower.

Contribute to ALSA or PulseAudio (or both) instead, ya dolt!

I think its more "traveling 500 miles" then finding things that are worth changing and traveling again.
It don't think it will bring much improvement, but it will surely bring improvement.

8MIB of RAM is really really small for P 100... Consider upgrading.
486 is ok with 8MiB, but Pentium and up need at least 16MiB.

Also, the sound pretty much sucked. Cmmon 8bit, 8khz almost always mono. No wonder tracker was so favorite back then.

So, I remember playing songs on my old 486sx with 4MiB RAM and 160 MB HDD and I don't want those times back.

Has 8 MB when I bought it, later upgraded to 16 MB. And sorry the message was a response to Ferdinand about playing songs in mp3. But... I had make a mistake, i'm recalling that that mp3 songs was on a newer PC, an AMD Athlon 500 MHZ. Sorry.

(…) Now, there is nothing fundamental stopping ALSA from adopting this kind of design. But nothing stopping it isn't the same as making it happen - that would require a significant engineering effort.

This is in tune what I do in KLANG, only that I don't use a DLL but a PLL which is used as a frequency scaler from buffer interval interrupts to sample position. I come from experimental physics and whenever we have to synchronize high frequency delay counters to low frequency triggers the PLL module gets put into the NIM rack.

Also our sample rates in physics are several orders of magnitudes higher of that found in audio. Right now I got that task (at my work I get paid for) to process 2GS/s with 16 bits/S. Oh, and I have to rescale that with varying target sample distances, with lowest possible harmonic distortion. That's the kind of signal processing I usually deal with, and this is to be happen on a 8 cores Ivy Bridge, so…

Originally Posted by PaulDavis

In addition, even without this, you still have to decide where sample rate conversion and sample format conversion will take place - in user space, or in the kernel.

In the kernel of course, because for one, sample format conversion is a no brainer, the biggest problem is being nice to the cache lines. Sample rate conversion is the tricky beast, but can be done with fixed point just as well, if not even better. A lot of people, especially those coming from PC programming, have a rather low regard for fixed point stuff, for some reason I can't fathom. But if you look around in the high performance, high precision DSP business, most signal processing is done in fixed point there. And that's for good reasons; avoiding loss of precision is one of them. Actually if you need very high precision and performance, you end up doing things fixed point very soon.

Originally Posted by PaulDavis

OS X does not have a prohibition on floating point in kernel space (which is contributes a teeny bit to why their kernel is slower than linux for many things).

You can do floating point in the Linux kernel, it's just frowned upon. kernel_fpu_begin and kernel_fpu_end allow for FPU register save, restore. But KLANG doesn't need it, because it does everything fixed point.

I know, from personal experience, that a Pentium 200 MMX can play mp3 fluently (192Kbps, 44KHz, 16-bit, Damn Small Linux, a couple of years ago) but a 486DX2 66MHz can't. Of course this was with a distro tweaked for low resources machines. Considering that the 486-66MHz played the mp3 with lots of stuttering, but it would still output about 500ms of clean sound each 1-2 seconds, the Pentium 133MHz probably would be able to play a 128Kbps mp3 fluently (albeit with 100% cpu usage or very close).

good quality sound mixing requires floating point operation, but this is not allowed in kernel currently.
How can fixed-point operation achieving good quality

However, if compare to Windows/FreeBSD, they does sound mixing in kernel for low latency.
i don't think that linux developers are so "superior" to be able to achieve the goal in userspace.
As long as Linus bans floating point operation in kernel, he is banning Linux kernel to achieve low-latency audio in a cpu cycle effective/power effective way.

KLANG seems to be a small step in the correct direction, but this is unrealistic to reinvent the wheel (how many years will it take?)
either enhancing in ALSA with floating point or improving OSS4 and push it mainline.