From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262284AbVC2KYL (ORCPT ); Tue, 29 Mar 2005 05:24:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262285AbVC2KYK (ORCPT ); Tue, 29 Mar 2005 05:24:10 -0500 Received: from ns2.suse.de ([195.135.220.15]:7368 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S262284AbVC2KWK (ORCPT ); Tue, 29 Mar 2005 05:22:10 -0500 Date: Tue, 29 Mar 2005 12:22:09 +0200 Message-ID: From: Takashi Iwai To: Marcin Dalecki Cc: Benjamin Herrenschmidt , Lee Revell , Linux Kernel list Subject: Re: Mac mini sound woes In-Reply-To: References: <1111966920.5409.27.camel@gaston> <1112067369.19014.24.camel@mindpipe> <4a7a16914e8d838e501b78b5be801eca@dalecki.de> <1112084311.5353.6.camel@gaston> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Tue, 29 Mar 2005 11:22:07 +0200, Marcin Dalecki wrote: > > > On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote: > > > > Well, we are claiming _and_ obviously proposing a solution ;) > > I beg to differ. > > >> 1. Where do you have true "real-time" under linux? Kernel or user > >> space? > > > > That's bullshit. > > Wait a moment... > > > you don't need "true" real time for the mixing/volume > > processing in most cases. > > Yeah! Give me a break: *Most cases*. Playing sound and video is > paramount for requiring asserted timing. Isn't that a property > RT is defined by? No, still you don't need "true" real-time OS. (More exactly, do we have a "true" RT OS? :) > > I've been doing sound drivers on various > > platforms who don't have anything that look like true realtime neither > > and beleive, it works. Besides, if doing it linux shows latency > > problems, let's just fix them. > > Perhaps as an exercise you could fix the jerky mouse movements on > Linux - too? I would be very glad to see the mouse, which has truly > modest > RT requirements, to start to behave the way it's supposed to do. > And yes I expect it to still move smoothly when doing "make -j100 > world". On the contrary, doing the soft-mixing/volume in kernel is the source of latency when schedule isn't done properly without preemption. > >> 2. Where would you put the firmware for an DSP? Far away or as near to > >> hardware as possible? > > > > Yes. This point is moot. The firmware is somewhere in your filesystem > > and obtained with the request_firmware() interface, that has nothing to > > do in the kernel. If it's really small, it might be ok to stuff it in > > the kernel. But anyway, this point is totally unrelated to the > > statement > > you are replying to. > > No. You didn't get it. I'm taking the view that mixing sound is simply > a task you would typically love to make a DSP firmware do. > However providing a DSP for sound processing at 44kHZ on the same > PCB as an 1GHZ CPU is a ridiculous waste of resources. Thus most > hardware > vendors out there decided to use the main CPU instead. Thus the > "firmware" > is simply running on the main CPU now. Now where should it go? I'm > convinced > that its better to put it near the hardware in the whole stack. I don't understand this logic... > You > think > it's best to put it far away and to invent artificial synchronization > problems between different applications putting data down to the > same hardware device. > > >> 3. How do you synchronize devices on non real time system? > > > > I'm not sure I understand what you mean here. I suppose it's about > > propagation of clock sources, which is traditionally done in the slave > > way; that is the producer (whatever it is, mixer, app, ...) is "sucked" > > by the lowest level at a given rate, the sample count beeing the > > timestamp, variable sample size having other means (and less precise of > > course) to synchronize. > > No I'm simply taking the view that most of the time it's not only a > single > application which will feed the sound output. And quite frequently you > have > to synchronize even with video output. Hmm, how is this related to the topic whether a job is done in user or kernel space...? > >> 4. Why the hell do we have whole network protocols inside the kernel? > >> Couldn't those > >> be perfectly handled in user space? Or maybe there are good reasons? > > > > Network protocol do very few computation on the data in the packets > > (well, except for IPsec for security reasons mostly) but this is a gain > > totally unrelated. Like comparing apples and pears. > > No it's not that far away. The same constraints which did lead most > people > to move TCP in to the kernel basically apply to sound output. > It's just a data stream those days after all. It depends on the efficiency, too. And, if you think of efficiency, user-space has a big gain that it can use SIMD operations. > >> 5. Should a driver just basically map the hardware to the user space > >> or > >> shouldn't > >> it perhaps provide abstraction from the actual hardware implementing > >> it? > > > > This is in no way incompatible with having the mixing and volume > > control > > in userspace. It's actually quite a good idea to have a userland > > library > > that isolates you from the low level "raw" kernel intefaces of the > > driver, and in the case of sound, provides you with the means to setup > > codec chains, mixing components, etc... > > It is not. At least every other OS out there with significant care for > sound did came to a different conclusion. ALSA provides the "driver" feature in user-space because it's more flexible, more efficient and safer than doing in kernel. It's transparent from apps perspective. It really doesn't matter whether it's in kernel or user space. I think your misunderstanding is that you beliieve user-space can't do RT. It's wrong. See JACK (jackit.sf.net), for example. Takashi