On Sun, 8 Jan 2006, Olivier Galibert wrote:
> On Sun, Jan 08, 2006 at 10:42:02AM +0100, Jaroslav Kysela wrote:
> > On Sun, 8 Jan 2006, Olivier Galibert wrote:
> >
> > > On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> > > > Yes, it's a known problem to be fixed. But, it's no excuse to do
> > > > _everything_ in the kernel (which OSS requires).
> > >
> > > OSS does not require to do anything in the kernel except an entry
> > > point.
> > >
> > >
> > > > And if the application doesn't support, who and where converts it?
> > > > With OSS API, it's a job of the kernel.
> > >
> > > Once again no. Nothing prevents the kernel to forward the data to
> > > userland daemons depending on a userspace-uploaded configuration.
> >
> > But it's quite ineffecient. The kernel must switch tasks at least twice
> > or more. It's the major problem with the current OSS API.
>
> Once. U->K or K->U is not task switching and accordingly has a very
> low cost. It's changing of userspace task that is costly. And dmix
> _is_ a task switch, there is no performance difference between talking
> with it through shared memory and semaphores and who knows what else
> and talking with it through a kernel interface.
>
> You should count how many U-U switches and U-K syscalls communicating
> with dmix represents. Hard to do for a simple user, since the
> protocol is not documented.
You're in a mistake. For x86, there are no U-K syscalls for dmix and no
extra U-U task switches, even the latency is same as for the direct
hardware access, because we're using a lockless technique. Also, in case
of use of using mutexes for other architectures, there is only task switch
when mutex is locked when the real mixing is in progress (the mixing is
really small time windows, so it's rare to have mutex locked).
In case of a mixing daemon, you need to regulary woke up a task in a time
period (probably with a highter time interval than application are feeding
new samples). So you have at least one U-U task switch in the perfect
conditions (all sound applications delivered data "in time").
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
