* Re: [OT] ALSA userspace API complexity
[not found] ` <5rf9X-7yf-25@gated-at.bofh.it>
@ 2006-01-04 11:56 ` Patrizio Bassi
2006-01-04 18:07 ` Florian Schmidt
2006-01-05 18:59 ` Lee Revell
0 siblings, 2 replies; 84+ messages in thread
From: Patrizio Bassi @ 2006-01-04 11:56 UTC (permalink / raw)
To: Jaroslav Kysela, Kernel,
Jaroslav Kysela ha scritto:
> On Wed, 4 Jan 2006, Pete Zaitcev wrote:
>
>
>>On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
>>
>>
>>>>2) ALSA API is to complicated: most applications opens single sound
>>>> stream.
>>>
>>>FUD and nonsense. []
>>>http://devzero.co.uk/~alistair/alsa/
>>
>>That's the kicker, isn't it? Once you get used to it, it's a workable
>>API, if kinky and verbose. I have a real life example, too:
>> http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
>>But arriving on the solution costed a lot of torn hair. Look at this
>>bald head here! And who is going to pay my medical bills when ALSA
>>causes me ulcers, Jaroslav?
>
>
> Well, the ALSA primary goal is to be the complete HAL not hidding the
> extra hardware capabilities to applications. So API might look a bit
> complicated for the first glance, but the ALSA interface code for simple
> applications is not so big, isn't?
>
> Also, note that app developers are not forced to use ALSA directly - there
> is a lot of "portable" sound API libraries having an ALSA backend doing
> this job quite effectively. We can add a simple (like OSS) API layer
> into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
> some support functions for the easy PCM device initialization might be
> a good idea.
>
> Jaroslav
>
considering that alsa API and drivers is pretty stable i see no problem
in OSS removal.
When writing a program adding oss compatibility seems faster, but,
creates lots of problems.
check the skype example (yes i know it's closed-source). 99% of sound
problems users have is due to OSS driver usage.
that's a big problem. Needs a radical solution. Considering aoss works
in 50% of cases i suggest aoss improvement and not OSS keeping in kernel.
A good idea could be an OSS API layer over Alsa-lib...but i personally
don't know how much can that costs, considering you should link against
alsa-lib too.
This discussion seems a no-sense.
Kernel API continues to change every -rc and noone cares that.
OSS has been deprecated for a lot, and it's as old as moon.
Patrizio
--
Patrizio Bassi
www.patriziobassi.it
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 11:56 ` [OT] ALSA userspace API complexity Patrizio Bassi
@ 2006-01-04 18:07 ` Florian Schmidt
2006-01-04 18:46 ` Alistair John Strachan
2006-01-05 18:59 ` Lee Revell
1 sibling, 1 reply; 84+ messages in thread
From: Florian Schmidt @ 2006-01-04 18:07 UTC (permalink / raw)
To: patrizio.bassi; +Cc: Jaroslav Kysela, Kernel,
On Wed, 04 Jan 2006 12:56:12 +0100
Patrizio Bassi <patrizio.bassi@gmail.com> wrote:
> that's a big problem. Needs a radical solution. Considering aoss works
> in 50% of cases i suggest aoss improvement and not OSS keeping in kernel.
aoss works _much_ less often than the OSS emulation kernel modules. I'd
rather see (if not just for ease of setup), sw mixing in the OSS
emulation kernel modules. aoss should still continue to exist as it has
some advanced functionality like being able to use any alsa defined pcm
device, but for the vast majority of cases it would be the best if the
OSS emulation kernel module simply finally provided sw mixing.
It might also be worth taking a look at FUSE and stuff like oss2jack
instead, as it would be (imho) the cleaner approach for getting OSS
emulation to userspace as opposed to aoss (device file interface vs.
ugly LD_PRELOAD hack (which has its share of problems. Especially with
apps/libs that resolved the linux system call symbols at compile time -
this is where aoss/LD_PRELOAD won't work, but a FUSE based approach
would)).
Actually i suppose a FUSE based oss2alsa would probably make the old OSS
emulation modules unnecessary if implemented right :) As the relevant
code then lives in userspace it can make trivial use of stuff like ALSA
sw mixing and all other ALSA userspace goodies (which aoss can, too, but
at the cost of being an ugly LD_PRELOAD hack).
Have fun,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 18:07 ` Florian Schmidt
@ 2006-01-04 18:46 ` Alistair John Strachan
0 siblings, 0 replies; 84+ messages in thread
From: Alistair John Strachan @ 2006-01-04 18:46 UTC (permalink / raw)
To: Florian Schmidt; +Cc: patrizio.bassi, Jaroslav Kysela, Kernel,
On Wednesday 04 January 2006 18:07, Florian Schmidt wrote:
> On Wed, 04 Jan 2006 12:56:12 +0100
>
> Patrizio Bassi <patrizio.bassi@gmail.com> wrote:
> > that's a big problem. Needs a radical solution. Considering aoss works
> > in 50% of cases i suggest aoss improvement and not OSS keeping in kernel.
>
> aoss works _much_ less often than the OSS emulation kernel modules. I'd
> rather see (if not just for ease of setup), sw mixing in the OSS
> emulation kernel modules. aoss should still continue to exist as it has
> some advanced functionality like being able to use any alsa defined pcm
> device, but for the vast majority of cases it would be the best if the
> OSS emulation kernel module simply finally provided sw mixing.
>
> It might also be worth taking a look at FUSE and stuff like oss2jack
> instead, as it would be (imho) the cleaner approach for getting OSS
> emulation to userspace as opposed to aoss (device file interface vs.
> ugly LD_PRELOAD hack (which has its share of problems. Especially with
> apps/libs that resolved the linux system call symbols at compile time -
> this is where aoss/LD_PRELOAD won't work, but a FUSE based approach
> would)).
>
> Actually i suppose a FUSE based oss2alsa would probably make the old OSS
> emulation modules unnecessary if implemented right :) As the relevant
> code then lives in userspace it can make trivial use of stuff like ALSA
> sw mixing and all other ALSA userspace goodies (which aoss can, too, but
> at the cost of being an ugly LD_PRELOAD hack).
Not to disrespect Miklos's work, but relying on FUSE for such a fundamental
problem is probably not a good idea. Most people probably do not compile FUSE
into their kernel.
I do agree with other posters here that OSS compatibility a) needs to be
improved and b) should not be limited to the features of the soundcard (i.e.
it must software mix). As Andi has pointed out, wholly removing OSS is not in
the spirit of Linux and will not happen for many years.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 11:56 ` [OT] ALSA userspace API complexity Patrizio Bassi
2006-01-04 18:07 ` Florian Schmidt
@ 2006-01-05 18:59 ` Lee Revell
2006-01-05 20:06 ` Patrizio Bassi
2006-01-05 20:47 ` Patrizio Bassi
1 sibling, 2 replies; 84+ messages in thread
From: Lee Revell @ 2006-01-05 18:59 UTC (permalink / raw)
To: patrizio.bassi; +Cc: Jaroslav Kysela, Kernel,
On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
> that's a big problem. Needs a radical solution. Considering aoss works
> in 50% of cases i suggest aoss improvement and not OSS keeping in
> kernel.
>
Please rephrase your statement in the form of a USEFUL BUG REPORT.
Lee
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 18:59 ` Lee Revell
@ 2006-01-05 20:06 ` Patrizio Bassi
2006-01-05 20:11 ` Lee Revell
2006-01-05 20:47 ` Patrizio Bassi
1 sibling, 1 reply; 84+ messages in thread
From: Patrizio Bassi @ 2006-01-05 20:06 UTC (permalink / raw)
To: Lee Revell; +Cc: Jaroslav Kysela, Kernel,
Lee Revell ha scritto:
>On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
>
>
>>that's a big problem. Needs a radical solution. Considering aoss works
>>in 50% of cases i suggest aoss improvement and not OSS keeping in
>>kernel.
>>
>>
>>
>
>Please rephrase your statement in the form of a USEFUL BUG REPORT.
>
>Lee
>
>
>
>
i opened an aoss/skype bug, that got closed without a complete fix..
because other problems were found...but actually that's not a complete
solution
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1224
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 20:06 ` Patrizio Bassi
@ 2006-01-05 20:11 ` Lee Revell
0 siblings, 0 replies; 84+ messages in thread
From: Lee Revell @ 2006-01-05 20:11 UTC (permalink / raw)
To: patrizio.bassi; +Cc: Jaroslav Kysela, Kernel,
On Thu, 2006-01-05 at 21:06 +0100, Patrizio Bassi wrote:
> Lee Revell ha scritto:
>
> >On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
> >
> >
> >>that's a big problem. Needs a radical solution. Considering aoss works
> >>in 50% of cases i suggest aoss improvement and not OSS keeping in
> >>kernel.
> >>
> >>
> >>
> >
> >Please rephrase your statement in the form of a USEFUL BUG REPORT.
> >
> >Lee
> >
> >
> >
> >
> i opened an aoss/skype bug, that got closed without a complete fix..
> because other problems were found...but actually that's not a complete
> solution
>
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1224
>
>
Please see bug #1228. I closed #1224 as it had diverged wildly from the
original bug report (which was someone asking "why ALSA doesn't do
software mixing like artsd", which it does of course).
The status is we need more information on this bug. Some people report
that Skype works perfectly with aoss. It seems to be hardware, ALSA
version, or Skype version dependent.
Since Skype is closed source I'm afraid you'll have to do most of the
debugging work yourself, we can't waste time debugging closed source
apps.
I have heard that kiax (open source VOIP client) has some of the same
problems with aoss as Skype so that's likely to be the most productive
approach.
Lee
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 18:59 ` Lee Revell
2006-01-05 20:06 ` Patrizio Bassi
@ 2006-01-05 20:47 ` Patrizio Bassi
1 sibling, 0 replies; 84+ messages in thread
From: Patrizio Bassi @ 2006-01-05 20:47 UTC (permalink / raw)
To: Lee Revell; +Cc: Kernel,
Lee Revell ha scritto:
>On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
>
>
>>that's a big problem. Needs a radical solution. Considering aoss works
>>in 50% of cases i suggest aoss improvement and not OSS keeping in
>>kernel.
>>
>>
>>
>
>
>
>
yes i am the one (testing lots of voip solutions) in the bug report.
i told you that kiax has a similar problem :)
i think this sort of mail flood in kml is not productive.
As Lee asked, let's use their mantis system and leave kml free.
this is going OT...from OSS removal, to Alsa bad design, to Alsa
bugs...what else?
Patrizio
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
@ 2006-01-08 7:19 linux
2006-01-08 22:08 ` Hannu Savolainen
0 siblings, 1 reply; 84+ messages in thread
From: linux @ 2006-01-08 7:19 UTC (permalink / raw)
To: linux-kernel
hannu@opensound.com wrote:
> To get (say) 10 ms latencies you have to tell the sound subsystem
> to allocate to buffer that is smaller than 10 ms. This in turn means that
> the application must be able to run it's processing loop within less than 10
> ms with 100.000...0% confidence. This is true regardless of how advanced
> or primitive the audio subsystem (API) is.
Only if you need 10 ms latencies 100.000...0% of the time. Which isn't
always the case.
The rest of the time, you can do very well by providing a way to supply
"tentative" data in advance of need, but cancel it and replace it with
better data when something happens... something explodes in a game, or
a new person speaks up in an audio conferencing application, or a new MIDI
event arrives.
Real-time DSP is a different matter, but the point I'm trying to make
is that there is a non-zero set of applications for which additional
API festures allow low average latency and guaranteed lack of total
dropouts.
Simply writing to /dev/dsp doesn't give you that, but e.g. DMA out of
user-space buffers does.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 7:19 linux
@ 2006-01-08 22:08 ` Hannu Savolainen
0 siblings, 0 replies; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-08 22:08 UTC (permalink / raw)
To: linux; +Cc: linux-kernel, linux-audio-dev
On Sun, 8 Jan 2006 linux@horizon.com wrote:
> Only if you need 10 ms latencies 100.000...0% of the time. Which isn't
> always the case.
If you are doing audio with 10 ms _buffers_ then you will need smaller
than 10 ms latencies from the beginning to the end. This is always the
case.
> The rest of the time, you can do very well by providing a way to supply
> "tentative" data in advance of need, but cancel it and replace it with
> better data when something happens... something explodes in a game, or
> a new person speaks up in an audio conferencing application, or a new MIDI
> event arrives.
You can't predict the future output if you are doing processing on live
input and playing back the result immediately. In this kind of
applications you are limited to the latencies the plattform can
guarantee. There is nothing the audio subsystem can do to make things
work better so for this reason any time spent on developing such features
is complete waste of time.
Right. If you can predict what the output could be then you don't need to
limit the the buffer to 10 ms. You can use much longer buffer and rewrite
parts of it.
In reality you can use surprisingly large buffers in applications like
games and nobody will notice any lags. This is because human brain
automatically masks them. As you know speed of sound is about 340 m/s.
Largish delay of 0.1s=100ms equals to distance of 34 meters. This makes
the distance to the explosion to sound like they occurred 34 meters behind
the actual place. 10 ms equals to just 3.4 meters.
Also in reality getting 10 ms "one way" latencies don't require any
special tricking with DMA from user land or things like that. Simply using
short enough buffer is enough. If the game itself is properly designed
then 10-20ms will work out of box (at least with OSS). This approach has
been used since the old sasteroids game 10-12 years ago and it's still
used by the SDL library.
Using sophisticated algorithms that "cannot fail" may be sexy but it's
pointless because nothing fails anyway.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <5rdrx-4Yl-43@gated-at.bofh.it>]
* Re: [OT] ALSA userspace API complexity
[not found] <5rdrx-4Yl-43@gated-at.bofh.it>
@ 2006-01-05 14:01 ` Heikki Orsila
2006-01-05 14:24 ` Jaroslav Kysela
2006-01-05 14:49 ` Alistair John Strachan
0 siblings, 2 replies; 84+ messages in thread
From: Heikki Orsila @ 2006-01-05 14:01 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Alistair John Strachan
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Tuesday 03 January 2006 23:10, Tomasz K?oczko wrote:
> 2) ALSA API is to complicated: most applications opens single sound
> stream.
> FUD and nonsense. I've written many DSP applications and very often I can
> recycle the same code for use in them.
It's not FUD and it's very true. I've written ALSA support for many
programs and I still can't remember the tricks that are needed to get
even basic things working.
Just look at error handling of libao-0.8.6 for a great example how
complicated it is to write code for ALSA. The following code is directly
from the source:
/* try to write the entire buffer at once */
err = internal->writei(internal->pcm_handle, ptr, len);
/* it's possible that no data was transferred */
if (err == -EAGAIN) {
continue;
}
if (err < 0) {
/* this might be an error, or an exception */
err = alsa_error_recovery(internal, err);
if (err < 0) {
fprintf(stderr,"ALSA write error: %s\n",
snd_strerror(err));
return 0;
}
/* abandon the rest of the buffer */
break;
}
alsa_error_recovery() expands to 30 lines of more logic. This is pretty
insane considering that libao _only_ writes data to device and does
nothing else. If ALSA was done properly, the main loop would simply be:
err = internal->writei(internal->pcm_handle, ptr, len);
/* it's possible that no data was transferred */
if (err == -EAGAIN || err == -EINTR) {
continue;
}
if (err < 0) {
/* BAD BAD */
}
When I originally ran into this signal handling brain damage of ALSA, I
had to actually look into other programs how they handle signals because
ALSA documentation is so bad. The core problem is of course the broken
API, not the bad documentation.
A small note, libao can not handle EINTR properly. A patch has been
submitted already.
I've long ago stopped using ALSA API because it is broken. But if you
wanted to make ALSA usable by real people you might considering adding 3
functions (there are ~300 already so not much loss):
err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
err = alsa_simple_writei(); /* handless signal brokeness automagically */
alsa_simple_close();
Basically ogg123/mpg123 like applications would only need 3 alsa calls.
Now everyone reimplementing their own buggy versions of simple mechanisms.
--
Heikki Orsila Barbie's law:
heikki.orsila@iki.fi "Math is hard, let's go shopping!"
http://www.iki.fi/shd
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:01 ` Heikki Orsila
@ 2006-01-05 14:24 ` Jaroslav Kysela
2006-01-05 14:45 ` Heikki Orsila
` (2 more replies)
2006-01-05 14:49 ` Alistair John Strachan
1 sibling, 3 replies; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-05 14:24 UTC (permalink / raw)
To: Heikki Orsila; +Cc: Linux Kernel Mailing List, Alistair John Strachan
On Thu, 5 Jan 2006, Heikki Orsila wrote:
> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Tuesday 03 January 2006 23:10, Tomasz K?oczko wrote:
> > 2) ALSA API is to complicated: most applications opens single sound
> > stream.
>
> > FUD and nonsense. I've written many DSP applications and very often I can
> > recycle the same code for use in them.
>
> I've long ago stopped using ALSA API because it is broken. But if you
> wanted to make ALSA usable by real people you might considering adding 3
> functions (there are ~300 already so not much loss):
This sentence makes this in my mind: real people = lazy people. The error
codes are documented well. Also, aplay in the alsa-utils package has
good error recovery code including test pcm.c utility in alsa-lib.
> err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> err = alsa_simple_writei(); /* handless signal brokeness automagically */
> alsa_simple_close();
Well, it's better to create only "fast parameter setup" and "default error
recovery" functions.
> Basically ogg123/mpg123 like applications would only need 3 alsa calls.
> Now everyone reimplementing their own buggy versions of simple mechanisms.
While "official" examples exists for a long time. Also, we already noted
that we are not best documentation writers, but everytime when we ask for
help we hear nothing from other people.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:24 ` Jaroslav Kysela
@ 2006-01-05 14:45 ` Heikki Orsila
2006-01-10 9:22 ` Jaroslav Kysela
2006-01-05 14:51 ` Olivier Galibert
2006-01-05 15:27 ` Heikki Orsila
2 siblings, 1 reply; 84+ messages in thread
From: Heikki Orsila @ 2006-01-05 14:45 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Jaroslav Kysela
On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote:
> On Thu, 5 Jan 2006, Heikki Orsila wrote:
> This sentence makes this in my mind: real people = lazy people.
Yes, but it has good reasons too. The real point of userspace libraries
and programs rather than kernel space is saving effort. Laziness in
programming is good so long as programs are readable and correct.
Your success must be measured according to the number of bugs with ALSA
programs and the time used to develop ALSA support for them. Right now
it looks very bad to me. Even libao can't handle ALSA well, and knowing
some XMMS developers they have hard time with ALSAs complexity. KISS.
> The error codes are documented well.
That's a bad excuse for requiring buffer underruns to be handled
specially because it's not a fatal error. Errors should be handled
as close to the error source as possible, and the ALSA lib is the
logical place to handle underrun by default (unless the application
really is interested in handling underruns specially). Passing errors
through unreasonably many layers causes more complexity for programmers.
> > err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> > err = alsa_simple_writei(); /* handless signal brokeness automagically */
> > alsa_simple_close();
>
> Well, it's better to create only "fast parameter setup" and "default error
> recovery" functions.
As long as all applications PCM code can be written into 10-20 C lines.
That includes: opening device, writing pcm data and closing the device.
> > Basically ogg123/mpg123 like applications would only need 3 alsa calls.
> > Now everyone reimplementing their own buggy versions of simple mechanisms.
>
> While "official" examples exists for a long time.
btw. your official examples don't work on simple PCM playback didn't
work when I last time tried. Sorry, I can't remember details because it
is so long ago.
--
Heikki Orsila Barbie's law:
heikki.orsila@iki.fi "Math is hard, let's go shopping!"
http://www.iki.fi/shd
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:45 ` Heikki Orsila
@ 2006-01-10 9:22 ` Jaroslav Kysela
2006-01-10 11:50 ` Heikki Orsila
0 siblings, 1 reply; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-10 9:22 UTC (permalink / raw)
To: Heikki Orsila; +Cc: Linux Kernel Mailing List
On Thu, 5 Jan 2006, Heikki Orsila wrote:
> > > err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> > > err = alsa_simple_writei(); /* handless signal brokeness automagically */
> > > alsa_simple_close();
> >
> > Well, it's better to create only "fast parameter setup" and "default error
> > recovery" functions.
>
> As long as all applications PCM code can be written into 10-20 C lines.
> That includes: opening device, writing pcm data and closing the device.
I've added snd_pcm_set_params() and snd_pcm_recover() functions into
alsa-lib (they're a bit experimental and I'm still waiting for any
feedback from others).
The "minimal example" can be reached at:
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/test/pcm_min.c?rev=1.2&view=markup
> > > Basically ogg123/mpg123 like applications would only need 3 alsa calls.
> > > Now everyone reimplementing their own buggy versions of simple mechanisms.
> >
> > While "official" examples exists for a long time.
>
> btw. your official examples don't work on simple PCM playback didn't
> work when I last time tried. Sorry, I can't remember details because it
> is so long ago.
Any bug report? We don't have a crystal ball to fix bugs without any
information.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:24 ` Jaroslav Kysela
2006-01-05 14:45 ` Heikki Orsila
@ 2006-01-05 14:51 ` Olivier Galibert
2006-01-05 15:26 ` Alexander E. Patrakov
2006-01-05 15:33 ` Jaroslav Kysela
2006-01-05 15:27 ` Heikki Orsila
2 siblings, 2 replies; 84+ messages in thread
From: Olivier Galibert @ 2006-01-05 14:51 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Heikki Orsila, Linux Kernel Mailing List, Alistair John Strachan
On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote:
> This sentence makes this in my mind: real people = lazy people. The error
> codes are documented well.
Actual alsa reference documentation:
int snd_pcm_prepare(snd_pcm_t *pcm)
Prepare PCM for use.
Parameters:
pcm PCM handle
Returns:
0 on success otherwise a negative error code
[Beautifully documented error codes and causes]
snd_pcm_sframes_t snd_pcm_writei(snd_pcm_t * pcm,
const void *buffer,
snd_pcm_uframes_t size
)
Write interleaved frames to a PCM.
Parameters:
pcm PCM handle
buffer frames containing buffer
size frames to be written
Returns:
a positive number of frames actually written otherwise a negative error code
Return values:
-EBADFD PCM is not in the right state (SND_PCM_STATE_PREPARED or SND_PCM_STATE_RUNNING)
-EPIPE an underrun occurred
-ESTRPIPE a suspend event occurred (stream is suspended and waiting for an application recovery)
If the blocking behaviour is selected, then routine waits until all requested bytes are played or put to the playback ring buffer. The count of bytes can be less only if a signal or underrun occurred.
If the non-blocking behaviour is selected, then routine doesn't wait at all.
[Count of bytes less than the frame count when an underrun, which
returns -EPIPE, happened? -EBADFD when the state is XRUN (not it
doesn't)? Cause and handling of suspend events?]
Anybody who says the alsa documentation is good never had to use it.
At that point I know my simple playing code is incorrect and I have no
clue on how to fix it.
> Also, aplay in the alsa-utils package has
> good error recovery code including test pcm.c utility in alsa-lib.
A sleep(1) in the error recovery path? Are you people nuts?
Incidentally:
- "A small demo which sends a simple sinusoidal wave to the speakers"
requiring close to 900 lines is demented. That's the size of
glxgears.c, with 50% of that one being printer support. A complete
smartflow example getting a sound stream on the network and playing
it with oss takes 160 lines, with 20 lines of copyright-ish at the
start. The actual sound part of that is _30_ lines.
- Error and state handling after writei changes depending on the call.
We're supposed to guess which one is correct?
Make simple things simple, guys.
OG.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:51 ` Olivier Galibert
@ 2006-01-05 15:26 ` Alexander E. Patrakov
2006-01-05 15:30 ` Jaroslav Kysela
2006-01-05 18:11 ` Florian Schmidt
2006-01-05 15:33 ` Jaroslav Kysela
1 sibling, 2 replies; 84+ messages in thread
From: Alexander E. Patrakov @ 2006-01-05 15:26 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Olivier Galibert, Heikki Orsila, Alistair John Strachan
Olivier Galibert wrote:
> Make simple things simple, guys.
Sorry for hijacking the thread, but it is very true. ALSA is just too
flexible so that the ALSA equivalent (if it indeed exists) of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339951 cannot be fixed.
OSS allows specification of device name, and one can set up udev rules
so that e.g. /dev/dsp-creative it is always a symlink to a SB PCI sound
card and /dev/dsp-fortemedia is for FM801. Then one can tell xine to
play sound through /dev/dsp-fortemedia. ALSA accepts only numbers in its
plughw:x,y,z notation, and applications are unfixable when kernel device
numbers become random.
--
Alexander E. Patrakov
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 15:26 ` Alexander E. Patrakov
@ 2006-01-05 15:30 ` Jaroslav Kysela
2006-01-05 16:01 ` Alexander E. Patrakov
2006-01-05 18:11 ` Florian Schmidt
1 sibling, 1 reply; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-05 15:30 UTC (permalink / raw)
To: Alexander E. Patrakov
Cc: Linux Kernel Mailing List, Olivier Galibert, Heikki Orsila,
Alistair John Strachan
On Thu, 5 Jan 2006, Alexander E. Patrakov wrote:
> Olivier Galibert wrote:
>
> > Make simple things simple, guys.
>
> Sorry for hijacking the thread, but it is very true. ALSA is just too flexible
> so that the ALSA equivalent (if it indeed exists) of
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339951 cannot be fixed. OSS
> allows specification of device name, and one can set up udev rules so that
> e.g. /dev/dsp-creative it is always a symlink to a SB PCI sound card and
> /dev/dsp-fortemedia is for FM801. Then one can tell xine to play sound through
> /dev/dsp-fortemedia. ALSA accepts only numbers in its plughw:x,y,z notation,
> and applications are unfixable when kernel device numbers become random.
It's not true. You can also use plughw:CARDID,0 or so notation.
Identification of cards are available via control interface or look
to /proc/asound/cards file. The card ID string can be set via
a module option. Also you can fix the card index numbers with
a module option.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 15:30 ` Jaroslav Kysela
@ 2006-01-05 16:01 ` Alexander E. Patrakov
0 siblings, 0 replies; 84+ messages in thread
From: Alexander E. Patrakov @ 2006-01-05 16:01 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Linux Kernel Mailing List, Olivier Galibert, Heikki Orsila,
Alistair John Strachan
Jaroslav Kysela wrote:
>You can also use plughw:CARDID,0 or so notation.
>
>
Thanks, it works here indeed.
>Identification of cards are available via control interface or look
>to /proc/asound/cards file. The card ID string can be set via
>a module option. Also you can fix the card index numbers with
>a module option.
>
>
The point here is that virtually every other subsystem can use udev to
rename devices and/or create symlinks. For ALSA, an ALSA-specific
solution has to be used. Although, I admit that udev offers nothing over
this solution for my sound card.
--
Alexander E. Patrakov
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 15:26 ` Alexander E. Patrakov
2006-01-05 15:30 ` Jaroslav Kysela
@ 2006-01-05 18:11 ` Florian Schmidt
1 sibling, 0 replies; 84+ messages in thread
From: Florian Schmidt @ 2006-01-05 18:11 UTC (permalink / raw)
To: Alexander E. Patrakov
Cc: Linux Kernel Mailing List, Olivier Galibert, Heikki Orsila,
Alistair John Strachan
On Thu, 05 Jan 2006 20:26:36 +0500
"Alexander E. Patrakov" <patrakov@gmail.com> wrote:
> Olivier Galibert wrote:
>
> > Make simple things simple, guys.
>
> Sorry for hijacking the thread, but it is very true. ALSA is just too
> flexible so that the ALSA equivalent (if it indeed exists) of
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339951 cannot be fixed.
> OSS allows specification of device name, and one can set up udev rules
> so that e.g. /dev/dsp-creative it is always a symlink to a SB PCI sound
> card and /dev/dsp-fortemedia is for FM801. Then one can tell xine to
> play sound through /dev/dsp-fortemedia. ALSA accepts only numbers in its
> plughw:x,y,z notation, and applications are unfixable when kernel device
> numbers become random.
maybe i misunderstood your point, but:
a] every alsa driver can have an option "index" which tells it what card
number to grab, so either pass it as module load option or at kernel
boot time..
b] applications should actually allow the user to enter _any_ string as
a device name (well "any" is actually too much). This enables the user
to define his own pcm devices (i.e. using alsa pcm LADSPA plugin) and
use these in any native ALSA app.
There's all kind of nifty predefined pcm device definitions available,
as i.e. "surround50", "surround51", etc.. One can even indicate what
card number to use, i.e. "surround50:0" or "surround50:2" (for the first
and third card in the system respectively). The special name "!default"
can also be overridden easily to make any sane and well programmed ALSA
app use a certain pcm device of the user's choice.
If i completely missed your point -> sorry
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:51 ` Olivier Galibert
2006-01-05 15:26 ` Alexander E. Patrakov
@ 2006-01-05 15:33 ` Jaroslav Kysela
2006-01-05 16:48 ` Marcin Dalecki
1 sibling, 1 reply; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-05 15:33 UTC (permalink / raw)
To: Olivier Galibert
Cc: Heikki Orsila, Linux Kernel Mailing List, Alistair John Strachan
On Thu, 5 Jan 2006, Olivier Galibert wrote:
> - "A small demo which sends a simple sinusoidal wave to the speakers"
> requiring close to 900 lines is demented. That's the size of
> glxgears.c, with 50% of that one being printer support. A complete
> smartflow example getting a sound stream on the network and playing
> it with oss takes 160 lines, with 20 lines of copyright-ish at the
> start. The actual sound part of that is _30_ lines.
The pcm.c file shows you 7 available methods how you can send audio data
to alsa-lib. It's complete example. If you remove the parsing command
line, sine generation, error handling, you'll end with few lines too.
> - Error and state handling after writei changes depending on the call.
> We're supposed to guess which one is correct?
>
> Make simple things simple, guys.
Yes, we should stay with simple 1.0 linux kernel. Anyway, we're taking all
points from this discussion.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 15:33 ` Jaroslav Kysela
@ 2006-01-05 16:48 ` Marcin Dalecki
0 siblings, 0 replies; 84+ messages in thread
From: Marcin Dalecki @ 2006-01-05 16:48 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Olivier Galibert, Heikki Orsila, Linux Kernel Mailing List,
Alistair John Strachan
On 2006-01-05, at 16:33, Jaroslav Kysela wrote:
>> Make simple things simple, guys.
>
> Yes, we should stay with simple 1.0 linux kernel.
This blatant attempt to defend a broken subsystem by "analogy" fails
because last time
I checked the semantics of system calls like read/write/open/close
didn't
change significantly between kernel version 1.0 and 2.6.15.
The number of system calls didn't change that much as well.
Yes it may be true that some aggregation of exhaustive crappy
interfaces over time
in the kernel can be indeed observed. However the very fact which
makes it remain
still usable are precisely those very "primitive" system calls -
which are still
around and kicking.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:24 ` Jaroslav Kysela
2006-01-05 14:45 ` Heikki Orsila
2006-01-05 14:51 ` Olivier Galibert
@ 2006-01-05 15:27 ` Heikki Orsila
2 siblings, 0 replies; 84+ messages in thread
From: Heikki Orsila @ 2006-01-05 15:27 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Linux Kernel Mailing List, Alistair John Strachan
On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote:
> On Thu, 5 Jan 2006, Heikki Orsila wrote:
> > err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
>
> Well, it's better to create only "fast parameter setup" and "default error
> recovery" functions.
And what would it look like? I would prefer all functions being
alsa_simple_* because a user could read interface documentation
alphabetically and see all the relevant functions as they are adjacent.
I would correct my earlier 'frames_in_period' to 'latency_in_frames' because
most users are not interested in period size. Latency on the other hand
matters. 10ms latency would just be samplingrate / 100 and the ALSA lib
would choose good approximate period/buffer sizes internally. Those who
need something better should just use the old way.
--
Heikki Orsila Barbie's law:
heikki.orsila@iki.fi "Math is hard, let's go shopping!"
http://www.iki.fi/shd
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 14:01 ` Heikki Orsila
2006-01-05 14:24 ` Jaroslav Kysela
@ 2006-01-05 14:49 ` Alistair John Strachan
1 sibling, 0 replies; 84+ messages in thread
From: Alistair John Strachan @ 2006-01-05 14:49 UTC (permalink / raw)
To: Heikki Orsila; +Cc: Linux Kernel Mailing List
Firstly, trimming CCs is quite rude and makes it very difficult for others to
address your problems.
On Thursday 05 January 2006 14:01, Heikki Orsila wrote:
> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Tuesday 03 January 2006 23:10, Tomasz K?oczko wrote:
> > 2) ALSA API is to complicated: most applications opens single sound
> > stream.
> >
> > FUD and nonsense. I've written many DSP applications and very often I can
> > recycle the same code for use in them.
>
> It's not FUD and it's very true. I've written ALSA support for many
> programs and I still can't remember the tricks that are needed to get
> even basic things working.
They're not really tricks, they're allowing developers to flexibly handle
cases that they may care about, such as momentary communication problems
(think USB soundcards, headsets), versus unrecoverable errors. For example,
the code I wrote handles your example below somewhat more easily:
// try to play data
for (i = 0; i < PLAYBACK_RETRIES; i++) {
if ((err = snd_pcm_writei (card->playback.fd, card->buffer, card->frames)) <
0) {
adebug ("Had to re-init playback.\n");
if ((err = snd_pcm_prepare (card->playback.fd)) < 0)
return -PCM_PREPARATION_FAILED;
}
break;
}
// we couldn't reprepare
if (i == PLAYBACK_RETRIES)
return -PCM_WRITE_FAILED;
return ALSA_SUCCESS;
PLAYBACK_RETRIES is arbitrary. Less robust software, or programs that were
very sensitive to any sort of intermittent unavailability would error out
immediately, without the for loop.
However, the documentation makes it fairly clear that in the case where a
writei() fails, you must "re-prepare" the card for PCM IO. This can be
attempted numerous times before giving up.
I agree that some sort of layman's wrapper might be helpful here, but please
don't go back to the ways of a crippled OSS API by preventing us from
handling these cases
> alsa_error_recovery() expands to 30 lines of more logic. This is pretty
> insane considering that libao _only_ writes data to device and does
> nothing else. If ALSA was done properly, the main loop would simply be:
This is ridiculous. Why bother? If libao is so simple, just break out if
re-preparation fails.
>
> err = internal->writei(internal->pcm_handle, ptr, len);
>
> /* it's possible that no data was transferred */
> if (err == -EAGAIN || err == -EINTR) {
> continue;
> }
>
> if (err < 0) {
> /* BAD BAD */
> }
This looks suspiciously like what I have above. Clear, simple, non-broken.
ALSA does it already.
> err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate,
> frames_in_period /* 0 for automated default */ ); err =
> alsa_simple_writei(); /* handless signal brokeness automagically */
> alsa_simple_close();
simple_{open,setup}() I agree with. There's no reason for that to have to be a
whole stack of separate functions. Use return codes to indicate the type of
failure.
simple_writei() might be okay, but it's pretty inflexible for even mildly
complex problems requiring more than "just write data". The old mechanisms
need to persist.
simple_close(), uhm.. snd_pcm_close (fd). Don't need it. I'm not sure why you
think that is necessary.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 84+ messages in thread
* [2.6 patch] schedule obsolete OSS drivers for removal
@ 2005-07-26 15:08 Adrian Bunk
2006-01-03 19:37 ` Adrian Bunk
0 siblings, 1 reply; 84+ messages in thread
From: Adrian Bunk @ 2005-07-26 15:08 UTC (permalink / raw)
To: linux-kernel
Cc: perex, alsa-devel, James, sailer, linux-sound, zab, kyle,
parisc-linux, jgarzik, Thorsten Knabe, zwane, zaitcev
This patch schedules obsolete OSS drivers (with ALSA drivers that
support the same hardware) for removal.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
I've Cc'ed the people listed in MAINTAINERS as being responsible for one
or more of these drivers, and I've also Cc'ed the ALSA people.
Please tell if any my driver selections is wrong.
Documentation/feature-removal-schedule.txt | 7 +
sound/oss/Kconfig | 79 ++++++++++++---------
2 files changed, 54 insertions(+), 32 deletions(-)
--- linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt.old 2005-07-26 16:50:05.000000000 +0200
+++ linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt 2005-07-26 16:51:24.000000000 +0200
@@ -44,0 +45,7 @@
+What: drivers depending on OBSOLETE_OSS_DRIVER
+When: October 2005
+Why: OSS drivers with ALSA replacements
+Who: Adrian Bunk <bunk@stusta.de>
+
+---------------------------
+
--- linux-2.6.13-rc3-mm1-modular/sound/oss/Kconfig.old 2005-07-23 21:04:56.000000000 +0200
+++ linux-2.6.13-rc3-mm1-modular/sound/oss/Kconfig 2005-07-24 01:22:11.000000000 +0200
@@ -4,9 +4,24 @@
# More hacking for modularisation.
#
# Prompt user for primary drivers.
+
+config OBSOLETE_OSS_DRIVER
+ bool "Obsolete OSS drivers"
+ depends on SOUND_PRIME
+ help
+ This patch enables support for obsolete OSS drivers that
+ are scheduled for removal in the near future since there
+ are ALSA drivers for the same hardware.
+
+ Please contact Adrian Bunk <bunk@stusta.de> if you had to
+ say Y here because your soundcard is not properly supported
+ by ALSA.
+
+ If unsure, say N.
+
config SOUND_BT878
tristate "BT878 audio dma"
- depends on SOUND_PRIME
+ depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
---help---
Audio DMA support for bt878 based grabber boards. As you might have
already noticed, bt878 is listed with two functions in /proc/pci.
@@ -22,7 +37,7 @@
config SOUND_CMPCI
tristate "C-Media PCI (CMI8338/8738)"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a PCI sound card using the CMI8338
or the CMI8738 chipset. Data on these chips are available at
@@ -61,7 +76,7 @@
config SOUND_EMU10K1
tristate "Creative SBLive! (EMU10K1)"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
---help---
Say Y or M if you have a PCI sound card using the EMU10K1 chipset,
such as the Creative SBLive!, SB PCI512 or Emu-APS.
@@ -95,7 +110,7 @@
config SOUND_CS4281
tristate "Crystal Sound CS4281"
- depends on SOUND_PRIME
+ depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
help
Picture and feature list at
<http://www.pcbroker.com/crystal4281.html>.
@@ -112,7 +127,7 @@
config SOUND_ES1370
tristate "Ensoniq AudioPCI (ES1370)"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a PCI sound card utilizing the Ensoniq
ES1370 chipset, such as Ensoniq's AudioPCI (non-97). To find
@@ -125,7 +140,7 @@
config SOUND_ES1371
tristate "Creative Ensoniq AudioPCI 97 (ES1371)"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a PCI sound card utilizing the Ensoniq
ES1371 chipset, such as Ensoniq's AudioPCI97. To find out if
@@ -138,7 +153,7 @@
config SOUND_ESSSOLO1
tristate "ESS Technology Solo1"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a PCI sound card utilizing the ESS Technology
Solo1 chip. To find out if your sound card uses a
@@ -149,7 +164,7 @@
config SOUND_MAESTRO
tristate "ESS Maestro, Maestro2, Maestro2E driver"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a sound system driven by ESS's Maestro line
of PCI sound chips. These include the Maestro 1, Maestro 2, and
@@ -158,28 +173,28 @@
config SOUND_MAESTRO3
tristate "ESS Maestro3/Allegro driver (EXPERIMENTAL)"
- depends on SOUND_PRIME && PCI && EXPERIMENTAL
+ depends on SOUND_PRIME && PCI && EXPERIMENTAL && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a sound system driven by ESS's Maestro 3
PCI sound chip.
config SOUND_ICH
tristate "Intel ICH (i8xx) audio support"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Support for integral audio in Intel's I/O Controller Hub (ICH)
chipset, as used on the 810/820/840 motherboards.
config SOUND_HARMONY
tristate "PA Harmony audio driver"
- depends on GSC_LASI && SOUND_PRIME
+ depends on GSC_LASI && SOUND_PRIME && OBSOLETE_OSS_DRIVER
help
Say 'Y' or 'M' to include support for Harmony soundchip
on HP 712, 715/new and many other GSC based machines.
config SOUND_SONICVIBES
tristate "S3 SonicVibes"
- depends on SOUND_PRIME
+ depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a PCI sound card utilizing the S3
SonicVibes chipset. To find out if your sound card uses a
@@ -218,7 +233,7 @@
config SOUND_AU1000
tristate "Au1000 Sound"
- depends on SOUND_PRIME && (SOC_AU1000 || SOC_AU1100 || SOC_AU1500)
+ depends on SOUND_PRIME && (SOC_AU1000 || SOC_AU1100 || SOC_AU1500) && OBSOLETE_OSS_DRIVER
config SOUND_AU1550_AC97
tristate "Au1550 AC97 Sound"
@@ -492,7 +507,7 @@
config SOUND_VIA82CXXX
tristate "VIA 82C686 Audio Codec"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y here to include support for the audio codec found on VIA
82Cxxx-based chips. Typically these are built into a motherboard.
@@ -546,7 +561,7 @@
config SOUND_AD1816
tristate "AD1816(A) based cards (EXPERIMENTAL)"
- depends on EXPERIMENTAL && SOUND_OSS
+ depends on EXPERIMENTAL && SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say M here if you have a sound card based on the Analog Devices
AD1816(A) chip.
@@ -563,7 +578,7 @@
config SOUND_SGALAXY
tristate "Aztech Sound Galaxy (non-PnP) cards"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
This module initializes the older non Plug and Play sound galaxy
cards from Aztech. It supports the Waverider Pro 32 - 3D and the
@@ -599,7 +614,7 @@
config SOUND_CS4232
tristate "Crystal CS4232 based (PnP) cards"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say Y here if you have a card based on the Crystal CS4232 chip set,
which uses its own Plug and Play protocol.
@@ -613,7 +628,7 @@
config SOUND_SSCAPE
tristate "Ensoniq SoundScape support"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Answer Y if you have a sound card based on the Ensoniq SoundScape
chipset. Such cards are being manufactured at least by Ensoniq, Spea
@@ -625,7 +640,7 @@
config SOUND_GUS
tristate "Gravis Ultrasound support"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say Y here for any type of Gravis Ultrasound card, including the GUS
or GUS MAX. See also <file:Documentation/sound/oss/ultrasound> for more
@@ -727,7 +742,7 @@
config SOUND_NM256
tristate "NM256AV/NM256ZX audio support"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say M here to include audio support for the NeoMagic 256AV/256ZX
chipsets. These are the audio chipsets found in the Sony
@@ -739,7 +754,7 @@
config SOUND_MAD16
tristate "OPTi MAD16 and/or Mozart based cards"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
---help---
Answer Y if your card has a Mozart (OAK OTI-601) or MAD16 (OPTi
82C928 or 82C929 or 82C931) audio interface chip. These chips are
@@ -860,7 +875,7 @@
config SOUND_AWE32_SYNTH
tristate "AWE32 synth"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say Y here if you have a Sound Blaster SB32, AWE32-PnP, SB AWE64 or
similar sound card. See <file:Documentation/sound/oss/README.awe>,
@@ -870,7 +885,7 @@
config SOUND_WAVEFRONT
tristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards"
- depends on SOUND_OSS && m
+ depends on SOUND_OSS && m && OBSOLETE_OSS_DRIVER
help
Answer Y or M if you have a Tropez Plus, Tropez or Maui sound card
and read the files <file:Documentation/sound/oss/Wavefront> and
@@ -878,7 +893,7 @@
config SOUND_MAUI
tristate "Limited support for Turtle Beach Wave Front (Maui, Tropez) synthesizers"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say Y here if you have a Turtle Beach Wave Front, Maui, or Tropez
sound card.
@@ -904,7 +919,7 @@
config SOUND_YM3812
tristate "Yamaha FM synthesizer (YM3812/OPL-3) support"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
---help---
Answer Y if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4).
Answering Y is usually a safe and recommended choice, however some
@@ -920,7 +935,7 @@
config SOUND_OPL3SA1
tristate "Yamaha OPL3-SA1 audio controller"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a Yamaha OPL3-SA1 sound chip, which is
usually built into motherboards. Read
@@ -932,7 +947,7 @@
config SOUND_OPL3SA2
tristate "Yamaha OPL3-SA2 and SA3 based PnP cards"
- depends on SOUND_OSS
+ depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a card based on one of these Yamaha sound
chipsets or the "SAx", which is actually a SA3. Read
@@ -946,7 +961,7 @@
config SOUND_YMFPCI
tristate "Yamaha YMF7xx PCI audio (native mode)"
- depends on SOUND_OSS && PCI
+ depends on SOUND_OSS && PCI && OBSOLETE_OSS_DRIVER
help
Support for Yamaha cards including the YMF711, YMF715, YMF718,
YMF719, YMF724, Waveforce 192XG, and Waveforce 192 Digital.
@@ -1088,11 +1103,11 @@
config SOUND_ALI5455
tristate "ALi5455 audio support"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
config SOUND_FORTE
tristate "ForteMedia FM801 driver"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y or M if you want driver support for the ForteMedia FM801 PCI
audio controller (Abit AU10, Genius Sound Maker, HP Workstation
@@ -1100,7 +1115,7 @@
config SOUND_RME96XX
tristate "RME Hammerfall (RME96XX) support"
- depends on SOUND_PRIME && PCI
+ depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
help
Say Y or M if you have a Hammerfall or Hammerfall light
multichannel card from RME. If you want to access advanced
@@ -1108,7 +1123,7 @@
config SOUND_AD1980
tristate "AD1980 front/back switch plugin"
- depends on SOUND_PRIME
+ depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
config SOUND_SH_DAC_AUDIO
tristate "SuperH DAC audio support"
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [2.6 patch] schedule obsolete OSS drivers for removal
@ 2006-01-03 19:37 ` Adrian Bunk
2006-01-03 23:10 ` Tomasz Kłoczko
0 siblings, 1 reply; 84+ messages in thread
From: Adrian Bunk @ 2006-01-03 19:37 UTC (permalink / raw)
To: Olivier Galibert, Alistair John Strachan, Tomasz Torcz,
Jan Engelhardt, Andi Kleen, perex, alsa-devel, James, sailer,
linux-sound, zab, kyle, parisc-linux, jgarzik, Thorsten Knabe,
zwane, zaitcev, linux-kernel
On Tue, Jan 03, 2006 at 08:24:49PM +0100, Olivier Galibert wrote:
> On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
> > This argument is basically watered down with devfs, udev, sysfs, etc. which
> > all have exactly the same issues. Should a crippled OSS API be the way
> > forward for Linux? I think not.
>
> And they're getting some real backlash because of that now. Hell,
> Linus' message was about udev in the first place.
The udev breakages might not have been nice, but OSS/ALSA is a
completely different issue:
OSS has been deprecated since ALSA was merged into the Linux kernel
_four years ago_.
And I'm only talking about removing drivers _with ALSA drivers for the
same hardware available_.
> As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> to setup a simple stereo 16bits output with OSS than the 13 ALSA
> library calls anyday. Especially with the impressive lack of
> documentation you get about what the hell is a period, or what you can
> do except aborting when you get an error.
>...
For a general OSS<->ALSA discussion, you are five years too late.
> OG.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [2.6 patch] schedule obsolete OSS drivers for removal
2006-01-03 19:37 ` Adrian Bunk
@ 2006-01-03 23:10 ` Tomasz Kłoczko
2006-01-04 9:37 ` [OT] ALSA userspace API complexity Alistair John Strachan
[not found] ` <mailman.1136368805.14661.linux-kernel2news@redhat.com>
0 siblings, 2 replies; 84+ messages in thread
From: Tomasz Kłoczko @ 2006-01-03 23:10 UTC (permalink / raw)
To: Adrian Bunk
Cc: Olivier Galibert, Alistair John Strachan, Tomasz Torcz,
Jan Engelhardt, Andi Kleen, perex, alsa-devel, James, sailer,
linux-sound, zab, kyle, parisc-linux, jgarzik, Thorsten Knabe,
zwane, zaitcev, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4834 bytes --]
On Tue, 3 Jan 2006, Adrian Bunk wrote:
> On Tue, Jan 03, 2006 at 08:24:49PM +0100, Olivier Galibert wrote:
>> On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
>>> This argument is basically watered down with devfs, udev, sysfs, etc. which
>>> all have exactly the same issues. Should a crippled OSS API be the way
>>> forward for Linux? I think not.
>>
>> And they're getting some real backlash because of that now. Hell,
>> Linus' message was about udev in the first place.
>
> The udev breakages might not have been nice, but OSS/ALSA is a
> completely different issue:
>
> OSS has been deprecated since ALSA was merged into the Linux kernel
> _four years ago_.
Also more than four years exist another thing: generaly sound suport in
Linux kernel is broken by design. Points where it is broken:
1) ALSA API forces not use devices files and many things on sound managing
level are handled on user space library. This dissallow civilized
redirection sound stream in runed application without this application
interractions (try redirect sound stream on runed application for
example to headset .. simple case skype .. oh you probaly don't know: in
current ALSA infrastructure there is no civilized way for handle
gadgests like BT headsets). In current ALSA API (IIRC) you must write in
special way applications for handle this (look pint 2)).
2) ALSA API is to complicated: most applications opens single sound
stream.
All what system user expect it is plaing sound by more then one
application with simple mixing sound streams. For me ALSA is prepared
like for handle ANY sound case .. EXCEPT all most simpler.
3) ALSA kernel architecture is to complicated. This main reason why
configuring sound on Linux is SO COMPLICATED. From my system:
# lsmod | grep ^snd | wc -l
19
All this for handle ONLY ONE sound card. Why not one alsa main module
and one with hardware backend module like in comarcial OSS ?
ALSA is also requires much more bigger code size than OSS variant
(count all snd* modules size, jackd and libasound and compare this with
OSS modules and user space OSS library size). Simillar is on allocated
memory in all system sound components.
Many task switches incurred by the current ALSA architecture
add quickly up to perceivalble deleys during processing. In many cases
sound must be handled with RT piorites so all code sise must possible
small for handle this with minimal latency.
4) ALSA mixing model is UNSECURE by design because all mixing sound
streams (for example with diffrent sampling rates) are performed
in user space.
Also using jackd also "creates problems" with RTing this proccess and
much more bigger problems on configure stage (for joe user).
All this can be handled in secure and proprer RT prioprities
ONLY on kernel space (so all gaming mith jackd or so is plain waste
of time). Only on kernel level is possible correctly handle all this.
With ALSA you can't extend in esy way for example SELinux for prevent
intercept sound streem from microphone by remote user. Current OSS API
is much more better for SELinux.
Why ? because all mixing on OSS is performed on kernel level.
I can't understand why ALSA developers still do not understands this
fundamentalt facts.
5) OSS API can be used not only on Linux. ALSA API can be used ONLY on
Linux.
This was, still is and (looks like allways) will be main reason
for not spending so many time as it is required on polish sound
interractions on Linux applications.
Still I can't understand why introducing ALSA *must* break OSS user
space API in so deep way.
OSS user space API also have some weak poinst on to big complications
because it allow implemet the same cases in to many forms (for some
cases it provides more than two ways for handle some scenarios).
I do not understand why on developing Linux soud support was forgoten
"don't move .. improve" sentence :>
OSS API paralelism looks lik was "correctly" implemnted in ALSA .. so
ALSA do not improves sound handling for user space applications and
additionaly introduces other own complications (ASA API documentations
in many cases isn't clear).
Conclution: removing OSS from Linux kernel and force using ALSA in last
four years was IMO one of the main resons why Linux still can't
effectively fight on desktop area and in future will be/can be one of the
most importand weak point which can drive Linux to die at all (in longer
period).
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
^ permalink raw reply [flat|nested] 84+ messages in thread
* [OT] ALSA userspace API complexity
2006-01-03 23:10 ` Tomasz Kłoczko
@ 2006-01-04 9:37 ` Alistair John Strachan
[not found] ` <mailman.1136368805.14661.linux-kernel2news@redhat.com>
1 sibling, 0 replies; 84+ messages in thread
From: Alistair John Strachan @ 2006-01-04 9:37 UTC (permalink / raw)
To: Tomasz Kłoczko
Cc: Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, perex, alsa-devel, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, zaitcev,
linux-kernel
On Tuesday 03 January 2006 23:10, Tomasz Kłoczko wrote:
[snip]
>
> 2) ALSA API is to complicated: most applications opens single sound
> stream.
FUD and nonsense. I've written many DSP applications and very often I can
recycle the same code for use in them. Here's an example, abstracted,
commented, handling errors from the subsystem, in just over 100 LOC.
http://devzero.co.uk/~alistair/alsa/
The API is really _only_ complicated because it expects you to set things OSS
either can't handle or doesn't allow you to configure. Things that very often
an application will eventually care about. All this for the sake of 5 minutes
reading documentation, and each API call almost identical in design.
Personally, I found the lack of documentation for some of the setup API
annoying, but it's since been rectified and each call is humanly
understandable.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <mailman.1136368805.14661.linux-kernel2news@redhat.com>]
* Re: [OT] ALSA userspace API complexity
[not found] ` <mailman.1136368805.14661.linux-kernel2news@redhat.com>
@ 2006-01-04 11:00 ` Pete Zaitcev
2006-01-04 11:35 ` Jaroslav Kysela
0 siblings, 1 reply; 84+ messages in thread
From: Pete Zaitcev @ 2006-01-04 11:00 UTC (permalink / raw)
To: Alistair John Strachan, kloczek
Cc: Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, perex, alsa-devel, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, zaitcev,
linux-kernel
On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > 2) ALSA API is to complicated: most applications opens single sound
> > stream.
>
> FUD and nonsense. []
> http://devzero.co.uk/~alistair/alsa/
That's the kicker, isn't it? Once you get used to it, it's a workable
API, if kinky and verbose. I have a real life example, too:
http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
But arriving on the solution costed a lot of torn hair. Look at this
bald head here! And who is going to pay my medical bills when ALSA
causes me ulcers, Jaroslav?
-- Pete
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 11:00 ` Pete Zaitcev
@ 2006-01-04 11:35 ` Jaroslav Kysela
2006-01-04 11:47 ` Pete Zaitcev
` (2 more replies)
0 siblings, 3 replies; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-04 11:35 UTC (permalink / raw)
To: Pete Zaitcev
Cc: Alistair John Strachan, kloczek, Adrian Bunk, Olivier Galibert,
Tomasz Torcz, Jan Engelhardt, Andi Kleen, alsa-devel, James,
sailer, linux-sound, zab, kyle, parisc-linux, jgarzik,
Thorsten Knabe, zwane, linux-kernel
On Wed, 4 Jan 2006, Pete Zaitcev wrote:
> On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
>
> > > 2) ALSA API is to complicated: most applications opens single sound
> > > stream.
> >
> > FUD and nonsense. []
> > http://devzero.co.uk/~alistair/alsa/
>
> That's the kicker, isn't it? Once you get used to it, it's a workable
> API, if kinky and verbose. I have a real life example, too:
> http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
> But arriving on the solution costed a lot of torn hair. Look at this
> bald head here! And who is going to pay my medical bills when ALSA
> causes me ulcers, Jaroslav?
Well, the ALSA primary goal is to be the complete HAL not hidding the
extra hardware capabilities to applications. So API might look a bit
complicated for the first glance, but the ALSA interface code for simple
applications is not so big, isn't?
Also, note that app developers are not forced to use ALSA directly - there
is a lot of "portable" sound API libraries having an ALSA backend doing
this job quite effectively. We can add a simple (like OSS) API layer
into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
some support functions for the easy PCM device initialization might be
a good idea.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 11:35 ` Jaroslav Kysela
@ 2006-01-04 11:47 ` Pete Zaitcev
2006-01-04 14:23 ` Alistair John Strachan
2006-01-05 12:01 ` Tomasz Kłoczko
2 siblings, 0 replies; 84+ messages in thread
From: Pete Zaitcev @ 2006-01-04 11:47 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: s0348365, kloczek, bunk, galibert, zdzichu, jengelh, ak,
alsa-devel, James, sailer, linux-sound, zab, kyle, parisc-linux,
jgarzik, linux, zwane, linux-kernel
On Wed, 4 Jan 2006 12:35:25 +0100 (CET), Jaroslav Kysela <perex@suse.cz> wrote:
> [...] We can add a simple (like OSS) API layer
> into alsa-lib, but I'm not sure, if it's worth to do it.
Probably not worth it. But having more examples like Alistair's in docs
would be a good idea, I expect. The silly patch I quoted is one of
the hottest documents on my webpage. People need this stuff, and
cannot find it.
-- Pete
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 11:35 ` Jaroslav Kysela
2006-01-04 11:47 ` Pete Zaitcev
@ 2006-01-04 14:23 ` Alistair John Strachan
2006-01-05 11:41 ` Olivier Galibert
2006-01-05 12:01 ` Tomasz Kłoczko
2 siblings, 1 reply; 84+ messages in thread
From: Alistair John Strachan @ 2006-01-04 14:23 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Pete Zaitcev, kloczek, Adrian Bunk, Olivier Galibert,
Tomasz Torcz, Jan Engelhardt, Andi Kleen, alsa-devel, James,
sailer, linux-sound, zab, kyle, parisc-linux, jgarzik,
Thorsten Knabe, zwane, linux-kernel
On Wednesday 04 January 2006 11:35, Jaroslav Kysela wrote:
> On Wed, 4 Jan 2006, Pete Zaitcev wrote:
> > On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan
<s0348365@sms.ed.ac.uk> wrote:
> > > > 2) ALSA API is to complicated: most applications opens single sound
> > > > stream.
> > >
> > > FUD and nonsense. []
> > > http://devzero.co.uk/~alistair/alsa/
> >
> > That's the kicker, isn't it? Once you get used to it, it's a workable
> > API, if kinky and verbose. I have a real life example, too:
> > http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
> > But arriving on the solution costed a lot of torn hair. Look at this
> > bald head here! And who is going to pay my medical bills when ALSA
> > causes me ulcers, Jaroslav?
>
> Well, the ALSA primary goal is to be the complete HAL not hidding the
> extra hardware capabilities to applications. So API might look a bit
> complicated for the first glance, but the ALSA interface code for simple
> applications is not so big, isn't?
>
> Also, note that app developers are not forced to use ALSA directly - there
> is a lot of "portable" sound API libraries having an ALSA backend doing
> this job quite effectively. We can add a simple (like OSS) API layer
> into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
> some support functions for the easy PCM device initialization might be
> a good idea.
I agree. I see a lot of steam blowing and hot air from people complaining
about ALSA. Your API is perfectly usable and aptly translates generic issues
with any sound hardware (such as xruns and hardware buffering) without hiding
them away so they cannot be manipulated.
The only significant issue with ALSA is the number of tunables that you have
to set with individual function calls. Personally, I like this approach, but
I do always end up wrapping them in some structure, so perhaps you could have
a "quick and dirty" one liner that would either be:
snd_hw_set_params (fd, ... long list of sensible parameters ...)
snd_sw_set_params (fd, ... ditto ...)
Or, take an ioctl approach (which people here seem to love; urgh):
struct hw_params my_hw_params = {
PCM_LE_16,
2,
blah,
};
...
snd_hw_set_params (fd, &my_hw_params);
snd_sw_set_params (fd, &my_sw_params);
I think your time is better spent addressing the issues of "bloat" in the
kernel side of things (the more code in userspace the better, despite what
ridiculous statements there have been on this thread to the contrary).
_Documentation_ clearly distinguishing between "sw" paramters and "hw"
parameters would also be good, as when I first learnt ALSA (some 3 years
ago), I didn't even know what these were!
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 14:23 ` Alistair John Strachan
@ 2006-01-05 11:41 ` Olivier Galibert
0 siblings, 0 replies; 84+ messages in thread
From: Olivier Galibert @ 2006-01-05 11:41 UTC (permalink / raw)
To: Alistair John Strachan
Cc: Jaroslav Kysela, Pete Zaitcev, kloczek, Adrian Bunk,
Tomasz Torcz, Jan Engelhardt, Andi Kleen, alsa-devel, James,
sailer, linux-sound, zab, kyle, parisc-linux, jgarzik,
Thorsten Knabe, zwane, linux-kernel
On Wed, Jan 04, 2006 at 02:23:42PM +0000, Alistair John Strachan wrote:
> Or, take an ioctl approach (which people here seem to love; urgh):
I'm afraid you missed the point there. ioctl or not ioctl is not
important, and yes, ioctls have a lot of problems. The problem is
having a library define the public interface for kernel services. I
don't see how come Linus accepted that, unless he doesn't really use
sound and just doesn't care, which is my current interpretation.
OG.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-04 11:35 ` Jaroslav Kysela
2006-01-04 11:47 ` Pete Zaitcev
2006-01-04 14:23 ` Alistair John Strachan
@ 2006-01-05 12:01 ` Tomasz Kłoczko
2006-01-05 12:23 ` Jaroslav Kysela
2006-01-05 12:47 ` Leonard Milcin Jr.
2 siblings, 2 replies; 84+ messages in thread
From: Tomasz Kłoczko @ 2006-01-05 12:01 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Pete Zaitcev, Alistair John Strachan, Adrian Bunk,
Olivier Galibert, Tomasz Torcz, Jan Engelhardt, Andi Kleen,
alsa-devel, James, sailer, linux-sound, zab, kyle, parisc-linux,
jgarzik, Thorsten Knabe, zwane, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2175 bytes --]
On Wed, 4 Jan 2006, Jaroslav Kysela wrote:
> On Wed, 4 Jan 2006, Pete Zaitcev wrote:
>
>> On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
>>
>>>> 2) ALSA API is to complicated: most applications opens single sound
>>>> stream.
>>>
>>> FUD and nonsense. []
>>> http://devzero.co.uk/~alistair/alsa/
>>
>> That's the kicker, isn't it? Once you get used to it, it's a workable
>> API, if kinky and verbose. I have a real life example, too:
>> http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
>> But arriving on the solution costed a lot of torn hair. Look at this
>> bald head here! And who is going to pay my medical bills when ALSA
>> causes me ulcers, Jaroslav?
>
> Well, the ALSA primary goal is to be the complete HAL not hidding the
> extra hardware capabilities to applications. So API might look a bit
> complicated for the first glance, but the ALSA interface code for simple
> applications is not so big, isn't?
Sorry Jaroslav byt this not unix way.
Wny applications myst know anything about hardware layer ?
In unix way all this details are rolled on kernel layer.
> Also, note that app developers are not forced to use ALSA directly - there
> is a lot of "portable" sound API libraries having an ALSA backend doing
> this job quite effectively. We can add a simple (like OSS) API layer
> into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
> some support functions for the easy PCM device initialization might be
> a good idea.
If we have so many "portable" sound API libraries .. look most of them
uses the same way for handle sound on kernel interaction. Is this
complicated ALSA way is realy neccessary ?
For example .. jackd can use OSS API for handle sound device.
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
Allow me translate sentence from my signature to english
"People do not have problems they create them themselves"
and ALSA case matches in 100%.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 12:01 ` Tomasz Kłoczko
@ 2006-01-05 12:23 ` Jaroslav Kysela
2006-01-05 14:21 ` Olivier Galibert
2006-01-05 15:07 ` Tomasz Kłoczko
2006-01-05 12:47 ` Leonard Milcin Jr.
1 sibling, 2 replies; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-05 12:23 UTC (permalink / raw)
To: Tomasz Kłoczko
Cc: Pete Zaitcev, Alistair John Strachan, Adrian Bunk,
Olivier Galibert, Tomasz Torcz, Jan Engelhardt, Andi Kleen,
ALSA development, James, sailer, linux-sound, zab, kyle,
parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2699 bytes --]
On Thu, 5 Jan 2006, Tomasz Kłoczko wrote:
> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:
> > Well, the ALSA primary goal is to be the complete HAL not hidding the
> > extra hardware capabilities to applications. So API might look a bit
> > complicated for the first glance, but the ALSA interface code for simple
> > applications is not so big, isn't?
>
> Sorry Jaroslav byt this not unix way.
> Wny applications myst know anything about hardware layer ?
> In unix way all this details are rolled on kernel layer.
It means that you are saying that kernel should be bigger and bigger.
Please, see the graphics APIs. Why we have X servers in user space (and
only some supporting code is in the kernel) then? It's because if we
would move everything into kernel it will be even more bloated. The kernel
should do really the basic things like direct hardware access, DMA
transfer etc.
> > Also, note that app developers are not forced to use ALSA directly -
> > there is a lot of "portable" sound API libraries having an ALSA
> > backend doing this job quite effectively. We can add a simple (like
> > OSS) API layer into alsa-lib, but I'm not sure, if it's worth to do
> > it. Perhaps, adding some support functions for the easy PCM device
> > initialization might be a good idea.
>
> If we have so many "portable" sound API libraries .. look most of them
> uses the same way for handle sound on kernel interaction. Is this
> complicated ALSA way is realy neccessary ? For example .. jackd can use
> OSS API for handle sound device.
The grounds of ALSA APIs are not complicated. The complicated are the
extra features (like stream linking) which can be included conditionaly.
Note that during API development, mostly users requesting extra features
were speak loudly, others were only watching.
We know that the reduction requests have points for embedded systems etc.
And we will definitely try to sort "real-core" and "extra" things.
Also, note that if OSS used a library to access to sound devices, we won't
ever have such problems with the OSS API redirection to another API.
I already created a prototype of OSS API redirector (part of alsa-oss
package), see:
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/README?rev=1.1&view=markup
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/oss-redir.h?rev=1.6&view=markup
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/oss-redir.c?rev=1.9&view=markup
But it's a question, if OSS application developers take this proposal.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 12:23 ` Jaroslav Kysela
@ 2006-01-05 14:21 ` Olivier Galibert
2006-01-05 15:07 ` Tomasz Kłoczko
1 sibling, 0 replies; 84+ messages in thread
From: Olivier Galibert @ 2006-01-05 14:21 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Tomasz K?oczko, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Tomasz Torcz, Jan Engelhardt, Andi Kleen,
ALSA development, James, sailer, linux-sound, zab, kyle,
parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
On Thu, Jan 05, 2006 at 01:23:23PM +0100, Jaroslav Kysela wrote:
> It means that you are saying that kernel should be bigger and bigger.
> Please, see the graphics APIs. Why we have X servers in user space (and
> only some supporting code is in the kernel) then? It's because if we
> would move everything into kernel it will be even more bloated. The kernel
> should do really the basic things like direct hardware access, DMA
> transfer etc.
You plan to remove the network stack from the kernel when then? X is
in user space for some rather strange values of userspace[1] for
historical and political reasons, not technical ones. When
performance raises its ugly head and you end up having to listen to
engineers again you end up with DRI and that:
Module Size Used by
nvidia 3464380 12
X is a beautiful example of how things should not have been done. Its
only redeeming quality is that it exists and works, and that's
definitively a non-negligible one.
> But it's a question, if OSS application developers take this proposal.
You seem to be missing the point that the entire reason why OSS is
important is that it isn't a library.
OG.
[1] Direct hardware access, DMA, pci enumeration, hardware
reconfiguration, what a beautiful userspace we have there.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 12:23 ` Jaroslav Kysela
2006-01-05 14:21 ` Olivier Galibert
@ 2006-01-05 15:07 ` Tomasz Kłoczko
2006-01-05 16:14 ` Takashi Iwai
` (2 more replies)
1 sibling, 3 replies; 84+ messages in thread
From: Tomasz Kłoczko @ 2006-01-05 15:07 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Pete Zaitcev, Alistair John Strachan, Adrian Bunk,
Olivier Galibert, Tomasz Torcz, Jan Engelhardt, Andi Kleen,
ALSA development, James, sailer, linux-sound, zab, kyle,
parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3794 bytes --]
On Thu, 5 Jan 2006, Jaroslav Kysela wrote:
> On Thu, 5 Jan 2006, Tomasz Kłoczko wrote:
>
>> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:
>
>>> Well, the ALSA primary goal is to be the complete HAL not hidding the
>>> extra hardware capabilities to applications. So API might look a bit
>>> complicated for the first glance, but the ALSA interface code for simple
>>> applications is not so big, isn't?
>>
>> Sorry Jaroslav byt this not unix way.
>> Wny applications myst know anything about hardware layer ?
>> In unix way all this details are rolled on kernel layer.
>
> It means that you are saying that kernel should be bigger and bigger.
> Please, see the graphics APIs. Why we have X servers in user space (and
> only some supporting code is in the kernel) then? It's because if we
> would move everything into kernel it will be even more bloated. The kernel
> should do really the basic things like direct hardware access, DMA
> transfer etc.
List all neccessary feactures and abstract them. Below this layer you
can plug to this all device drivers. Where is the problem ?
Cureent way moves some importand details like mixing to user space
library.
All abstraction are NOW coded but some parts of this abstraction are on
library level and you are wrong because this still ONE abstraction
(not multiple/growing).
Moving some patrs of this abstraction to user space level DISSALLOW secure
manage because you do not have *single point of entry to this layer*. Try
plug library abstraction to SELinux layer. Can you do this with ALSA way ?
If you have sound device with hardware mixer(s) ALSA now work
transparently.
If you have sound device without this soft mixing is moved to user space
.. but applications do not need know about this even now because all
neccessary details are handled on library level. Is it ?
So question is: why the hell *ALL* mixing details are not moved to kernel
space to SIMPLE and NOT GROWING abstraction ?
Next thing: look again on diffrent types sound devices. What do you have ?
Sound output/input device(s) wich acan be oppened with diffrent sampling
rates and diffrent samle sizes or only constatns sample rates/sizes, mixer
devic(s), midi ... all ot them CAN BE abstracted to form with hidded ALL
hardware details. Problem with growing abstraction size ocurres ONLY when
some new hardware will provides new hardware sound part class/type.
Generaly this NOT OCCURRES in case sound devices.
So .. I don't see your "kernel should be bigger and bigger". If you
want continue please describe this.
BTW X11: please don't use X11 examplary. Despite the fact that ther are
quite a lot of people working around it's defficiencies in a moderately
successfully way, X11 has to be considered a piece of rotten bloated
mindless utter crap and by no way as an exemplary piece of software design
exercise.
In case ALSA now questions are very basic:
- all hardware mixers are very simillar with very izomorphic interface
(read this as: this can be very easy abstracted) and we have only one
other case with soft mixing when this hardwware must be emulated in
software .. so all this details can be rolled to one leyer on kernel
level.
So: why all mixing details are not in kernel space ?
- KNOWN FACT is OSS provides simpler API for user space for handle
usual cases.
Why Linux can't provide only OSS API abstraction for user space
application ? And/or why ALSA developers want to replace this by
mostly bloated and pourly documented ALSA user space API ?
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 15:07 ` Tomasz Kłoczko
@ 2006-01-05 16:14 ` Takashi Iwai
2006-01-05 17:19 ` Marcin Dalecki
` (2 more replies)
2006-01-05 18:56 ` Lee Revell
2006-01-05 22:39 ` Joern Nettingsmeier
2 siblings, 3 replies; 84+ messages in thread
From: Takashi Iwai @ 2006-01-05 16:14 UTC (permalink / raw)
To: Tomasz Kłoczko
Cc: Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, ALSA development, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
At Thu, 5 Jan 2006 16:07:02 +0100 (CET),
Tomasz Kłoczko wrote:
>
> On Thu, 5 Jan 2006, Jaroslav Kysela wrote:
>
> > On Thu, 5 Jan 2006, Tomasz Kłoczko wrote:
> >
> >> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:
> >
> >>> Well, the ALSA primary goal is to be the complete HAL not hidding the
> >>> extra hardware capabilities to applications. So API might look a bit
> >>> complicated for the first glance, but the ALSA interface code for simple
> >>> applications is not so big, isn't?
> >>
> >> Sorry Jaroslav byt this not unix way.
> >> Wny applications myst know anything about hardware layer ?
> >> In unix way all this details are rolled on kernel layer.
> >
> > It means that you are saying that kernel should be bigger and bigger.
> > Please, see the graphics APIs. Why we have X servers in user space (and
> > only some supporting code is in the kernel) then? It's because if we
> > would move everything into kernel it will be even more bloated. The kernel
> > should do really the basic things like direct hardware access, DMA
> > transfer etc.
>
> List all neccessary feactures and abstract them. Below this layer you
> can plug to this all device drivers. Where is the problem ?
> Cureent way moves some importand details like mixing to user space
> library.
> All abstraction are NOW coded but some parts of this abstraction are on
> library level and you are wrong because this still ONE abstraction
> (not multiple/growing).
> Moving some patrs of this abstraction to user space level DISSALLOW secure
> manage because you do not have *single point of entry to this layer*. Try
> plug library abstraction to SELinux layer. Can you do this with ALSA way ?
I don't understand this. The alsa-lib doesn't skip the h/w access.
It still accesses the device file as usual, open/close/ioctls. If the
h/w to do softmix is restricted, you can't use it, too.
Or, am I missing something else?
> If you have sound device with hardware mixer(s) ALSA now work
> transparently.
> If you have sound device without this soft mixing is moved to user space
> .. but applications do not need know about this even now because all
> neccessary details are handled on library level. Is it ?
> So question is: why the hell *ALL* mixing details are not moved to kernel
> space to SIMPLE and NOT GROWING abstraction ?
Because many people believe that the softmix in the kernel space is
evil. The discussion aboult this could be a long thread.
(snip)
> In case ALSA now questions are very basic:
>
> - all hardware mixers are very simillar with very izomorphic interface
> (read this as: this can be very easy abstracted) and we have only one
> other case with soft mixing when this hardwware must be emulated in
> software .. so all this details can be rolled to one leyer on kernel
> level.
> So: why all mixing details are not in kernel space ?
The problem is not the interface but the implementation.
> - KNOWN FACT is OSS provides simpler API for user space for handle
> usual cases.
Please define "usual cases".
> Why Linux can't provide only OSS API abstraction for user space
> application ? And/or why ALSA developers want to replace this by
> mostly bloated and pourly documented ALSA user space API ?
Because OSS API doesn't cover many things. For example,
- PCM with non-interleaved formats
- PCM with 3-bytes-packed 24bit formats
These functions are popluar on many sound devices.
In addition, imagine how you would implement the following:
- Combination of multiple devices
- Split of channels to concurrent accesses
- Handling of floating pointer samples
- Post/pre-effects (like chorus/reverb)
Forcing OSS API means to force to process the all things above in
the kernel. I guess many people would disagree with it.
Takashi
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 16:14 ` Takashi Iwai
@ 2006-01-05 17:19 ` Marcin Dalecki
2006-01-05 20:13 ` Tomasz Kłoczko
2006-01-05 23:06 ` Hannu Savolainen
2 siblings, 0 replies; 84+ messages in thread
From: Marcin Dalecki @ 2006-01-05 17:19 UTC (permalink / raw)
To: Takashi Iwai
Cc: Tomasz Kłoczko, Jaroslav Kysela, Pete Zaitcev,
Alistair John Strachan, Adrian Bunk, Olivier Galibert,
Tomasz Torcz, Jan Engelhardt, Andi Kleen, ALSA development,
James, sailer, linux-sound, zab, kyle, parisc-linux, jgarzik,
Thorsten Knabe, zwane, LKML
On 2006-01-05, at 17:14, Takashi Iwai wrote:
>
> Because OSS API doesn't cover many things. For example,
>
> - PCM with non-interleaved formats
> - PCM with 3-bytes-packed 24bit formats
>
> These functions are popluar on many sound devices.
>
> In addition, imagine how you would implement the following:
>
> - Combination of multiple devices
> - Split of channels to concurrent accesses
> - Handling of floating pointer samples
> - Post/pre-effects (like chorus/reverb)
>
> Forcing OSS API means to force to process the all things above in
> the kernel. I guess many people would disagree with it.
Not at all. What a sane system would do would be the following:
1. Provide kernel devices, which are supposed to be used by a single
user space helper
daemon claiming them once and for ever. Those would expose the
extensive low level hardware interface
which is required to implement this kind of processing. Those
controlling devices would be basically
accessible by the root user.
2. Provide kernel devices, which are supposed to be used by consumer
applications. Those would
be basically just engaged in the data lifting between the user space
application
the kernel and the processing daemon application.
Very much a design similar what can be found in the area of terminal
support where there is a distinction
between a pseudo tty and a tty driver. Actually if one thinks about
it the sound output and feeding *should* be associated with a
terminal device. Keyboard/Micro Display/Speakers - pretty much the
same data flow.
Very much the same as the relation between the ethernet interface
card drivers and the netowork stack support.
No the alsa mess just basically hurrying up to map the hardware
facilities as primitively as possible in to user space for messing
around inside some "library" which is supposed to do wonders.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 16:14 ` Takashi Iwai
2006-01-05 17:19 ` Marcin Dalecki
@ 2006-01-05 20:13 ` Tomasz Kłoczko
2006-01-07 14:32 ` Takashi Iwai
2006-01-05 23:06 ` Hannu Savolainen
2 siblings, 1 reply; 84+ messages in thread
From: Tomasz Kłoczko @ 2006-01-05 20:13 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, ALSA development, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4987 bytes --]
[..]
>>> It means that you are saying that kernel should be bigger and bigger.
>>> Please, see the graphics APIs. Why we have X servers in user space (and
>>> only some supporting code is in the kernel) then? It's because if we
>>> would move everything into kernel it will be even more bloated. The kernel
>>> should do really the basic things like direct hardware access, DMA
>>> transfer etc.
>>
>> List all neccessary feactures and abstract them. Below this layer you
>> can plug to this all device drivers. Where is the problem ?
>> Cureent way moves some importand details like mixing to user space
>> library.
>> All abstraction are NOW coded but some parts of this abstraction are on
>> library level and you are wrong because this still ONE abstraction
>> (not multiple/growing).
>> Moving some patrs of this abstraction to user space level DISSALLOW secure
>> manage because you do not have *single point of entry to this layer*. Try
>> plug library abstraction to SELinux layer. Can you do this with ALSA way ?
>
> I don't understand this. The alsa-lib doesn't skip the h/w access.
> It still accesses the device file as usual, open/close/ioctls. If the
> h/w to do softmix is restricted, you can't use it, too.
> Or, am I missing something else?
Soft mixing is performed by writing to allocated shared memory block.
Try to use SELinux on dissalow use SHM only for mixing souds.
In case performing ALL (possible) mixing tricks you have SINGLE point of
entry from any application. Using SHM with r/w permission allow one
allicattions dump sound streams writed by other applications.
>> If you have sound device with hardware mixer(s) ALSA now work
>> transparently.
>> If you have sound device without this soft mixing is moved to user space
>> .. but applications do not need know about this even now because all
>> neccessary details are handled on library level. Is it ?
>> So question is: why the hell *ALL* mixing details are not moved to kernel
>> space to SIMPLE and NOT GROWING abstraction ?
>
> Because many people believe that the softmix in the kernel space is
> evil. The discussion aboult this could be a long thread.
Moment .. are you want to say: there is no compact mixing abstraction
layer in ALSA because because ALSA is developed by believers ? (not
technicians/enginers ?)
Sorry .. be so kind and try to answer on my question using only stricte
*technical arguments*.
> (snip)
>> In case ALSA now questions are very basic:
>>
>> - all hardware mixers are very simillar with very izomorphic interface
>> (read this as: this can be very easy abstracted) and we have only one
>> other case with soft mixing when this hardwware must be emulated in
>> software .. so all this details can be rolled to one leyer on kernel
>> level.
>> So: why all mixing details are not in kernel space ?
>
> The problem is not the interface but the implementation.
Hmm .. if "ALSA is developed by belivers" slowny now I undestand .. all
this :>
[..]
> Because OSS API doesn't cover many things. For example,
>
> - PCM with non-interleaved formats
> - PCM with 3-bytes-packed 24bit formats
Not true. Download OSS from opensound. You can find in soundcard.h
AFMT_S24_PACKED define.
> These functions are popluar on many sound devices.
>
> In addition, imagine how you would implement the following:
>
> - Combination of multiple devices
> - Split of channels to concurrent accesses
> - Handling of floating pointer samples
> - Post/pre-effects (like chorus/reverb)
Are you want say something like: architesture of OSS is so bad there is no
civilized way for extending this ? (except: chorus/reverb are now handled
by comercial OSS).
Correct me if I'm wrong: his not true.
> Forcing OSS API means to force to process the all things above in
> the kernel. I guess many people would disagree with it.
Completly disagee.
And another argument: comercial OSS have ALSA emulation and ALSA have OSS
emulation.
So .. there is no general architecture problems on implemting both varians
(in both variants sits only some implementation bugs).
This unhides one fact: *ALSA and OSS are mostly izomorphic* (look on
similarities ALSA and OSS device drivers architecture).
And if it is true there was/is no strong arguments for droping OSS and
replace this by ALSA. As I sayd ALSA is only on Linux. Using OSS allow
easier develpment soud support in user space applications for some group
of currently used unices. This is IMO strong argument .. much stronger
than existing or not group of belivers. For me now switching to ALSA have
only *political groud* .. nothing more. Interesting .. how long Linux can
survive without looking on some economic aspects ?
If you allow .. EOT
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 20:13 ` Tomasz Kłoczko
@ 2006-01-07 14:32 ` Takashi Iwai
2006-01-08 2:03 ` Olivier Galibert
0 siblings, 1 reply; 84+ messages in thread
From: Takashi Iwai @ 2006-01-07 14:32 UTC (permalink / raw)
To: Tomasz Kłoczko
Cc: Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, ALSA development, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
At Thu, 5 Jan 2006 21:13:25 +0100 (CET),
Tomasz Kłoczko wrote:
>
> [..]
> >>> It means that you are saying that kernel should be bigger and bigger.
> >>> Please, see the graphics APIs. Why we have X servers in user space (and
> >>> only some supporting code is in the kernel) then? It's because if we
> >>> would move everything into kernel it will be even more bloated. The kernel
> >>> should do really the basic things like direct hardware access, DMA
> >>> transfer etc.
> >>
> >> List all neccessary feactures and abstract them. Below this layer you
> >> can plug to this all device drivers. Where is the problem ?
> >> Cureent way moves some importand details like mixing to user space
> >> library.
> >> All abstraction are NOW coded but some parts of this abstraction are on
> >> library level and you are wrong because this still ONE abstraction
> >> (not multiple/growing).
> >> Moving some patrs of this abstraction to user space level DISSALLOW secure
> >> manage because you do not have *single point of entry to this layer*. Try
> >> plug library abstraction to SELinux layer. Can you do this with ALSA way ?
> >
> > I don't understand this. The alsa-lib doesn't skip the h/w access.
> > It still accesses the device file as usual, open/close/ioctls. If the
> > h/w to do softmix is restricted, you can't use it, too.
> > Or, am I missing something else?
>
> Soft mixing is performed by writing to allocated shared memory block.
> Try to use SELinux on dissalow use SHM only for mixing souds.
> In case performing ALL (possible) mixing tricks you have SINGLE point of
> entry from any application. Using SHM with r/w permission allow one
> allicattions dump sound streams writed by other applications.
Yes, it's a known problem to be fixed. But, it's no excuse to do
_everything_ in the kernel (which OSS requires).
> >> If you have sound device with hardware mixer(s) ALSA now work
> >> transparently.
> >> If you have sound device without this soft mixing is moved to user space
> >> .. but applications do not need know about this even now because all
> >> neccessary details are handled on library level. Is it ?
> >> So question is: why the hell *ALL* mixing details are not moved to kernel
> >> space to SIMPLE and NOT GROWING abstraction ?
> >
> > Because many people believe that the softmix in the kernel space is
> > evil. The discussion aboult this could be a long thread.
>
> Moment .. are you want to say: there is no compact mixing abstraction
> layer in ALSA because because ALSA is developed by believers ? (not
> technicians/enginers ?)
> Sorry .. be so kind and try to answer on my question using only stricte
> *technical arguments*.
I stated above because I know it will be a discussion without a clear
end. From the convenence viewpoint, doing everthing in the kernel
including the software mixing is fine. But, do you want to it -- to
do EVERTHING in the kernel with a great risk of system down and the
programming restrictions (no FP, etc)?
> > Because OSS API doesn't cover many things. For example,
> >
> > - PCM with non-interleaved formats
> > - PCM with 3-bytes-packed 24bit formats
>
> Not true. Download OSS from opensound. You can find in soundcard.h
> AFMT_S24_PACKED define.
And if the application doesn't support, who and where converts it?
With OSS API, it's a job of the kernel.
> > These functions are popluar on many sound devices.
> >
> > In addition, imagine how you would implement the following:
> >
> > - Combination of multiple devices
> > - Split of channels to concurrent accesses
> > - Handling of floating pointer samples
> > - Post/pre-effects (like chorus/reverb)
>
> Are you want say something like: architesture of OSS is so bad there is no
> civilized way for extending this ? (except: chorus/reverb are now handled
> by comercial OSS).
> Correct me if I'm wrong: his not true.
Could you tell me how do you handle the floating point in the kernel
code?
> This unhides one fact: *ALSA and OSS are mostly izomorphic* (look on
> similarities ALSA and OSS device drivers architecture).
>
> And if it is true there was/is no strong arguments for droping OSS and
> replace this by ALSA. As I sayd ALSA is only on Linux. Using OSS allow
> easier develpment soud support in user space applications for some group
> of currently used unices. This is IMO strong argument .. much stronger
> than existing or not group of belivers. For me now switching to ALSA have
> only *political groud* .. nothing more. Interesting .. how long Linux can
> survive without looking on some economic aspects ?
Don't get me wrong. I, as ALSA developer, don't believe that OSS API
would disappear. The API will remain. But the implementation may
change. That's all what is happening -- Adrian has asked to drop the
codes which are implemented differently (on ALSA). No one requested
to drop the API support.
Takashi
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-07 14:32 ` Takashi Iwai
@ 2006-01-08 2:03 ` Olivier Galibert
2006-01-08 2:26 ` Martin Drab
2006-01-08 9:42 ` Jaroslav Kysela
0 siblings, 2 replies; 84+ messages in thread
From: Olivier Galibert @ 2006-01-08 2:03 UTC (permalink / raw)
To: Takashi Iwai; +Cc: ALSA development, linux-sound, LKML
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.
OG.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 2:03 ` Olivier Galibert
@ 2006-01-08 2:26 ` Martin Drab
2006-01-08 13:21 ` Olivier Galibert
2006-01-08 9:42 ` Jaroslav Kysela
1 sibling, 1 reply; 84+ messages in thread
From: Martin Drab @ 2006-01-08 2:26 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Takashi Iwai, ALSA development, linux-sound, LKML
On Sun, 8 Jan 2006, Olivier Galibert wrote:
> > 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.
I think that the point was, that switching from userspace to kernelspace
then to userspace again and back to kernelspace in order to do something,
that could have been done directly in the userspace, and though could save
those two unnecessary switches, is an unnecessary overhead, which may not
necessarily be that insignificant if it's done so often (which for
streaming audio is the case). Why doing things complicated when there is
no evident gain from it, or is there?
Martin
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 2:26 ` Martin Drab
@ 2006-01-08 13:21 ` Olivier Galibert
2006-01-08 13:32 ` Jaroslav Kysela
0 siblings, 1 reply; 84+ messages in thread
From: Olivier Galibert @ 2006-01-08 13:21 UTC (permalink / raw)
To: Martin Drab; +Cc: Takashi Iwai, ALSA development, linux-sound, LKML
On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote:
> On Sun, 8 Jan 2006, Olivier Galibert wrote:
>
> > > 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.
>
> I think that the point was, that switching from userspace to kernelspace
> then to userspace again and back to kernelspace in order to do something,
> that could have been done directly in the userspace, and though could save
> those two unnecessary switches, is an unnecessary overhead, which may not
> necessarily be that insignificant if it's done so often (which for
> streaming audio is the case).
You all seem to forget that dmix is in userspace in a different task
too.
> Why doing things complicated when there is no evident gain from it,
> or is there?
No evident gain? Wow. What about:
- stopping crippling the OSS api
- having a real kernel api for which you can make different libraries
depending on the need of the users
- stop making a fundamentally unsecure shared library mandatory
- opening the possibility of writing plugins to people without a PhD
in lattice QCD.
and that's just a start.
OG.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 13:21 ` Olivier Galibert
@ 2006-01-08 13:32 ` Jaroslav Kysela
2006-01-08 23:18 ` Pavel Machek
0 siblings, 1 reply; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-08 13:32 UTC (permalink / raw)
To: Olivier Galibert
Cc: Martin Drab, Takashi Iwai, ALSA development, linux-sound, LKML
On Sun, 8 Jan 2006, Olivier Galibert wrote:
> On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote:
> > On Sun, 8 Jan 2006, Olivier Galibert wrote:
> >
> > > > 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.
> >
> > I think that the point was, that switching from userspace to kernelspace
> > then to userspace again and back to kernelspace in order to do something,
> > that could have been done directly in the userspace, and though could save
> > those two unnecessary switches, is an unnecessary overhead, which may not
> > necessarily be that insignificant if it's done so often (which for
> > streaming audio is the case).
>
> You all seem to forget that dmix is in userspace in a different task
> too.
Because it is really not. The mixing is done directly to the mmaped DMA
buffer.
> > Why doing things complicated when there is no evident gain from it,
> > or is there?
>
> No evident gain? Wow. What about:
> - stopping crippling the OSS api
We're not doing that. We're just showing that OSS API and useability has
it's own problems, too.
> - having a real kernel api for which you can make different libraries
> depending on the need of the users
>
> - stop making a fundamentally unsecure shared library mandatory
ALSA kernel API is real and binary compatible. If someone require to
write an own library, we will document this API, of course, too.
> - opening the possibility of writing plugins to people without a PhD
> in lattice QCD.
Already done. We have official plugin SDK in alsa-lib to create user space
drivers. If you have some questions or bug-reports (missing docs etc),
please, fill a bug report.
Also, you can use very simple LADSPA plugin style, because alsa-lib can
use LADSPA plugins directly, too.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 13:32 ` Jaroslav Kysela
@ 2006-01-08 23:18 ` Pavel Machek
0 siblings, 0 replies; 84+ messages in thread
From: Pavel Machek @ 2006-01-08 23:18 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Olivier Galibert, Martin Drab, Takashi Iwai, ALSA development,
linux-sound, LKML
On Ne 08-01-06 14:32:40, Jaroslav Kysela wrote:
> ALSA kernel API is real and binary compatible. If someone require to
> write an own library, we will document this API, of course, too.
The documentation would be nice, regardless of other libraries. It is
kernel API and that really should be documented.
Pavel
--
Thanks, Sharp!
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 2:03 ` Olivier Galibert
2006-01-08 2:26 ` Martin Drab
@ 2006-01-08 9:42 ` Jaroslav Kysela
2006-01-08 13:04 ` Olivier Galibert
2006-01-08 13:38 ` Marcin Dalecki
1 sibling, 2 replies; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-08 9:42 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Takashi Iwai, ALSA development, linux-sound, LKML
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.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 9:42 ` Jaroslav Kysela
@ 2006-01-08 13:04 ` Olivier Galibert
2006-01-08 13:23 ` Jaroslav Kysela
2006-01-08 13:38 ` Marcin Dalecki
1 sibling, 1 reply; 84+ messages in thread
From: Olivier Galibert @ 2006-01-08 13:04 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Takashi Iwai, ALSA development, linux-sound, LKML
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.
OG.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 13:04 ` Olivier Galibert
@ 2006-01-08 13:23 ` Jaroslav Kysela
0 siblings, 0 replies; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-08 13:23 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Takashi Iwai, ALSA development, linux-sound, LKML
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@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-08 9:42 ` Jaroslav Kysela
2006-01-08 13:04 ` Olivier Galibert
@ 2006-01-08 13:38 ` Marcin Dalecki
1 sibling, 0 replies; 84+ messages in thread
From: Marcin Dalecki @ 2006-01-08 13:38 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Olivier Galibert, Takashi Iwai, ALSA development, linux-sound, LKML
On 2006-01-08, at 10:42, Jaroslav Kysela wrote:
>>
>> 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.
1. It was only presented as an opportunity. Not every data has to go
this way.
2. Aren't you the person which was showing off X11 as a good example
to draw guidelines from?
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 16:14 ` Takashi Iwai
2006-01-05 17:19 ` Marcin Dalecki
2006-01-05 20:13 ` Tomasz Kłoczko
@ 2006-01-05 23:06 ` Hannu Savolainen
2006-01-05 23:39 ` Lee Revell
` (4 more replies)
2 siblings, 5 replies; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-05 23:06 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-sound, LKML
On Thu, 5 Jan 2006, Takashi Iwai wrote:
> > If you have sound device without this soft mixing is moved to user space
> > .. but applications do not need know about this even now because all
> > neccessary details are handled on library level. Is it ?
> > So question is: why the hell *ALL* mixing details are not moved to kernel
> > space to SIMPLE and NOT GROWING abstraction ?
>
> Because many people believe that the softmix in the kernel space is
> evil.
This is the usual argument against kernel level mixing. Somebody has once
said that all this is evil. However this is not necessarily correct.
OSS has done kernel level mixing for years. The vmix driver has been used
as the default audio device by hundreds of thousands of customers for
years. We have not received any single bug report that is caused
by the concept of kernel mixing.
Kernel mixing is not rocket science. All you need to do is picking a
sample from the output buffers of each of the applications, sum them
together (with some volume scaling) and feed the result to the physical
device. Ok, handling different sample formats/rates makes it much more
difficult but that could be done in the library level.
> > Why Linux can't provide only OSS API abstraction for user space
> > application ? And/or why ALSA developers want to replace this by
> > mostly bloated and pourly documented ALSA user space API ?
>
> Because OSS API doesn't cover many things. For example,
>
> - PCM with non-interleaved formats
There is no need to handle non-interleaved data in kernel level drivers
because all the devices use interleaved formats. Handling
interleaving/de-interleaving in the application/driver code can be done in
a simple for loop. So why to make the driver/API more complicated with
this.
> - PCM with 3-bytes-packed 24bit formats
Applications have no reasons to use for this kind of stupid format so OSS
translates it to the usual 32 bit format on fly. In fact OSS API does
have support for this format.
> These functions are popluar on many sound devices.
>
> In addition, imagine how you would implement the following:
>
> - Combination of multiple devices
> - Split of channels to concurrent accesses
Could you be more specific with the above isues?
> - Handling of floating pointer samples
This is not necessary in the kernel drivers because user land apps/libs do
this themselves. However OSS API defines a floating point data type just
in case some future device needs it.
> - Post/pre-effects (like chorus/reverb)
OSS already does this (part of the softoss/vmix driver).
> Forcing OSS API means to force to process the all things above in
> the kernel. I guess many people would disagree with it.
Wrong. This is not an API issue at all. It's an implementation one.
An alternative for doing some operations in the kernel is looping the
audio data through an user land daemon. The application itself is still
using the usual OSS API without knowing anything about any daemons. We
have tested this approach and it works. There just has not been any good
reason to use this approach instead of using kernel space approach.
Passing data through multiple applications makes the latency issues to
accumulate. If you do the processing in the kernel you will hit by the
task scheduling latencies at most once.
The OSS approach is not to make everything in the kernel. Things that can
be done easier in the applications (or in libraries) have been left
out from the API.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:06 ` Hannu Savolainen
@ 2006-01-05 23:39 ` Lee Revell
2006-01-05 23:56 ` Hannu Savolainen
2006-01-05 23:40 ` Lee Revell
` (3 subsequent siblings)
4 siblings, 1 reply; 84+ messages in thread
From: Lee Revell @ 2006-01-05 23:39 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Takashi Iwai, linux-sound, LKML
On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > - PCM with 3-bytes-packed 24bit formats
> Applications have no reasons to use for this kind of stupid format so
> OSS translates it to the usual 32 bit format on fly. In fact OSS API
> does have support for this format.
What about hardware that only understands this format?
Lee
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:39 ` Lee Revell
@ 2006-01-05 23:56 ` Hannu Savolainen
2006-01-06 0:03 ` Lee Revell
0 siblings, 1 reply; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-05 23:56 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, linux-sound, LKML
On Thu, 5 Jan 2006, Lee Revell wrote:
> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > > - PCM with 3-bytes-packed 24bit formats
> > Applications have no reasons to use for this kind of stupid format so
> > OSS translates it to the usual 32 bit format on fly. In fact OSS API
> > does have support for this format.
>
> What about hardware that only understands this format?
There is no such hardware. Or is there?
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:56 ` Hannu Savolainen
@ 2006-01-06 0:03 ` Lee Revell
0 siblings, 0 replies; 84+ messages in thread
From: Lee Revell @ 2006-01-06 0:03 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Takashi Iwai, linux-sound, LKML
On Fri, 2006-01-06 at 01:56 +0200, Hannu Savolainen wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
>
> > On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > > > - PCM with 3-bytes-packed 24bit formats
> > > Applications have no reasons to use for this kind of stupid format so
> > > OSS translates it to the usual 32 bit format on fly. In fact OSS API
> > > does have support for this format.
> >
> > What about hardware that only understands this format?
> There is no such hardware. Or is there?
>
Yep, the Roland SC-D70 and EDIROL UA-5 in "advanced mode", I guess it
lets them cram more channels of 24 bit audio over a slow USB pipe. It's
no fun...
Lee
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:06 ` Hannu Savolainen
2006-01-05 23:39 ` Lee Revell
@ 2006-01-05 23:40 ` Lee Revell
2006-01-05 23:59 ` Hannu Savolainen
2006-01-06 0:14 ` Marcin Dalecki
2006-01-06 3:14 ` Edgar Toernig
` (2 subsequent siblings)
4 siblings, 2 replies; 84+ messages in thread
From: Lee Revell @ 2006-01-05 23:40 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Takashi Iwai, linux-sound, LKML
On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> We have not received any single bug report that is caused
> by the concept of kernel mixing.
> Kernel mixing is not rocket science. All you need to do is picking a
> sample from the output buffers of each of the applications, sum them
> together (with some volume scaling) and feed the result to the
> physical
> device.
Hey, interesting, this is exactly what dmix does in userspace. And we
have not seen any bug reports caused by the concept of userspace mixing
(just implementation bugs like any piece of software).
Lee
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:40 ` Lee Revell
@ 2006-01-05 23:59 ` Hannu Savolainen
2006-01-06 15:03 ` Stefan Smietanowski
2006-01-10 9:43 ` Jaroslav Kysela
2006-01-06 0:14 ` Marcin Dalecki
1 sibling, 2 replies; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-05 23:59 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, linux-sound, LKML
On Thu, 5 Jan 2006, Lee Revell wrote:
> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > We have not received any single bug report that is caused
> > by the concept of kernel mixing.
> > Kernel mixing is not rocket science. All you need to do is picking a
> > sample from the output buffers of each of the applications, sum them
> > together (with some volume scaling) and feed the result to the
> > physical
> > device.
>
> Hey, interesting, this is exactly what dmix does in userspace. And we
> have not seen any bug reports caused by the concept of userspace mixing
> (just implementation bugs like any piece of software).
Having dmix working in user space doesn't prove that kernel level mixing
is evil. This was the original topic.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:59 ` Hannu Savolainen
@ 2006-01-06 15:03 ` Stefan Smietanowski
2006-01-06 15:48 ` Erik Mouw
2006-01-06 18:37 ` Lee Revell
2006-01-10 9:43 ` Jaroslav Kysela
1 sibling, 2 replies; 84+ messages in thread
From: Stefan Smietanowski @ 2006-01-06 15:03 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Lee Revell, Takashi Iwai, linux-sound, LKML
[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]
Hannu Savolainen wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
>
>
>>On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
>>
>>>We have not received any single bug report that is caused
>>>by the concept of kernel mixing.
>>>Kernel mixing is not rocket science. All you need to do is picking a
>>>sample from the output buffers of each of the applications, sum them
>>>together (with some volume scaling) and feed the result to the
>>>physical
>>>device.
>>
>>Hey, interesting, this is exactly what dmix does in userspace. And we
>>have not seen any bug reports caused by the concept of userspace mixing
>>(just implementation bugs like any piece of software).
>
> Having dmix working in user space doesn't prove that kernel level mixing
> is evil. This was the original topic.
Wasn't there a thread a few years ago (3-5?) about sound mixing in the
kernel?
I've tried searching for it but have been unsuccessful so I could be
remembering wrong.
I can't remember if it was about OSS, ALSA or anything else but I
believe the conclusion was that sound mixing does NOT belong in the
kernel and SHOULD be done in userspace. I have a faint memory of that
being written by Alan Cox, but since it was a while ago I could very
well be mistaken there (too?).
// Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 15:03 ` Stefan Smietanowski
@ 2006-01-06 15:48 ` Erik Mouw
2006-01-06 18:37 ` Lee Revell
1 sibling, 0 replies; 84+ messages in thread
From: Erik Mouw @ 2006-01-06 15:48 UTC (permalink / raw)
To: Stefan Smietanowski
Cc: Hannu Savolainen, Lee Revell, Takashi Iwai, linux-sound, LKML, alan
On Fri, Jan 06, 2006 at 04:03:26PM +0100, Stefan Smietanowski wrote:
> Hannu Savolainen wrote:
> > Having dmix working in user space doesn't prove that kernel level mixing
> > is evil. This was the original topic.
>
> Wasn't there a thread a few years ago (3-5?) about sound mixing in the
> kernel?
>
> I've tried searching for it but have been unsuccessful so I could be
> remembering wrong.
"The kernel is an arbitrator of resources it is not a shit bucket for
solving other peoples incompetence." -- Alan Cox
Here's the post:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.3/0324.html
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 15:03 ` Stefan Smietanowski
2006-01-06 15:48 ` Erik Mouw
@ 2006-01-06 18:37 ` Lee Revell
1 sibling, 0 replies; 84+ messages in thread
From: Lee Revell @ 2006-01-06 18:37 UTC (permalink / raw)
To: Stefan Smietanowski; +Cc: Hannu Savolainen, Takashi Iwai, linux-sound, LKML
On Fri, 2006-01-06 at 16:03 +0100, Stefan Smietanowski wrote:
> I can't remember if it was about OSS, ALSA or anything else but I
> believe the conclusion was that sound mixing does NOT belong in the
> kernel and SHOULD be done in userspace.
Well, sound mixing really belongs in hardware, but that seems to be a
lost cause - vendors are way too cheap these days.
I can't believe they managed to hoodwink Windows gamers into accepting a
new generation of sound devices that make the CPU do the work the
hardware used to do...
Lee
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:59 ` Hannu Savolainen
2006-01-06 15:03 ` Stefan Smietanowski
@ 2006-01-10 9:43 ` Jaroslav Kysela
2006-01-10 13:42 ` Hannu Savolainen
1 sibling, 1 reply; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-10 9:43 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Lee Revell, Takashi Iwai, linux-sound, LKML
On Fri, 6 Jan 2006, Hannu Savolainen wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
>
> > On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > > We have not received any single bug report that is caused
> > > by the concept of kernel mixing.
> > > Kernel mixing is not rocket science. All you need to do is picking a
> > > sample from the output buffers of each of the applications, sum them
> > > together (with some volume scaling) and feed the result to the
> > > physical
> > > device.
> >
> > Hey, interesting, this is exactly what dmix does in userspace. And we
> > have not seen any bug reports caused by the concept of userspace mixing
> > (just implementation bugs like any piece of software).
> Having dmix working in user space doesn't prove that kernel level mixing
> is evil. This was the original topic.
Overloading interrupt handlers with extra things is evil (and I bet you're
mixing samples in the interrupt handler). Even the network stack uses
interrupts only for DMA management and not for any extra operations.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-10 9:43 ` Jaroslav Kysela
@ 2006-01-10 13:42 ` Hannu Savolainen
2006-01-10 14:08 ` Jaroslav Kysela
0 siblings, 1 reply; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-10 13:42 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Lee Revell, Takashi Iwai, linux-sound, LKML
On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
> Overloading interrupt handlers with extra things is evil (and I bet you're
> mixing samples in the interrupt handler). Even the network stack uses
> interrupts only for DMA management and not for any extra operations.
You mean it's evil because nobody else is doing it? Then it must be
evil or rather voodoo.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-10 13:42 ` Hannu Savolainen
@ 2006-01-10 14:08 ` Jaroslav Kysela
2006-01-10 14:17 ` Hannu Savolainen
2006-01-10 20:13 ` Marcin Dalecki
0 siblings, 2 replies; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-10 14:08 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Lee Revell, Takashi Iwai, linux-sound, LKML
On Tue, 10 Jan 2006, Hannu Savolainen wrote:
> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
>
> > Overloading interrupt handlers with extra things is evil (and I bet you're
> > mixing samples in the interrupt handler). Even the network stack uses
> > interrupts only for DMA management and not for any extra operations.
> You mean it's evil because nobody else is doing it? Then it must be
> evil or rather voodoo.
No, I mean that it's quite obvious bad design, because you might increase
interrupt latencies for other drivers.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-10 14:08 ` Jaroslav Kysela
@ 2006-01-10 14:17 ` Hannu Savolainen
2006-01-10 20:13 ` Marcin Dalecki
1 sibling, 0 replies; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-10 14:17 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Lee Revell, Takashi Iwai, linux-sound, LKML
On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
> No, I mean that it's quite obvious bad design, because you might increase
> interrupt latencies for other drivers.
Maybe if running with all interrupts disabled.
The "mixing" time for one interrupt has been measured and it was smaller
than the resolution of the measurement method (1 usec). It is indeed a
serious risk to the system.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-10 14:08 ` Jaroslav Kysela
2006-01-10 14:17 ` Hannu Savolainen
@ 2006-01-10 20:13 ` Marcin Dalecki
1 sibling, 0 replies; 84+ messages in thread
From: Marcin Dalecki @ 2006-01-10 20:13 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Hannu Savolainen, Lee Revell, Takashi Iwai, linux-sound, LKML
On 2006-01-10, at 15:08, Jaroslav Kysela wrote:
> On Tue, 10 Jan 2006, Hannu Savolainen wrote:
>
>> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
>>
>>> Overloading interrupt handlers with extra things is evil (and I
>>> bet you're
>>> mixing samples in the interrupt handler). Even the network stack
>>> uses
>>> interrupts only for DMA management and not for any extra operations.
>> You mean it's evil because nobody else is doing it? Then it must be
>> evil or rather voodoo.
>
> No, I mean that it's quite obvious bad design, because you might
> increase
> interrupt latencies for other drivers.
"Becasue you might" is a bad argument. Either you do or you don't. My
guess is that you don't
becase the amount of data to be handled is absymally small. (Come one
48kBaud is not much...)
And BTW. good luck trying to convince the /dev/random gang that it
isn't good for performance
what they are doing on the IRQ path...
Marcin Dalecki
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:40 ` Lee Revell
2006-01-05 23:59 ` Hannu Savolainen
@ 2006-01-06 0:14 ` Marcin Dalecki
2006-01-06 0:29 ` Martin Drab
2006-01-06 1:21 ` Zan Lynx
1 sibling, 2 replies; 84+ messages in thread
From: Marcin Dalecki @ 2006-01-06 0:14 UTC (permalink / raw)
To: Lee Revell; +Cc: Hannu Savolainen, Takashi Iwai, linux-sound, LKML
On 2006-01-06, at 00:40, Lee Revell wrote:
> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
>> We have not received any single bug report that is caused
>> by the concept of kernel mixing.
>> Kernel mixing is not rocket science. All you need to do is picking a
>> sample from the output buffers of each of the applications, sum them
>> together (with some volume scaling) and feed the result to the
>> physical
>> device.
>
> Hey, interesting, this is exactly what dmix does in userspace. And we
> have not seen any bug reports caused by the concept of userspace
> mixing
> (just implementation bugs like any piece of software).
This attitude that every kind of software has to have bugs is
blunt idiotic tale-tale bullshit just showing off complete incompetence.
Does the acronym car-ABS and micro-controller maybe perhaps ring a
bell for you?
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 0:14 ` Marcin Dalecki
@ 2006-01-06 0:29 ` Martin Drab
2006-01-06 0:57 ` Marcin Dalecki
2006-01-06 1:21 ` Zan Lynx
1 sibling, 1 reply; 84+ messages in thread
From: Martin Drab @ 2006-01-06 0:29 UTC (permalink / raw)
To: Marcin Dalecki
Cc: Lee Revell, Hannu Savolainen, Takashi Iwai, linux-sound, LKML
On Fri, 6 Jan 2006, Marcin Dalecki wrote:
> On 2006-01-06, at 00:40, Lee Revell wrote:
...
> > (just implementation bugs like any piece of software).
>
> This attitude that every kind of software has to have bugs is
> blunt idiotic tale-tale bullshit just showing off complete incompetence.
Now you're dreaming, right? Because as much as we all don't like it, it is
a realistic fact. There's just NO WAY you can responsibly say about any
piece software, that it is completely error free. I think there's lots of
people (especially) on this list, that may confirm that.
Martin
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 0:29 ` Martin Drab
@ 2006-01-06 0:57 ` Marcin Dalecki
2006-01-06 1:49 ` Martin Drab
0 siblings, 1 reply; 84+ messages in thread
From: Marcin Dalecki @ 2006-01-06 0:57 UTC (permalink / raw)
To: Martin Drab; +Cc: Lee Revell, Hannu Savolainen, Takashi Iwai, linux-sound, LKML
On 2006-01-06, at 01:29, Martin Drab wrote:
> Because as much as we all don't like it, it is
> a realistic fact. There's just NO WAY you can responsibly say about
> any
> piece software, that it is completely error free.
You would be for example surprised to see how complex the software
controlling the breaks
of a reasonable modern car turns out to be... This is just a
technical example running contrary
to your "wisdom". In numerical computations you can find reasonable
amounts of software
which is precisely just that - bug free. There are mathematical
proofs running for hundreds of pages,
which are just valid. Do you think this kind of guys doesn't ever sit
down and write
some piece of software to help out well for example in determining
some aerodynamics of a plane?
Are you assuming this kind of applications is trivial and by virtue
of a natural law bug ridden?
And by the way: the zero program which has nothing to do is bug free.
QED.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 0:57 ` Marcin Dalecki
@ 2006-01-06 1:49 ` Martin Drab
0 siblings, 0 replies; 84+ messages in thread
From: Martin Drab @ 2006-01-06 1:49 UTC (permalink / raw)
To: Marcin Dalecki
Cc: Lee Revell, Hannu Savolainen, Takashi Iwai, linux-sound, LKML
On Fri, 6 Jan 2006, Marcin Dalecki wrote:
> On 2006-01-06, at 01:29, Martin Drab wrote:
>
> > Because as much as we all don't like it, it is
> > a realistic fact. There's just NO WAY you can responsibly say about any
> > piece software, that it is completely error free.
>
> You would be for example surprised to see how complex the software controlling
> the breaks
> of a reasonable modern car turns out to be... This is just a technical example
No doubts it is.
> running contrary
> to your "wisdom". In numerical computations you can find reasonable amounts of
> software
> which is precisely just that - bug free. There are mathematical proofs running
> for hundreds of pages,
> which are just valid.
Yes, I know. That, however, still doesn't necesarilly mean that it has to
be completely error free. (An error must not necessarily mean a complete
screw-up.)
> Do you think this kind of guys doesn't ever sit down and
> write
> some piece of software to help out well for example in determining some
> aerodynamics of a plane?
I know they do. Again, it doesn't mean that that software has to be
completely error free.
> Are you assuming this kind of applications is trivial and by virtue of a
> natural law bug ridden?
Well, I'm moving in an environment of nuclear energy, physics, and
mathematical modelling a bit for quite some while. And I know, that you
can never be absolutely certain that any (reasonably complex) software is
completely error free.
Apart from that, that in those really critical cases (such as a primary
controlling system of a nuclear reactor), you are actually forced to just
a strict subset of a strictly defined programming languages, it is just
that, that forces you to have tons of various sophisticated checking and
safety mechanisms implemented in the software to prevent any possible bugs
to do any serious harm, which in this case can no doubt be very terminal.
Overconfidence in these cases is not in place, even though these really
are the ones that are really thotoughly checked for bugs.
> And by the way: the zero program which has nothing to do is bug free. QED.
Ah, OK, you got me on that one. :) But that's not quite what I had in
mind.
Anyway, I guess we're quite by far OT with this. So I think we should just
leave it at that, and let everybody draw their own conclusions to their
own best knowledge. Sorry for bothering with this.
Martin
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 0:14 ` Marcin Dalecki
2006-01-06 0:29 ` Martin Drab
@ 2006-01-06 1:21 ` Zan Lynx
2006-01-06 15:17 ` Stefan Smietanowski
1 sibling, 1 reply; 84+ messages in thread
From: Zan Lynx @ 2006-01-06 1:21 UTC (permalink / raw)
To: Marcin Dalecki
Cc: Lee Revell, Hannu Savolainen, Takashi Iwai, linux-sound, LKML
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
On Fri, 2006-01-06 at 01:14 +0100, Marcin Dalecki wrote:
> On 2006-01-06, at 00:40, Lee Revell wrote:
> > Hey, interesting, this is exactly what dmix does in userspace. And we
> > have not seen any bug reports caused by the concept of userspace
> > mixing
> > (just implementation bugs like any piece of software).
>
> This attitude that every kind of software has to have bugs is
> blunt idiotic tale-tale bullshit just showing off complete incompetence.
>
> Does the acronym car-ABS and micro-controller maybe perhaps ring a
> bell for you?
Funny that you should mention bug-free code and ABS.
Just a few months ago, Subaru updated the ABS controller code for the
WRX. They sent me the notice in the mail. It was an optional upgrade,
the change was only needed to fix some very odd corner cases.
The point being that even critical micro-controller software has bugs.
Even software that has been mathematically proofed can have bugs. Knuth
uses it as a joke: "Beware bugs in the above code. I have
proven it correct; I have not actually tried it."
It's so funny because it's so true.
--
Zan Lynx <zlynx@acm.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 1:21 ` Zan Lynx
@ 2006-01-06 15:17 ` Stefan Smietanowski
2006-01-09 23:55 ` jerome lacoste
0 siblings, 1 reply; 84+ messages in thread
From: Stefan Smietanowski @ 2006-01-06 15:17 UTC (permalink / raw)
To: Zan Lynx
Cc: Marcin Dalecki, Lee Revell, Hannu Savolainen, Takashi Iwai,
linux-sound, LKML
[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]
Zan Lynx wrote:
> On Fri, 2006-01-06 at 01:14 +0100, Marcin Dalecki wrote:
>
>>On 2006-01-06, at 00:40, Lee Revell wrote:
>>
>>>Hey, interesting, this is exactly what dmix does in userspace. And we
>>>have not seen any bug reports caused by the concept of userspace
>>>mixing
>>>(just implementation bugs like any piece of software).
>>
>>This attitude that every kind of software has to have bugs is
>>blunt idiotic tale-tale bullshit just showing off complete incompetence.
>>
>>Does the acronym car-ABS and micro-controller maybe perhaps ring a
>>bell for you?
>
>
> Funny that you should mention bug-free code and ABS.
>
> Just a few months ago, Subaru updated the ABS controller code for the
> WRX. They sent me the notice in the mail. It was an optional upgrade,
> the change was only needed to fix some very odd corner cases.
>
> The point being that even critical micro-controller software has bugs.
>
> Even software that has been mathematically proofed can have bugs. Knuth
> uses it as a joke: "Beware bugs in the above code. I have
> proven it correct; I have not actually tried it."
>
> It's so funny because it's so true.
Same as when Renault introduced the keyless system in the Laguna in 2001
(some call it the Laguna II) - it's basically a card you stick into a
slot in the console which enables you to just press a button to start
the car instead of turning a key and it also contained memory about
your chair settings, mirrors and volume/sound settings of the radio.
Now, is this a highly complex piece of software running there to do
those things?
Regardless of how what someone believes - a few months later someone
was out driving and all of a sudden the car started speeding up and
since there was no key you couldn't turn the car off and the breaks
weren't strong enough to slow the car down and running at roughly
200kph he managed to YANK the card out of the slot before it could be
slowed down and the ignition turned off - the guy was lucky to be
alive.
It turns out that it was a combination of a bug in the keyless
system AND the cruise control that made this happen - two bugs
that in themselves wouldn't have triggered but at the right speed,
and when everything matched things went haywire, so no, no matter
how tight you write specifications or papers you can't get
everything bugfree, even in such a simple system as a keycard
for your car. Note that one of the bugs WAS in the keycard.
// Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 15:17 ` Stefan Smietanowski
@ 2006-01-09 23:55 ` jerome lacoste
2006-01-10 2:29 ` Stefan Smietanowski
0 siblings, 1 reply; 84+ messages in thread
From: jerome lacoste @ 2006-01-09 23:55 UTC (permalink / raw)
To: Stefan Smietanowski; +Cc: LKML
On 1/6/06, Stefan Smietanowski <stesmi@stesmi.com> wrote:
[...]
> Same as when Renault introduced the keyless system in the Laguna in 2001
> (some call it the Laguna II) - it's basically a card you stick into a
> slot in the console which enables you to just press a button to start
> the car instead of turning a key and it also contained memory about
> your chair settings, mirrors and volume/sound settings of the radio.
>
> Now, is this a highly complex piece of software running there to do
> those things?
>
> Regardless of how what someone believes - a few months later someone
> was out driving and all of a sudden the car started speeding up and
> since there was no key you couldn't turn the car off and the breaks
> weren't strong enough to slow the car down and running at roughly
> 200kph he managed to YANK the card out of the slot before it could be
> slowed down and the ignition turned off - the guy was lucky to be
> alive.
I think you are mixing 2 stories. According to my sources, the driver
of a Renault Vel Satis reported a similar issue and got stuck at
around 190kmph during an hour in October 2004. In March 2005, the
driver of a Laguna reported that he got stuck at 90 kmph for 40km.
> It turns out that it was a combination of a bug in the keyless
> system AND the cruise control that made this happen - two bugs
> that in themselves wouldn't have triggered but at the right speed,
> and when everything matched things went haywire, so no, no matter
> how tight you write specifications or papers you can't get
> everything bugfree, even in such a simple system as a keycard
> for your car. Note that one of the bugs WAS in the keycard.
To my knowledge, none of the reported issues have yet been identified
as coming from the car. I searched again before posting and found no
reference to that issue.
I would be happy to know where you found this information. At least to
know if the constructors are hidding something.
Cheers,
> // Stefan
Jerome
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-09 23:55 ` jerome lacoste
@ 2006-01-10 2:29 ` Stefan Smietanowski
0 siblings, 0 replies; 84+ messages in thread
From: Stefan Smietanowski @ 2006-01-10 2:29 UTC (permalink / raw)
To: jerome lacoste; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]
Hi.
>>Same as when Renault introduced the keyless system in the Laguna in 2001
>>(some call it the Laguna II) - it's basically a card you stick into a
>>slot in the console which enables you to just press a button to start
>>the car instead of turning a key and it also contained memory about
>>your chair settings, mirrors and volume/sound settings of the radio.
>>
>>Now, is this a highly complex piece of software running there to do
>>those things?
>>
>>Regardless of how what someone believes - a few months later someone
>>was out driving and all of a sudden the car started speeding up and
>>since there was no key you couldn't turn the car off and the breaks
>>weren't strong enough to slow the car down and running at roughly
>>200kph he managed to YANK the card out of the slot before it could be
>>slowed down and the ignition turned off - the guy was lucky to be
>>alive.
>
>
> I think you are mixing 2 stories. According to my sources, the driver
> of a Renault Vel Satis reported a similar issue and got stuck at
> around 190kmph during an hour in October 2004. In March 2005, the
> driver of a Laguna reported that he got stuck at 90 kmph for 40km.
Hm.
>>It turns out that it was a combination of a bug in the keyless
>>system AND the cruise control that made this happen - two bugs
>>that in themselves wouldn't have triggered but at the right speed,
>>and when everything matched things went haywire, so no, no matter
>>how tight you write specifications or papers you can't get
>>everything bugfree, even in such a simple system as a keycard
>>for your car. Note that one of the bugs WAS in the keycard.
>
>
> To my knowledge, none of the reported issues have yet been identified
> as coming from the car. I searched again before posting and found no
> reference to that issue.
>
> I would be happy to know where you found this information. At least to
> know if the constructors are hidding something.
Timeframe of the Laguna incident is roughly correct to my memory. It
was reported in the Swedish newspapers. I'll try searching for it
and see what I come up with, even though it's totally OT.
// Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:06 ` Hannu Savolainen
2006-01-05 23:39 ` Lee Revell
2006-01-05 23:40 ` Lee Revell
@ 2006-01-06 3:14 ` Edgar Toernig
2006-01-06 3:33 ` Hannu Savolainen
2006-01-06 7:47 ` Jan Engelhardt
2006-01-07 14:45 ` Takashi Iwai
4 siblings, 1 reply; 84+ messages in thread
From: Edgar Toernig @ 2006-01-06 3:14 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Takashi Iwai, linux-sound, LKML
Hannu Savolainen wrote:
>
> Takashi Iwai wrote:
> >
> > - Split of channels to concurrent accesses
>
> Could you be more specific with the above isues?
As I understand it: instead of providing one device with 5.1 capabilities
provide one device with 3 concurrent stereo users. Reading the datasheet
of my AC'97 decoder (a cheap ALC650 connected to an ATIIXP) there is hard-
ware that supports this[1].
Sure, Alsa can do all of this and more in software - somehow ...
Ciao, ET.
[1] Unless the ATIIXP has some limitations - there are no docs
available :-(
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 3:14 ` Edgar Toernig
@ 2006-01-06 3:33 ` Hannu Savolainen
2006-01-06 11:34 ` Florian Schmidt
0 siblings, 1 reply; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-06 3:33 UTC (permalink / raw)
To: Edgar Toernig; +Cc: Takashi Iwai, linux-sound, LKML
On Fri, 6 Jan 2006, Edgar Toernig wrote:
> Hannu Savolainen wrote:
> >
> > Takashi Iwai wrote:
> > >
> > > - Split of channels to concurrent accesses
> >
> > Could you be more specific with the above isues?
>
> As I understand it: instead of providing one device with 5.1 capabilities
> provide one device with 3 concurrent stereo users. Reading the datasheet
> of my AC'97 decoder (a cheap ALC650 connected to an ATIIXP) there is hard-
> ware that supports this[1].
Then this is in no way an API issue. Many OSS drivers (including envy24)
create separete device files for each input/output channel (or device pair).
Applications can chose to open the first device file in for all the
channels or any combination of the devices in mono/stereo/n-channel mode.
All this depends only on the driver implementation. There is nothing API
related. Any app can open the devices as usual without paying any
attention on the channel allocation (which is done automatically by the
driver). xmms (or whatever else consumer app) can open the device and ask
for stereo access. Equally well a DAB application can open the device and
ask for full 10 output channels (or anything between 1 and 10). No special
API features are needed for this.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 3:33 ` Hannu Savolainen
@ 2006-01-06 11:34 ` Florian Schmidt
0 siblings, 0 replies; 84+ messages in thread
From: Florian Schmidt @ 2006-01-06 11:34 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Edgar Toernig, Takashi Iwai, linux-sound, LKML
On Fri, 6 Jan 2006 05:33:43 +0200 (EET)
Hannu Savolainen <hannu@opensound.com> wrote:
> Then this is in no way an API issue. Many OSS drivers (including envy24)
> create separete device files for each input/output channel (or device pair).
> Applications can chose to open the first device file in for all the
> channels or any combination of the devices in mono/stereo/n-channel mode.
>
> All this depends only on the driver implementation. There is nothing API
> related. Any app can open the devices as usual without paying any
> attention on the channel allocation (which is done automatically by the
> driver). xmms (or whatever else consumer app) can open the device and ask
> for stereo access. Equally well a DAB application can open the device and
> ask for full 10 output channels (or anything between 1 and 10). No special
> API features are needed for this.
Hi,
i would find it helpful if you always made it crystal clear about what
version of OSS you are talking about:
- your proprietary version
- or the free one in the kernel
Mixing these isn't helping the discussion.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:06 ` Hannu Savolainen
` (2 preceding siblings ...)
2006-01-06 3:14 ` Edgar Toernig
@ 2006-01-06 7:47 ` Jan Engelhardt
2006-01-07 14:45 ` Takashi Iwai
4 siblings, 0 replies; 84+ messages in thread
From: Jan Engelhardt @ 2006-01-06 7:47 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: Takashi Iwai, linux-sound, LKML
>> > If you have sound device without this soft mixing is moved to user space
>> > .. but applications do not need know about this even now because all
>> > neccessary details are handled on library level. Is it ?
>> > So question is: why the hell *ALL* mixing details are not moved to kernel
>> > space to SIMPLE and NOT GROWING abstraction ?
>>
>> Because many people believe that the softmix in the kernel space is
>> evil.
>>
>This is the usual argument against kernel level mixing. Somebody has once
>said that all this is evil. However this is not necessarily correct.
>
I'm going with "is evil". Better let userspace have a segfault than a kernel
oops. I am having quite a moody feeling when running even my own things like
http://alphagate.hopto.org/quad_dsp/
>Kernel mixing is not rocket science. All you need to do is picking a
>sample from the output buffers of each of the applications, sum them
>together (with some volume scaling) and feed the result to the physical
>device. Ok, handling different sample formats/rates makes it much more
>difficult but that could be done in the library level.
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:06 ` Hannu Savolainen
` (3 preceding siblings ...)
2006-01-06 7:47 ` Jan Engelhardt
@ 2006-01-07 14:45 ` Takashi Iwai
4 siblings, 0 replies; 84+ messages in thread
From: Takashi Iwai @ 2006-01-07 14:45 UTC (permalink / raw)
To: Hannu Savolainen; +Cc: linux-sound, LKML
At Fri, 6 Jan 2006 01:06:27 +0200 (EET),
Hannu Savolainen wrote:
>
> On Thu, 5 Jan 2006, Takashi Iwai wrote:
>
> > > If you have sound device without this soft mixing is moved to user space
> > > .. but applications do not need know about this even now because all
> > > neccessary details are handled on library level. Is it ?
> > > So question is: why the hell *ALL* mixing details are not moved to kernel
> > > space to SIMPLE and NOT GROWING abstraction ?
> >
> > Because many people believe that the softmix in the kernel space is
> > evil.
> This is the usual argument against kernel level mixing. Somebody has once
> said that all this is evil. However this is not necessarily correct.
>
> OSS has done kernel level mixing for years. The vmix driver has been used
> as the default audio device by hundreds of thousands of customers for
> years. We have not received any single bug report that is caused
> by the concept of kernel mixing.
>
> Kernel mixing is not rocket science. All you need to do is picking a
> sample from the output buffers of each of the applications, sum them
> together (with some volume scaling) and feed the result to the physical
> device. Ok, handling different sample formats/rates makes it much more
> difficult but that could be done in the library level.
Yes, but which library?
> > > Why Linux can't provide only OSS API abstraction for user space
> > > application ? And/or why ALSA developers want to replace this by
> > > mostly bloated and pourly documented ALSA user space API ?
> >
> > Because OSS API doesn't cover many things. For example,
> >
> > - PCM with non-interleaved formats
> There is no need to handle non-interleaved data in kernel level drivers
> because all the devices use interleaved formats.
Many RME boards support only non-intereleave data.
> Handling
> interleaving/de-interleaving in the application/driver code can be done in
> a simple for loop. So why to make the driver/API more complicated with
> this.
>
> > - PCM with 3-bytes-packed 24bit formats
> Applications have no reasons to use for this kind of stupid format so OSS
> translates it to the usual 32 bit format on fly. In fact OSS API does
> have support for this format.
Well, this is stupid but very popular nowadays, unforunately :)
> > These functions are popluar on many sound devices.
> >
> > In addition, imagine how you would implement the following:
> >
> > - Combination of multiple devices
> > - Split of channels to concurrent accesses
> Could you be more specific with the above isues?
I meant to split channels of a single device to different processes
(e.g. front/rear/clfe for each). (I know it's doable but the question
is how to implement it.)
> > - Handling of floating pointer samples
> This is not necessary in the kernel drivers because user land apps/libs do
> this themselves. However OSS API defines a floating point data type just
> in case some future device needs it.
>
> > - Post/pre-effects (like chorus/reverb)
> OSS already does this (part of the softoss/vmix driver).
>
> > Forcing OSS API means to force to process the all things above in
> > the kernel. I guess many people would disagree with it.
> Wrong. This is not an API issue at all. It's an implementation one.
Indeed. But you know that almost all "OSS" applications access
directly the device files. There is no room to put a library to solve
these things in user-space.
> An alternative for doing some operations in the kernel is looping the
> audio data through an user land daemon. The application itself is still
> using the usual OSS API without knowing anything about any daemons. We
> have tested this approach and it works. There just has not been any good
> reason to use this approach instead of using kernel space approach.
> Passing data through multiple applications makes the latency issues to
> accumulate. If you do the processing in the kernel you will hit by the
> task scheduling latencies at most once.
Yes, I thought of the similar thing... But, is it really a preferred
approach?
> The OSS approach is not to make everything in the kernel. Things that can
> be done easier in the applications (or in libraries) have been left
> out from the API.
Basically, it's not 100% fault of OSS, IMO. But, looking at the
reality, apps do access directly to the kernel. It's worse in the
case of binary-only apps like flash or skype. To support these
things, the only "realistic" (OSS-ish) solution so far is to implement
the conversion routines in the kernel level.
Takashi
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 15:07 ` Tomasz Kłoczko
2006-01-05 16:14 ` Takashi Iwai
@ 2006-01-05 18:56 ` Lee Revell
2006-01-05 22:39 ` Joern Nettingsmeier
2 siblings, 0 replies; 84+ messages in thread
From: Lee Revell @ 2006-01-05 18:56 UTC (permalink / raw)
To: Tomasz Kłoczko
Cc: Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, ALSA development, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
On Thu, 2006-01-05 at 16:07 +0100, Tomasz Kłoczko wrote:
> - KNOWN FACT is OSS provides simpler API for user space for handle
> usual cases.
> Why Linux can't provide only OSS API abstraction for user space
> application ? And/or why ALSA developers want to replace this by
> mostly bloated and pourly documented ALSA user space API ?
>
Please, stop with the documentation thing. ALSA is perfectly well
documented. I guess the problem is that you googled "ALSA
documentation" and this page didn't come up as the first hit (or even on
the first page):
http://www.alsa-project.org/alsa-doc/alsa-lib/index.html
This is a Google bug. I suspect that the copius inter-document links
that Doxygen creates causes Google to think someone is trying to spam it
and penalizes the result.
Lee
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 15:07 ` Tomasz Kłoczko
2006-01-05 16:14 ` Takashi Iwai
2006-01-05 18:56 ` Lee Revell
@ 2006-01-05 22:39 ` Joern Nettingsmeier
2006-01-05 23:44 ` Tomasz Kłoczko
` (2 more replies)
2 siblings, 3 replies; 84+ messages in thread
From: Joern Nettingsmeier @ 2006-01-05 22:39 UTC (permalink / raw)
To: Tomasz Kłoczko
Cc: Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, ALSA development, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
Tomasz Kłoczko wrote:
> List all neccessary feactures and abstract them. Below this layer you
> can plug to this all device drivers. Where is the problem ?
users want to use all the bells and whistles that modern sound hardware
has to offer. so "necessary features" roughly equals the union of all
the "cool ideas of the week" of all soundcard vendors.
please have a look at, say, the rme hammerfall cards, compare them with
ye olde sblive, then take a look at usb audio devices and for dessert,
take a peek into current firewire hardware.
then push up your sleeves, design a small and elegant little abstraction
mechanism that is maximally effective in all circumstances and makes all
hardware features usable, wrap it up nicely and submit it to linus.
i look forward to hearing back from you, in, oh, 2015 or so?
jaroslav, takashi and the other alsa developers have been toiling with
this for years, and i hate to see them having to take shit from people
who don't do anything more with their sound hardware than listen to mp3s
in stereo and can't imagine anything else.
granted, there is always room for improvement. the alsa guys are very
receptive towards constructive criticism, when it is backed with a
little insight. many linux audio developers have criticised the API for
the high initial barrier, and ALSA certainly does not score that high in
the "making simple things simple" department. but it does make
*complicated things possible*, and all those rants of "gimme back me
oss" usually ignore this.
modem dialup users know better than to chime in to networking core
discussions and complain they don't need all that complexity. why do
professional audio users always have to put up with people who only
listen to mp3s whining about a complicate API?
i'll always grant you far better taste and insight into kernel matters
than i will ever have, but hey: the library is in userspace. it does not
clutter the kernel. so rrreeelaax!
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
if you are a free (as in "free speech") software developer
and you happen to be travelling near my home, drop me a line
and come round for a free (as in "free beer") beer. :-D
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 22:39 ` Joern Nettingsmeier
@ 2006-01-05 23:44 ` Tomasz Kłoczko
2006-01-05 23:49 ` Olivier Galibert
2006-01-06 0:00 ` Marcin Dalecki
2 siblings, 0 replies; 84+ messages in thread
From: Tomasz Kłoczko @ 2006-01-05 23:44 UTC (permalink / raw)
To: Joern Nettingsmeier
Cc: Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, ALSA development, James, sailer, linux-sound, zab,
kyle, parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2604 bytes --]
On Thu, 5 Jan 2006, Joern Nettingsmeier wrote:
[..]
> i look forward to hearing back from you, in, oh, 2015 or so?
Now we have 2006. Four years ALSA is in kernel tree.
2015 - 2006 = 9
4 < 9
Four years ago noone predisct some "temporary sound devices" like BT
headests in ALSA architecture (bt-sco was developed in 2002 and still
isn't merged in ALSA tree .. probably because module in current form can't
provide simple usage like "just plug and play").
This is not matter of any kind prediction because on market four
years ago was avalaible some "temporary sound devices". BT headsets
are real and still IIRC there is no way in current ALSA architecture point
where and how this must plugged.
Why ? Because most of soud stream routing are performed in user space
library abstraction. For handle this in current ALSA model you must
prepare EACH application for reciveing signals about for examaple
changing default soud device (for perform close old and open new). In ALSA
there is no layer where this kind of redirections can be managed outside
ALL applications in common and easy way for non-root users
Q: why Linux can't behive as it will have allways soud device with dummy
device plugged to /dev/null (if only soudcode is loaded) if there is no
soud hardware in system ? Look .. if you have loaded event module you have
virtual kbd and mouse .. but real kbd/mouse can be used only afrer load
keyboard/mouse modules.
Instead try to manage any kind of (even future) devices it will be good if
ALSA will be ready for manage only current "sound model devices" (like
mono, stereo, 5.1, 7.1 with simple way for extending set of this profiles)
but with *moved all sound routing* to kernel space with well defined
ioctl() or netlink (like in ipfilter) API for manage all configuration
details (for allow prepare for example cute GUI aplication for manage all
this for joe users). In this way also will be possible prepare some kernel
level interface for plugging additional modules (or loading external DSO
modules like in ipfilter for interract with with hardware in any other
way. Apply ipfilter way to soud subsystem can be also used for plugging
filters ..
So .. stop talking about future and start about preset problems. ALSA have
many problems with current devices (on soud subsystem *architecture level*)
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 22:39 ` Joern Nettingsmeier
2006-01-05 23:44 ` Tomasz Kłoczko
@ 2006-01-05 23:49 ` Olivier Galibert
2006-01-06 0:22 ` Joern Nettingsmeier
2006-01-06 0:00 ` Marcin Dalecki
2 siblings, 1 reply; 84+ messages in thread
From: Olivier Galibert @ 2006-01-05 23:49 UTC (permalink / raw)
To: Joern Nettingsmeier
Cc: Tomasz K?oczko, Jaroslav Kysela, Pete Zaitcev,
Alistair John Strachan, Adrian Bunk, Tomasz Torcz,
Jan Engelhardt, Andi Kleen, ALSA development, James, sailer,
linux-sound, zab, kyle, parisc-linux, jgarzik, Thorsten Knabe,
zwane, LKML
On Thu, Jan 05, 2006 at 11:39:43PM +0100, Joern Nettingsmeier wrote:
> modem dialup users know better than to chime in to networking core
> discussions and complain they don't need all that complexity. why do
> professional audio users always have to put up with people who only
> listen to mp3s whining about a complicate API?
Funnily enough, people who added SIGIO and epoll did not remove
select nor limited its capabilities.
The ALSA api has issues, whether you want to acknowledge them or not.
The OSS api has issues too, of course. But it is there to stay, and
it has advantages in some situations, like when simplicity or not
depending on a shared library matters. Ignoring it is stupid. Doing
your best to cripple it is stupid. The OSS api is an entrypoint in
the sound system as valid and important than others.
OG.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 23:49 ` Olivier Galibert
@ 2006-01-06 0:22 ` Joern Nettingsmeier
2006-01-06 1:30 ` Olivier Galibert
2006-01-06 2:20 ` Hannu Savolainen
0 siblings, 2 replies; 84+ messages in thread
From: Joern Nettingsmeier @ 2006-01-06 0:22 UTC (permalink / raw)
To: Olivier Galibert, Joern Nettingsmeier, Tomasz K?oczko,
Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Tomasz Torcz, Jan Engelhardt, Andi Kleen,
ALSA development, James, sailer, linux-sound, zab, kyle,
parisc-linux, jgarzik, Thorsten Knabe, zwane, LKML
Olivier Galibert wrote:
> On Thu, Jan 05, 2006 at 11:39:43PM +0100, Joern Nettingsmeier wrote:
>> modem dialup users know better than to chime in to networking core
>> discussions and complain they don't need all that complexity. why do
>> professional audio users always have to put up with people who only
>> listen to mp3s whining about a complicate API?
>
> Funnily enough, people who added SIGIO and epoll did not remove
> select nor limited its capabilities.
>
> The ALSA api has issues, whether you want to acknowledge them or not.
> The OSS api has issues too, of course. But it is there to stay, and
> it has advantages in some situations, like when simplicity or not
> depending on a shared library matters. Ignoring it is stupid. Doing
> your best to cripple it is stupid. The OSS api is an entrypoint in
> the sound system as valid and important than others.
agreed. nobody doubts this. a long time ago, this thread was about
removing obsolete *drivers*. that is orthogonal to the api issue.
then people starting whining about bugs in the alsa oss layer, while
being too lazy to file bug reports. nobody wants to "cripple" this api,
saying so is just stupid FUD and rather offensive.
then somebody started an api discussion, where *oss* was represented
quite fairly. it does have its nice sides. but to me it looks like most
of the people bashing *alsa* for its complexity have not understood the
problems it tries to (and does) solve.
shuffle 16 tracks of 24bit 48k audio in and out of the machine at a
latency where a professional drummer will not complain, with routing
options adequate for professional work, and then let's see how simple
your API is.
for those audio-challenged people out there: recall the tcp-offloading
discussions in the networking layer. nobody wants to do it, and they can
get away with it, because it does not buy you much and fucks up the api
big time.
in audioland, you have all kinds of funky shit going on in the hardware,
and you can't say, no we don't support that, to inelegant, because then
your stuff just can't compete.
hardware peculiarities cannot be abstracted away without sacrificing
efficiency, and this makes for a complicated api.
instead people keep whining and talk about headsets not working. sheesh.
tomasz, your impressive arithmetic with years is quite correct, but your
data is wrong. there have been years of development before alsa ever
came near the kernel. stop bitching, read up on some stuff (for
instance, find out about how different the gizmos i mentioned actually
are), get your facts straight. if by then you should happen to develop a
real interest in audio matters, the linux-audio-* lists welcome your
questions and contributions.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
if you are a free (as in "free speech") software developer
and you happen to be travelling near my home, drop me a line
and come round for a free (as in "free beer") beer. :-D
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 0:22 ` Joern Nettingsmeier
@ 2006-01-06 1:30 ` Olivier Galibert
2006-01-06 2:20 ` Hannu Savolainen
1 sibling, 0 replies; 84+ messages in thread
From: Olivier Galibert @ 2006-01-06 1:30 UTC (permalink / raw)
To: Joern Nettingsmeier
Cc: Tomasz K?oczko, Jaroslav Kysela, Pete Zaitcev,
Alistair John Strachan, Adrian Bunk, Tomasz Torcz,
Jan Engelhardt, Andi Kleen, ALSA development, James, sailer,
linux-sound, zab, kyle, parisc-linux, jgarzik, Thorsten Knabe,
zwane, LKML
On Fri, Jan 06, 2006 at 01:22:48AM +0100, Joern Nettingsmeier wrote:
> agreed. nobody doubts this. a long time ago, this thread was about
> removing obsolete *drivers*. that is orthogonal to the api issue.
Yeah, and there was way less flamage then too :-)
> then people starting whining about bugs in the alsa oss layer, while
> being too lazy to file bug reports. nobody wants to "cripple" this api,
> saying so is just stupid FUD and rather offensive.
You know, having the problem of device blocking between the oss api
kernel support (emulation is not a very good term in that context) and
the alsa api kernel support being meet by -EWONTFIX and "Don't use
OSS, use Alsa-lib, it's infinitely better" is somewhat offensive too.
You want me to file a bug report on that to see how far it's going to
go?
> then somebody started an api discussion, where *oss* was represented
> quite fairly. it does have its nice sides. but to me it looks like most
> of the people bashing *alsa* for its complexity have not understood the
> problems it tries to (and does) solve.
The "the documentation is perfect, you just not have read it"
fanboyism after having needed 2 or 3 days using that same
documentation to write a simple dynamic sound streaming in an
application I'm doing grates a little. Also, I notice that all my
comments about the numerous problms as seen in the windows world that
come with having a kernel api defined as a shared library have gone
beautifully ignored.
> shuffle 16 tracks of 24bit 48k audio in and out of the machine at a
> latency where a professional drummer will not complain, with routing
> options adequate for professional work, and then let's see how simple
> your API is.
I've done 64-channel microphone array capture, source tracking,
beamforming, speaker id and feeding an ASR over a network of computers
with a rather low latency. I wrote or participated in the complete
chain, from programming the capture dsp in assembly and debugging it
with a 'scope, writing the linux driver to get the data on the pci, or
writing the data transmission infrastructure. And the API is still
simple enough that it is becoming a de facto standard for smart space
applications and the comments are of the order of "there still are
some bugs (indeed there is, no doubts about that), but it allowed us
to having things working rather easily and fast".
Is that enough audio-unchallenged for you? Oh, it does video too.
> in audioland, you have all kinds of funky shit going on in the hardware,
> and you can't say, no we don't support that, to inelegant, because then
> your stuff just can't compete.
That's why you want a clean core and an extension mechanism, and add
the extensions in the core once they're general enough. See OpenGL.
> hardware peculiarities cannot be abstracted away without sacrificing
> efficiency, and this makes for a complicated api.
No, it doesn't. Again, see OpenGL. Audio hardware variability is
laughable compared to video hardware variability nowadays.
But you need to designed your API starting from what people want to
do, not from what the hardware does in detail.
OG.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 0:22 ` Joern Nettingsmeier
2006-01-06 1:30 ` Olivier Galibert
@ 2006-01-06 2:20 ` Hannu Savolainen
2006-01-10 9:54 ` Jaroslav Kysela
1 sibling, 1 reply; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-06 2:20 UTC (permalink / raw)
To: Joern Nettingsmeier
Cc: Olivier Galibert, Tomasz K?oczko, Jaroslav Kysela, Pete Zaitcev,
Alistair John Strachan, Adrian Bunk, Tomasz Torcz,
Jan Engelhardt, Andi Kleen, ALSA development, James, sailer,
linux-sound, zab, kyle, parisc-linux, jgarzik, Thorsten Knabe,
zwane, LKML
On Fri, 6 Jan 2006, Joern Nettingsmeier wrote:
> shuffle 16 tracks of 24bit 48k audio in and out of the machine at a latency
> where a professional drummer will not complain, with routing options adequate
> for professional work, and then let's see how simple your API is.
This is nonsense. This is something where the API design cannot make any
difference.
To get (say) 10 ms latencies you have to tell the sound subsystem
to allocate to buffer that is smaller than 10 ms. This in turn means that
the application must be able to run it's processing loop within less than 10
ms with 100.000...0% confidence. This is true regardless of how advanced
or primitive the audio subsystem (API) is.
What happens if some system load peak delays the application by 20 ms? The
result is complete failure. What is the ALSA (API) feature OSS doesn't
have that makes it able to predict what kind of output the application
should have fed to the device during the (about) 20 ms period of silence?
The fact is that there is nothing the audio subsystem can do to recover
the situation. For this very simple reason the OSS API lacks everything
that would be necessary to cope with this kind of problems.
After all the lowest possible audio latency depends on the level of real
time response capabilities of the underlaying OS/hardware/application
environment. If the app doesn't get the CPU right in time it will fail
(believe or not).
If the system can fullfill the response time requirements then any sound
subsystem will work equally well (unless they are seriously broken).
The sound subsystem implementations may have performance
differences of few usecs. However they don't make one better than another
in cases when the peak latencies are in millisecond range. In addition
same devices have FIFO/bus delays of up to few msec byt even then
advances in the audio subsystem/API design cannot help at all.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-06 2:20 ` Hannu Savolainen
@ 2006-01-10 9:54 ` Jaroslav Kysela
2006-01-10 13:50 ` Hannu Savolainen
0 siblings, 1 reply; 84+ messages in thread
From: Jaroslav Kysela @ 2006-01-10 9:54 UTC (permalink / raw)
To: Hannu Savolainen
Cc: Joern Nettingsmeier, Olivier Galibert, Tomasz K?oczko,
Pete Zaitcev, Alistair John Strachan, Adrian Bunk, Tomasz Torcz,
Jan Engelhardt, Andi Kleen, ALSA development, James, sailer,
linux-sound, zab, kyle, parisc-linux, jgarzik, Thorsten Knabe,
zwane, LKML
On Fri, 6 Jan 2006, Hannu Savolainen wrote:
> What happens if some system load peak delays the application by 20 ms? The
> result is complete failure. What is the ALSA (API) feature OSS doesn't
> have that makes it able to predict what kind of output the application
> should have fed to the device during the (about) 20 ms period of silence?
>
> The fact is that there is nothing the audio subsystem can do to recover
> the situation. For this very simple reason the OSS API lacks everything
> that would be necessary to cope with this kind of problems.
Applications should be notified that something is broken. If you have
a professional environment, you really need to know, if the output
survived all scheduling peaks and the audio data are delivered from/to
I/O in time.
Also, in the standard consumer environment is good to know that the system
have some trouble to deliver data in time (motivating developers of core
Linux kernel code or subsystems, or motivating app programers to set the
correct scheduling parameters) to fix remaining problems.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-10 9:54 ` Jaroslav Kysela
@ 2006-01-10 13:50 ` Hannu Savolainen
0 siblings, 0 replies; 84+ messages in thread
From: Hannu Savolainen @ 2006-01-10 13:50 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Joern Nettingsmeier, Olivier Galibert, Tomasz K?oczko,
Pete Zaitcev, Alistair John Strachan, Adrian Bunk, Tomasz Torcz,
Jan Engelhardt, Andi Kleen, ALSA development, James, sailer,
linux-sound, zab, kyle, parisc-linux, jgarzik, Thorsten Knabe,
zwane, LKML
On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
> On Fri, 6 Jan 2006, Hannu Savolainen wrote:
>
> > The fact is that there is nothing the audio subsystem can do to recover
> > the situation. For this very simple reason the OSS API lacks everything
> > that would be necessary to cope with this kind of problems.
>
> Applications should be notified that something is broken. If you have
> a professional environment, you really need to know, if the output
> survived all scheduling peaks and the audio data are delivered from/to
> I/O in time.
This is exactly how OSS API works. The application can check if there were
any errors so far. It can do it after finishing the playback or whenever
it likes. It can then show a dialog box saying that playback/recording
was not 100% error free. Alternatively it can show error counters on the
status line. Or most applications just don't care.
Best regards,
Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 22:39 ` Joern Nettingsmeier
2006-01-05 23:44 ` Tomasz Kłoczko
2006-01-05 23:49 ` Olivier Galibert
@ 2006-01-06 0:00 ` Marcin Dalecki
2 siblings, 0 replies; 84+ messages in thread
From: Marcin Dalecki @ 2006-01-06 0:00 UTC (permalink / raw)
To: Joern Nettingsmeier
Cc: Tomasz Kłoczko, Jaroslav Kysela, Pete Zaitcev,
Alistair John Strachan, Adrian Bunk, Olivier Galibert,
Tomasz Torcz, Jan Engelhardt, Andi Kleen, ALSA development,
James, sailer, linux-sound, zab, kyle, parisc-linux, jgarzik,
Thorsten Knabe, zwane, LKML
On 2006-01-05, at 23:39, Joern Nettingsmeier wrote:
> Tomasz Kłoczko wrote:
>> List all neccessary feactures and abstract them. Below this layer
>> you can plug to this all device drivers. Where is the problem ?
>
> users want to use all the bells and whistles that modern sound
> hardware has to offer. so "necessary features" roughly equals the
> union of all the "cool ideas of the week" of all soundcard vendors.
First and fore most users want simple things like for example playing
an mp3 file to just work.
Your concept that very many of them are interested in the high end
"features" of hardware you assume to be modern is wrong. Did you ever
notice that sound cards got just reduced to a simple AD/DA converter
combination? Modern hardware is frequently actually MUCH MUCH simpler
then old one used to be in this area.
> please have a look at, say, the rme hammerfall cards, compare them
> with ye olde sblive, then take a look at usb audio devices and for
> dessert, take a peek into current firewire hardware.
The existence of /dev/sound doesn't prohibit the existence of
/dev/bells_and_wistles (without any chance to work with anything else
then the vendors specific software).
That was precisely the situation with my sam9700 card....
> then push up your sleeves, design a small and elegant little
> abstraction mechanism that is maximally effective in all
> circumstances and makes all hardware features usable, wrap it up
> nicely and submit it to linus.
>
> i look forward to hearing back from you, in, oh, 2015 or so?
Your assumption about "all circumstances" is misguided. There is no
requirement for one size fits all here.
Look most people drive cars and not space shuttles.
> jaroslav, takashi and the other alsa developers have been toiling
> with this for years, and i hate to see them having to take shit
> from people who don't do anything more with their sound hardware
> than listen to mp3s in stereo and can't imagine anything else.
If hearing just the mp3 would just simply work with the alsa drivers
without getting in to too much hassle
with AC97 sound cards, which usually don't even include hardware
based volume controls nowadays, I'm pretty sure they wouldn't have to
"take this shit". And you should remember the bold announcements they
did make in first place.
> granted, there is always room for improvement. the alsa guys are
> very receptive towards constructive criticism, when it is backed
> with a little insight. many linux audio developers have criticised
> the API for the high initial barrier, and ALSA certainly does not
> score that high in the "making simple things simple" department.
> but it does make *complicated things possible*, and all those rants
> of "gimme back me oss" usually ignore this.
>
> modem dialup users know better than to chime in to networking core
> discussions and complain they don't need all that complexity. why
> do professional audio users always have to put up with people who
> only listen to mp3s whining about a complicate API?
> i'll always grant you far better taste and insight into kernel
> matters than i will ever have, but hey: the library is in
> userspace. it does not clutter the kernel. so rrreeelaax!
It clutters the application programming part very successfully.
BTW. Designing a sound API toward DMA, like ALSA does, is just plain
well beyond any hope...
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [OT] ALSA userspace API complexity
2006-01-05 12:01 ` Tomasz Kłoczko
2006-01-05 12:23 ` Jaroslav Kysela
@ 2006-01-05 12:47 ` Leonard Milcin Jr.
1 sibling, 0 replies; 84+ messages in thread
From: Leonard Milcin Jr. @ 2006-01-05 12:47 UTC (permalink / raw)
To: Tomasz Kłoczko
Cc: Jaroslav Kysela, Pete Zaitcev, Alistair John Strachan,
Adrian Bunk, Olivier Galibert, Tomasz Torcz, Jan Engelhardt,
Andi Kleen, alsa-devel, James, sailer, linux-sound, zab, kyle,
parisc-linux, jgarzik, Thorsten Knabe, zwane, linux-kernel
Tomasz Kłoczko wrote in his signature:
> -----------------------------------------------------------
> *Ludzie nie mają problemów, tylko sobie sami je stwarzają*
> -----------------------------------------------------------
> Allow me translate sentence from my signature to english
> "People do not have problems they create them themselves"
> and ALSA case matches in 100%.
Look, kloczek, how less problems we cold have by banishing
all the technology and going back to stone age?
The complexity is sometimes unavoidable if one tries to
please as many as possible. But why not userspace library
that simplifies access to ALSA for those who don't need
all the ,,complexity''? That pleases both -- those who
need feauters, and those who only need to pass something
to speakers. Maybe there are cards that work with OSS and
not with ALSA, and that may be the reason to keep it just
for some time. But in the long run I don't think there is
a need to have two sound systems in kernel just because
one is complicated and other lacks some features.
Leonard
^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2006-01-10 20:14 UTC | newest]
Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <4uzow-1g5-13@gated-at.bofh.it>
[not found] ` <5r0aY-2If-41@gated-at.bofh.it>
[not found] ` <5r3Ca-88G-81@gated-at.bofh.it>
[not found] ` <5reGV-6YD-23@gated-at.bofh.it>
[not found] ` <5reGV-6YD-21@gated-at.bofh.it>
[not found] ` <5rf9X-7yf-25@gated-at.bofh.it>
2006-01-04 11:56 ` [OT] ALSA userspace API complexity Patrizio Bassi
2006-01-04 18:07 ` Florian Schmidt
2006-01-04 18:46 ` Alistair John Strachan
2006-01-05 18:59 ` Lee Revell
2006-01-05 20:06 ` Patrizio Bassi
2006-01-05 20:11 ` Lee Revell
2006-01-05 20:47 ` Patrizio Bassi
2006-01-08 7:19 linux
2006-01-08 22:08 ` Hannu Savolainen
[not found] <5rdrx-4Yl-43@gated-at.bofh.it>
2006-01-05 14:01 ` Heikki Orsila
2006-01-05 14:24 ` Jaroslav Kysela
2006-01-05 14:45 ` Heikki Orsila
2006-01-10 9:22 ` Jaroslav Kysela
2006-01-10 11:50 ` Heikki Orsila
2006-01-05 14:51 ` Olivier Galibert
2006-01-05 15:26 ` Alexander E. Patrakov
2006-01-05 15:30 ` Jaroslav Kysela
2006-01-05 16:01 ` Alexander E. Patrakov
2006-01-05 18:11 ` Florian Schmidt
2006-01-05 15:33 ` Jaroslav Kysela
2006-01-05 16:48 ` Marcin Dalecki
2006-01-05 15:27 ` Heikki Orsila
2006-01-05 14:49 ` Alistair John Strachan
-- strict thread matches above, loose matches on Subject: below --
2005-07-26 15:08 [2.6 patch] schedule obsolete OSS drivers for removal Adrian Bunk
2006-01-03 19:37 ` Adrian Bunk
2006-01-03 23:10 ` Tomasz Kłoczko
2006-01-04 9:37 ` [OT] ALSA userspace API complexity Alistair John Strachan
[not found] ` <mailman.1136368805.14661.linux-kernel2news@redhat.com>
2006-01-04 11:00 ` Pete Zaitcev
2006-01-04 11:35 ` Jaroslav Kysela
2006-01-04 11:47 ` Pete Zaitcev
2006-01-04 14:23 ` Alistair John Strachan
2006-01-05 11:41 ` Olivier Galibert
2006-01-05 12:01 ` Tomasz Kłoczko
2006-01-05 12:23 ` Jaroslav Kysela
2006-01-05 14:21 ` Olivier Galibert
2006-01-05 15:07 ` Tomasz Kłoczko
2006-01-05 16:14 ` Takashi Iwai
2006-01-05 17:19 ` Marcin Dalecki
2006-01-05 20:13 ` Tomasz Kłoczko
2006-01-07 14:32 ` Takashi Iwai
2006-01-08 2:03 ` Olivier Galibert
2006-01-08 2:26 ` Martin Drab
2006-01-08 13:21 ` Olivier Galibert
2006-01-08 13:32 ` Jaroslav Kysela
2006-01-08 23:18 ` Pavel Machek
2006-01-08 9:42 ` Jaroslav Kysela
2006-01-08 13:04 ` Olivier Galibert
2006-01-08 13:23 ` Jaroslav Kysela
2006-01-08 13:38 ` Marcin Dalecki
2006-01-05 23:06 ` Hannu Savolainen
2006-01-05 23:39 ` Lee Revell
2006-01-05 23:56 ` Hannu Savolainen
2006-01-06 0:03 ` Lee Revell
2006-01-05 23:40 ` Lee Revell
2006-01-05 23:59 ` Hannu Savolainen
2006-01-06 15:03 ` Stefan Smietanowski
2006-01-06 15:48 ` Erik Mouw
2006-01-06 18:37 ` Lee Revell
2006-01-10 9:43 ` Jaroslav Kysela
2006-01-10 13:42 ` Hannu Savolainen
2006-01-10 14:08 ` Jaroslav Kysela
2006-01-10 14:17 ` Hannu Savolainen
2006-01-10 20:13 ` Marcin Dalecki
2006-01-06 0:14 ` Marcin Dalecki
2006-01-06 0:29 ` Martin Drab
2006-01-06 0:57 ` Marcin Dalecki
2006-01-06 1:49 ` Martin Drab
2006-01-06 1:21 ` Zan Lynx
2006-01-06 15:17 ` Stefan Smietanowski
2006-01-09 23:55 ` jerome lacoste
2006-01-10 2:29 ` Stefan Smietanowski
2006-01-06 3:14 ` Edgar Toernig
2006-01-06 3:33 ` Hannu Savolainen
2006-01-06 11:34 ` Florian Schmidt
2006-01-06 7:47 ` Jan Engelhardt
2006-01-07 14:45 ` Takashi Iwai
2006-01-05 18:56 ` Lee Revell
2006-01-05 22:39 ` Joern Nettingsmeier
2006-01-05 23:44 ` Tomasz Kłoczko
2006-01-05 23:49 ` Olivier Galibert
2006-01-06 0:22 ` Joern Nettingsmeier
2006-01-06 1:30 ` Olivier Galibert
2006-01-06 2:20 ` Hannu Savolainen
2006-01-10 9:54 ` Jaroslav Kysela
2006-01-10 13:50 ` Hannu Savolainen
2006-01-06 0:00 ` Marcin Dalecki
2006-01-05 12:47 ` Leonard Milcin Jr.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).