From kde-core-devel Sat Aug 14 17:19:16 2004 From: Matthias Welwarsky Date: Sat, 14 Aug 2004 17:19:16 +0000 To: kde-core-devel Subject: Re: ANNOUNCE: HEAD is open for development again Message-Id: <200408141919.25508.matze () stud ! fbi ! fh-darmstadt ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109250393800632 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-02=_cmkHBr3N1GeyP1d" --Boundary-02=_cmkHBr3N1GeyP1d Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday, 14. August 2004 16:16, Tim Jansen wrote: > On Saturday 14 August 2004 14:37, 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. > > The context switches are the problem, especially for low-latencies (which > need smaller frame sizes and thus more context-switches). To be precise, the problem is scheduling latency, not frequency of context= =20 switches. This used to be a problem with linux before the preemptive kernel= ,=20 the O(1) scheduler, etc. Not a valid argument to put mixing into the kernel= =20 any more. You can get pretty far with multithreading and realtime schedulin= g. > > The kernel should not be bloated with application specific demands. It = is > > ultimately an abstraction layer that provides nothing but hardware > > access. > > Is this your main argument or just a side-note? In the first case, the > question would be "assuming that the user experience suffers from this, > should a kernel provide a worse user experience in order to have a clean > architecture?" You could let the users decide, but... In order to keep an OS kernel stable and architecturally clean, yes. The=20 problem is not "the kernel", it is rather the fact that there has never, ev= er=20 been something like a true multimedia infrastructure in linux. People are=20 used to bang the kernel interfaces directly, ever since OSS was invented. S= o=20 about the only agreed-upon interface is OSS (and ALSA, well, sort of), and= =20 people tend to force functionality into it. > > Also, what about network transparency? Following your reasoning, this > > also belongs in kernel so that it "just works"? > > IMHO a kernel should at least provide the hooks, but the problem with > general network transparency in the kernel is its bad design (or more > precisely, Unix just never has been designed for that and the ugly ioctl() > hacks are great at preventing any attempt, which is why the typical Linux > installation has at least 4 special purpose servers for sharing > devices...). This has absolutely nothing to do with bad design. You have to draw a borde= r=20 somewhere, or you will never be able to provide a stable framework. And=20 there's absolutely nothing bad with having a service process to arbitrate=20 access to a resource. This is a proven concept in Unix. > > There's nothing, _NOTHING_ wrong with sound servers. The only thing wro= ng > > about them is bloat, like media codec plugins running inside the sound > > server process. > > The opposite is also bloat: then you need two different architectures for > mixing, resampling etc. You also need codecs for network transparency with > optimal quality. Duplicating functionality won't make it any simpler. No you don't. You're mixing "architecture" and "applications". Why shouldn'= t=20 your "application" use the same codec "architecture" that the soudserver=20 "application" uses?=20 But how useful is a soundserver that reads, decodes and outputs MP3 files a= ll=20 in one go, or directly streams media from a server? Look at noatun. It's=20 nothing but an arts frontend, and if you want it to do something that arts= =20 does not support (hint: shoutcast title info), you have to either force it= =20 into arts, causing bloat there, or you have to duplicate functionality,=20 causing bloat in noatun. It's bad either way, but causing bloat in a centra= l=20 component is worse, because a failure _there_ generates much more angry=20 users. So I reason that there has to be an end to features, which is true for the= =20 linux kernel, and also true for a sound server. =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=_cmkHBr3N1GeyP1d Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBHkmcANO+fpRuZ2IRAuXHAJ9Lwvsd0Nj4RROtPRS8a1KMl5wR8ACgxtUH bFzUK7OS6Fqeq3pP/uo3EAc= =tTGS -----END PGP SIGNATURE----- --Boundary-02=_cmkHBr3N1GeyP1d--