Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

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 <perex@xxxxxxx>
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/