Is it time for remove (crap) ALSA from kernel tree ?

Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 594 bytes --]


Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
for Linux:

http://www.opensound.com/press/2007/oss-gpl-cddl.txt

So this source without problems code can be integragrated in Linus tree 
and after this Linux can provide much better soud supoport than 
with current ALSA.

Any plans for doing this ?

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Alan Cox]

On Sun, 24 Jun 2007 19:51:38 +0200 (CEST)
Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl> wrote:

> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than 
> with current ALSA.

Years ago Linux dumped OSS for ALSA because ALSA offered far better
functionality and support. Why would we go back to the stone age ?

Its something useful to various other platforms with basically no
hardware support but Linux has ALSA and very good hardware support and
ALSA even has emulation for back compatibility with old OSS apps.

Ten years ago it would probably have made a difference, five maybe, today
its a release of historical code at best, and since they shipped binary
modules for Linux more like 'getting around to complying with the
licence' than anything else.

Alan

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1534 bytes --]

On Sun, 24 Jun 2007, Alan Cox wrote:
[..]
> Years ago Linux dumped OSS for ALSA because ALSA offered far better
> functionality and support. Why would we go back to the stone age ?
>
> Its something useful to various other platforms with basically no
> hardware support but Linux has ALSA and very good hardware support and
> ALSA even has emulation for back compatibility with old OSS apps.
>
> Ten years ago it would probably have made a difference, five maybe, today
> its a release of historical code at best, and since they shipped binary
> modules for Linux more like 'getting around to complying with the
> licence' than anything else.

Sory Alan but I don't want philosophical/historical discuss.
Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

Maybe it is not clear for you but now way for introduce better OSS support 
for FOSS applications is completly oppened (there is no legal 
contrargumets fo not using OSS).
There is no ALSA on non-Linux systems (and will not be) so all other 
OSes/Unices will have better sound support than Linux (better on technical 
level and also on support level because all this systems will use 
common OSS) .. and it is only matter of time (when/how fast ?).
If you dont see this please stop ..

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 198 bytes --]


On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

Ok: The OSS cs46xx driver did not support the rear 2 channels.


	Jan
-- 

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Alan Cox]

> Sory Alan but I don't want philosophical/historical discuss.
> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

We dropped OSS for ALSA for technical reasons. Those being that ALSA
- has a better audio API
- is more flexible
- provides OSS as emulation
- supports more hardware

I used to maintain the kernel OSS code (the fork when Hannu and friends
took their project non-free). I did the work to make the sound layer
modular when the vendors realises that the open one needed to be modular
and that since that was the main play of the non-free one that Hannu
wasn't going to be doing it. From a technical perspective ALSA is the
better design especially for flexible devices.

At the desktop level these days it doesn't really matter much, the
desktops use their own sound servers which sit on top of OSS, ALSA and
other sound systems.

Alan
 

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/24/2007 09:27 PM, Jan Engelhardt wrote:

> On Jun 24 2007 21:24, Tomasz K?oczko wrote:
>> Try to answer on question "ALSA or OSS ?" using *only* technical
>> arguments.
> 
> Ok: The OSS cs46xx driver did not support the rear 2 channels.

Not sure it's going to count as only technical in wanker language but note 
that a very important driver such as Envy24 also works decidely worse in the 
open sourced OSS. In the "module envy24 not found" sense.

Which is the same sense as anything currently available from sound/isa in fact.

Rene.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Olivier Galibert]

On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> 
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API

You mean the undocumented, 100% ioctl one?  With one ioctl to write
interleaved sound, one for non-interleaved sound, in addition to
setting interleaved or not in the configuration?  I should check one
day which one wins.

Or the "library"?  Don't get me started on this one.


I take your word about the fact that the kernel side is better.  The
userland side, not so much.

  OG.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Carlo Wood]

On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> 
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API
> - is more flexible
> - provides OSS as emulation
> - supports more hardware

I sent a patch to the ALSA developers 4 years ago.
It was never included in the kernel :/

Here's the comment from a script that I once wrote to
make some closed-source dinosar code run (speech recognition)
on modern linux:

# Note that ALSA (Advanced Linux Sound Architecture), the sound drivers that
# replace the older OSS as of kernel 2.5, also introduce a problem for some
# soundcards: unlike the OSS drivers, the ALSA drivers limit the recording
# buffer to the hardware limit of your sound card.  For example, the SB Live!
# only has two 'period' buffers (called fragments before), and although
# viavoice requests an 'arbitrary number of periods, size 1024 bytes', it
# only gets two periods of 1024 bytes: 2048 bytes in total!  The ViaVoice
# engine however doesn't even process sound until it sees at least 6102 bytes.
# The 'solution' for this is to increase the buffer size (from 1024 to say
# 8192), this script also takes care of that.  Unfortunately, also that is
# possibly not enough: the sound is read from the hardware in chunks of
# 'period size' and having only two buffers this is often causing an underrun.
# When ALSA sees an underrun... it stops the sound stream.

My (four year old) patch can be found here:

http://www.xs4all.nl/~carlo17/alsa/index.html

I STILL think that ALSA should restart the stream after an underrun,
but I am not someone who asks twice :p usually.

-- 
Carlo Wood <carlo@alinoe.com>

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Jesper Juhl]

On 25/06/07, Carlo Wood <carlo@alinoe.com> wrote:
> On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > > Sory Alan but I don't want philosophical/historical discuss.
> > > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> >
> > We dropped OSS for ALSA for technical reasons. Those being that ALSA
> > - has a better audio API
> > - is more flexible
> > - provides OSS as emulation
> > - supports more hardware
>
> I sent a patch to the ALSA developers 4 years ago.
> It was never included in the kernel :/
>
Did you try resending it?
Sometimes patches get missed, overlooked, dropped on the floor by mistake etc.

[snip]
>
> My (four year old) patch can be found here:
>
> http://www.xs4all.nl/~carlo17/alsa/index.html
>
> I STILL think that ALSA should restart the stream after an underrun,
> but I am not someone who asks twice :p usually.
>
When it comes to getting patches into mainline, asking twice (or more)
is sometimes required, and it's considered your responsability as
submitter to resend a patch if noone reacts to it the first time
around.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Carlo Wood]

On Mon, Jun 25, 2007 at 12:48:45AM +0200, Jesper Juhl wrote:
> Did you try resending it?
> Sometimes patches get missed, overlooked, dropped on the floor by mistake 
> etc.
...
> When it comes to getting patches into mainline, asking twice (or more)
> is sometimes required, and it's considered your responsability as
> submitter to resend a patch if noone reacts to it the first time
> around.

Some history:

At the time I suffered from a severe RSI (Repitive Stress Injury) and
I had to take into account that I'd not be able to type anymore at
some point.  This is why I became interested in speech recognition,
even though I had to limit my typing time to 2 hours or so per day.
The only speech recognition software available for linux was 'ViaVoice',
a discontinued package sold by IBM. I managed to get my hand on one
(even though they aren't even sold anymore *cough cough*) and quickly
found out that it was so old that it didn't even run anymore. I hacked
the binary package (closed source and stuff) until it ran again (which
involved writing this kernel patch). However, then I found out that
ViaVoice was unusable for me: it didn't recognize my voice - it just
didn't work (it worked for others, so it much be my voice or accent
or whatever). Hence, I dropped the whole project. I could use my
two hours per day of typing better.

Now - about the resending the patch... I usually do, but I also
reschedule the priority of such a task. In this case, since I NEVER
do anything with recording - and the project that made me be involved
was dead as far as me was concerned - it got scheduled so far at
the bottom that I simply never got to it anymore.

I have no idea how much the code has changed in the meantime, but
the problem is/was this:

There is significant difference between ALSA and OSS such that an
application that works under OSS does not work anymore with the
OSS emulation under ALSA.

Firstly, the total recording buffer that you get is limited - while
that is not the case with OSS. Secondly, if that buffer runs full
(xrun) the stream is stopped permanently and not restarted, while
it is restarted with OSS.

You can download testcode.c from
http://www.xs4all.nl/~carlo17/alsa/index.html
and run it:

hikaru:~>./a.out
    Allocated 2 buffers of 1024 bytes.
    Allocated 2 buffers of 2048 bytes.
    Allocated 2 buffers of 4096 bytes.
    Successfully allocated a buffer that is large enough.
    Available bytes: 3072
    Available bytes: 4768
    Available bytes: 6432
    Available bytes: 8192
    Successfully caused an xrun.
    non-blocking fragments: 2
    non-blocking bytes: 8192
    Available bytes in buffer: 9856
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Stream is not restarted after xrun.

Since this is not the same behaviour as with OSS - I think it's a bug.

I don't know if the patch on that patch can still be applied,
but if not - then I'm sure you are more into that code than
me and it will be a lot easier for you to fix this the right
way in the correct kernel code :)

-- 
Carlo Wood <carlo@alinoe.com>

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Nobin Mathew]

> I sent a patch to the ALSA developers 4 years ago.
> It was never included in the kernel :/

ALSA maintainers are very open to patches. try sending this again

>
> Here's the comment from a script that I once wrote to
> make some closed-source dinosar code run (speech recognition)
> on modern linux:
>
> # Note that ALSA (Advanced Linux Sound Architecture), the sound drivers that
> # replace the older OSS as of kernel 2.5, also introduce a problem for some
> # soundcards: unlike the OSS drivers, the ALSA drivers limit the recording
> # buffer to the hardware limit of your sound card.  For example, the SB Live!
> # only has two 'period' buffers (called fragments before), and although
> # viavoice requests an 'arbitrary number of periods, size 1024 bytes', it
> # only gets two periods of 1024 bytes: 2048 bytes in total!  The ViaVoice
> # engine however doesn't even process sound until it sees at least 6102 bytes.
> # The 'solution' for this is to increase the buffer size (from 1024 to say
> # 8192), this script also takes care of that.  Unfortunately, also that is
> # possibly not enough: the sound is read from the hardware in chunks of
> # 'period size' and having only two buffers this is often causing an underrun.
> # When ALSA sees an underrun... it stops the sound stream.
>

native ALSA drivers has all these required features.

> My (four year old) patch can be found here:
>
> http://www.xs4all.nl/~carlo17/alsa/index.html
>
> I STILL think that ALSA should restart the stream after an underrun,
> but I am not someone who asks twice :p usually.

If it is native ALSA driver then it will restart after each underrun
and overrun. It is the applications job to do this, alsa-lib provides
all support for this. I have no idea of OSS and OSS emulation in ALSA.

If you have any queries please try sending to alsa-devel.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Carlo Florendo]

Tomasz Kłoczko wrote:
> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and 
> GLPv2 for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than with 
> current ALSA.

Actually, ALSA is doing fine and doing great.  There are issues of course, 
and some bugs too, but they've got their mailing list and Takashi Iwai 
fixes things quite well (and fast). Calling something crap will be useless 
until you can prove it.  One minor complaint I have with ALSA is its 
documentation.  It provides basic stuff but one has to do a lot of 
cross-references, IMHO, to understand its API.  Other than that, with a 
mature open code base, ALSA is more excellent than OSS.

Before calling things crap, you should be more technical and realistic 
(i.e. prove it with example).  Otherwise, you will just be wasting your 
time whining.  It shows too your lack of technical skill since you complain 
without knowing what you're complaining about.

Best Regards,

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Carlo Florendo]

Tomasz Kłoczko wrote:
> On Sun, 24 Jun 2007, Alan Cox wrote:
> [..]
>> Years ago Linux dumped OSS for ALSA because ALSA offered far better
>> functionality and support. Why would we go back to the stone age ?
>>
>> Its something useful to various other platforms with basically no
>> hardware support but Linux has ALSA and very good hardware support and
>> ALSA even has emulation for back compatibility with old OSS apps.
>>
>> Ten years ago it would probably have made a difference, five maybe, today
>> its a release of historical code at best, and since they shipped binary
>> modules for Linux more like 'getting around to complying with the
>> licence' than anything else.
> 
> Sory Alan but I don't want philosophical/historical discuss.
> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

You dare to demand technical arguments while you have not provided a single 
one.  How dare you?


-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Alan Cox]

> If it is native ALSA driver then it will restart after each underrun
> and overrun. It is the applications job to do this, alsa-lib provides
> all support for this. I have no idea of OSS and OSS emulation in ALSA.

OSS should autorestart on underrun and just moan about overruns and drop
bits. So if it's not following that behaviour he is IMHO correct for the
OSS emulation case.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3856 bytes --]

On Sun, 24 Jun 2007, Alan Cox wrote:

>> Sory Alan but I don't want philosophical/historical discuss.
>> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API

How better and where better ?
Please be more verbose :>

> - is more flexible

Yes .. if you have API with thin abstracttion (like ALSA has) theoreticaly 
you can do more but also by lack of some abstraction normal/usual things 
must be implemented in harder way. This was theory .. pracice is completly 
diffrent because some applications still provides better soud support 
(without interruption) when uses OSS emulation placed on top ALSA layer 
than compiled for direct use ALSA API.

Sound it in not rocket science. In 99.9% cases you need well abstracted 
API which ALSA doe not provide and this is real cause why so poor sound 
support in Linux applications is. Thin ALSA abstraction is main cause of 
avalaibability "tons" of additional soud user space APIs.
"Nice" plot with current situation you can see on:
http://blogs.adobe.com/penguin.swf/linuxaudio.png

On above blog with this picture you can find more arguments against ALSA. 
Your "more flexible" API in this case mean "ALSA provides only 
atomic/elentar API". Result: look on for example GNOME mixer (or alsa-util 
term based mixer). After each change soud card type in your computer you 
will see changes in triggers set. More .. your "more flexible" API does 
not provides usualy expected soud adjustmets parameters like volume level, 
central balance .. but instead provides PCM level. Try go on street 
(sometimes) and ask some PC users or someone who have at home audio 
devices like TV/radio/whatever and ask them "what is it f* PCM ?".
Yes .. ALSA provides "more flexible API" if you want "fly using glider 
have only raw pieces of wood" .. not if you want just fly and nothing 
more.

On http://blogs.adobe.com/penguin.swf/ you can see also calling for better 
abstracted API.

> - provides OSS as emulation

OSS provides ALSA emulation too.
Sorry but for me there is no technical argument.

> - supports more hardware

Please .. talk obout/back to ALSA/OSS API/KAPI compare.

> I used to maintain the kernel OSS code (the fork when Hannu and friends
> took their project non-free). I did the work to make the sound layer
> modular when the vendors realises that the open one needed to be modular
> and that since that was the main play of the non-free one that Hannu
> wasn't going to be doing it. From a technical perspective ALSA is the
> better design especially for flexible devices.

Look at Hannu blog and grab more arguments against ALSA:
http://www.4front-tech.com/hannublog/

To above I can only add again my argumet (which you saw more than year ago 
and still is without response): ALSA does not provide secure way for manage
sound device on mixing level.

> At the desktop level these days it doesn't really matter much, the
> desktops use their own sound servers which sit on top of OSS, ALSA and
> other sound systems.

So .. why ALSA provides so thin API if in most cases applications 
want only open soud device and/or in some more sohisticated case soud 
device in stere, 4+1, 5+1 or so mode  .. why provide API which not 
provides this expected functionalities in easy way ?
Bad/poor design or API planning or not well educated programmers or maybe 
ALSA still is developed by "belivers" (not enginers) who don't beleve in 
"soft mixing in kernel space isn't possible/secure" (even if it is 
provided in OSS) ?

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 647 bytes --]

On Sun, 24 Jun 2007, Jan Engelhardt wrote:

>
> On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
>> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> Ok: The OSS cs46xx driver did not support the rear 2 channels.

Yes it is true .. OSS (Hannu tree) dos not provide rear 2 channels in
cs46xx driver because .. in this OSS tree there is no cs46xx driver :>

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Mon, 25 Jun 2007 10:06:18 +0100,
Alan Cox wrote:
> 
> > If it is native ALSA driver then it will restart after each underrun
> > and overrun. It is the applications job to do this, alsa-lib provides
> > all support for this. I have no idea of OSS and OSS emulation in ALSA.
> 
> OSS should autorestart on underrun and just moan about overruns and drop
> bits. So if it's not following that behaviour he is IMHO correct for the
> OSS emulation case.

I think he is right in the case of read (although I don't remember his
post as my buffer overran).  The playback is automaically reset and
restarted at underrun.

But, the patch there is wrong.  It should handle -EPIPE, which means
XRUN, while -ESTRPIPE means the suspend state.


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 455 bytes --]


On Jun 25 2007 12:06, Tomasz Kłoczko wrote:
>>
>> On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
>> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>>
>> Ok: The OSS cs46xx driver did not support the rear 2 channels.
>
> Yes it is true .. OSS (Hannu tree) dos not provide rear 2 channels in
> cs46xx driver because .. in this OSS tree there is no cs46xx driver :>

I think that says it all why ALSA should be kept.


	Jan
-- 

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Sun, 24 Jun 2007 19:51:38 +0200 (CEST),
Tomasz Kłoczko wrote:
> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than 
> with current ALSA.
> 
> Any plans for doing this ?

Did you count the number of devices that tree supports?
You'll loose the support of all new laptops and mobos sold in the last
year :)

Honestly, I'm not fully against changing the current code base (or
crap, whatever, any childish name).  There are indeed many misdesigns.
But, replacing with the above is no option, IMO.  The OSS have also
many misdesigns, so the same argument would start again.  One should
learn something from history...

Anyway, if it's going to be more constructive, I'm willing to join in.


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Mon, 25 Jun 2007 11:51:59 +0200 (CEST),
Tomasz Kłoczko wrote:
> 
> On Sun, 24 Jun 2007, Alan Cox wrote:
> 
> >> Sory Alan but I don't want philosophical/historical discuss.
> >> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> >
> > We dropped OSS for ALSA for technical reasons. Those being that ALSA
> > - has a better audio API
> 
> How better and where better ?
> Please be more verbose :>
> 
> > - is more flexible
> 
> Yes .. if you have API with thin abstracttion (like ALSA has) theoreticaly 
> you can do more but also by lack of some abstraction normal/usual things 
> must be implemented in harder way. This was theory .. pracice is completly 
> diffrent because some applications still provides better soud support 
> (without interruption) when uses OSS emulation placed on top ALSA layer 
> than compiled for direct use ALSA API.
> 
> Sound it in not rocket science. In 99.9% cases you need well abstracted 
> API which ALSA doe not provide and this is real cause why so poor sound 
> support in Linux applications is. Thin ALSA abstraction is main cause of 
> avalaibability "tons" of additional soud user space APIs.

I disagree about this.  Tons of various user-space APIs would be
created anyway.  It's the nature of FOSS developemnt.


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1670 bytes --]

On Mon, 25 Jun 2007, Takashi Iwai wrote:
[..]
>> Sound it in not rocket science. In 99.9% cases you need well abstracted
>> API which ALSA doe not provide and this is real cause why so poor sound
>> support in Linux applications is. Thin ALSA abstraction is main cause of
>> avalaibability "tons" of additional soud user space APIs.
>
> I disagree about this.  Tons of various user-space APIs would be
> created anyway.  It's the nature of FOSS developemnt.

Please recall history of (for example) esound.
>From esound README:

"Esound is an audio mixing server that allows multiple
applications to output sound to the same audio device."

It was started in time when most cheap sound cards was without hw mixer.
And .. when today you use ALSA on sound card without hw mixer still all 
this (past ?) problems are actual.
Look on main reasons developing arts ..
In documentation many other user space APIs you can find the same 
or similar reasons. Look .. I'm talkimg about real facts. Your 
disagreement completly ommits *reasons* spending some time on preapare 
this soud APIs.

ALSA still does not provides good soud devices virtualization for more 
then one application. Each day I'm using bludy words when I'm try to use 
skype which oppens /dev/mixer after run galeon with flash plugin which 
opens /dev/snd/pcm* or when I start GNOME session with soud enabled 
(handled by esd whuich uses ALSA).

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1538 bytes --]

On Mon, 25 Jun 2007, Takashi Iwai wrote:
[..]
>> Any plans for doing this ?
>
> Did you count the number of devices that tree supports?

What is harder ? Bring ALSA API to the same level of functionalities as 
OSS provides or port (FOSS) ALSA device drivers to OSS ?

> You'll loose the support of all new laptops and mobos sold in the last
> year :)

You are loosing point lack of will ALSA developers to make this useable, 
and well documented. OSS it is stabkle API specyfication with good 
reputation. ALSA still is in development stage.

> Honestly, I'm not fully against changing the current code base (or
> crap, whatever, any childish name).  There are indeed many misdesigns.
> But, replacing with the above is no option, IMO.  The OSS have also
> many misdesigns, so the same argument would start again.  One should
> learn something from history...

OSS is at all misdesigned ? or in some points ? if partialy it was bad (in 
time start work on ALSA) why was not improved ?
For me it looks like ALSA developers don't know "don't move - improve" 
sentence.

kloczek
PS. /me still waiting for simple yes or no answer on my qustion from 
responsible people.
For example: if Hannu or other OSS developer will bring some patches it 
will be integrated or not in main tree ?
-- 
-----------------------------------------------------------
*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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Mon, 25 Jun 2007 13:36:23 +0200 (CEST),
Tomasz Kłoczko wrote:
> 
> [1  <text/plain; ISO-8859-2 (8bit)>]
> On Mon, 25 Jun 2007, Takashi Iwai wrote:
> [..]
> >> Sound it in not rocket science. In 99.9% cases you need well abstracted
> >> API which ALSA doe not provide and this is real cause why so poor sound
> >> support in Linux applications is. Thin ALSA abstraction is main cause of
> >> avalaibability "tons" of additional soud user space APIs.
> >
> > I disagree about this.  Tons of various user-space APIs would be
> > created anyway.  It's the nature of FOSS developemnt.
> 
> Please recall history of (for example) esound.
> >From esound README:
> 
> "Esound is an audio mixing server that allows multiple
> applications to output sound to the same audio device."
> 
> It was started in time when most cheap sound cards was without hw mixer.
> And .. when today you use ALSA on sound card without hw mixer still all 
> this (past ?) problems are actual.

Huh?  I have no problems with soft mixing...

> Look on main reasons developing arts ..
> In documentation many other user space APIs you can find the same 
> or similar reasons. Look .. I'm talkimg about real facts. Your 
> disagreement completly ommits *reasons* spending some time on preapare 
> this soud APIs.
> 
> ALSA still does not provides good soud devices virtualization for more 
> then one application. Each day I'm using bludy words when I'm try to use 
> skype which oppens /dev/mixer after run galeon with flash plugin which 
> opens /dev/snd/pcm* or when I start GNOME session with soud enabled 
> (handled by esd whuich uses ALSA).

So, do you mean the soft-mixing is the biggest issue?  That's just a
part of a design issue, and if we want to go to that way, the
impelemtation would be trivial, regardless on ALSA or not.  Totally 
irrelevant argument regarding "remove ALSA".


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Jan Engelhardt]

On Jun 25 2007 14:31, Takashi Iwai wrote:
>> It was started in time when most cheap sound cards was without hw mixer.
>> And .. when today you use ALSA on sound card without hw mixer still all 
>> this (past ?) problems are actual.
>
>Huh?  I have no problems with soft mixing...

Diverging from the discussion, how is soft mixing actually done? If it was done
in userspace, it would need shared memory, or a back relay from kernelspace to
userspace (and back again for the final output), otherwise I could not imagine
how all alsa streams came together at one point.


	Jan
-- 

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Olivier Galibert]

On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote:
> So, do you mean the soft-mixing is the biggest issue?  That's just a
> part of a design issue, and if we want to go to that way, the
> impelemtation would be trivial, regardless on ALSA or not.  Totally 
> irrelevant argument regarding "remove ALSA".

Soft mixing is actually the biggest issue because if you had
generalized soft-mixing in the kernel-visible audio ports[1] you would
win two things:

- programs could use the OSS API without interfering with the ALSA one
  or which each other

- programs coult use the ALSA kernel API directly without interfering
  either, which would allow alternative libalsa implementations for
  those who hate the current one

Frankly, mandatory libraries are extremely annoying, and mandatory
extremely complex overdesigned libraries are simply unbearable.

  OG.

[1] Which does *not* mean doing the mixing in the kernel.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Olivier Galibert]

On Mon, Jun 25, 2007 at 02:40:23PM +0200, Jan Engelhardt wrote:
> 
> On Jun 25 2007 14:31, Takashi Iwai wrote:
> >> It was started in time when most cheap sound cards was without hw mixer.
> >> And .. when today you use ALSA on sound card without hw mixer still all 
> >> this (past ?) problems are actual.
> >
> >Huh?  I have no problems with soft mixing...
> 
> Diverging from the discussion, how is soft mixing actually done? If it was done
> in userspace, it would need shared memory, or a back relay from kernelspace to
> userspace (and back again for the final output), otherwise I could not imagine
> how all alsa streams came together at one point.

SysV shared memory and semaphores, done in the alsa lib.

Yes, your kernel sound access library does shared mem, semaphores,
fork+exec and friends.

Back relay and virtual devices is the way it should have been done.

  OG.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Mon, 25 Jun 2007 14:47:50 +0200,
Olivier Galibert wrote:
> 
> On Mon, Jun 25, 2007 at 02:40:23PM +0200, Jan Engelhardt wrote:
> > 
> > On Jun 25 2007 14:31, Takashi Iwai wrote:
> > >> It was started in time when most cheap sound cards was without hw mixer.
> > >> And .. when today you use ALSA on sound card without hw mixer still all 
> > >> this (past ?) problems are actual.
> > >
> > >Huh?  I have no problems with soft mixing...
> > 
> > Diverging from the discussion, how is soft mixing actually done? If it was done
> > in userspace, it would need shared memory, or a back relay from kernelspace to
> > userspace (and back again for the final output), otherwise I could not imagine
> > how all alsa streams came together at one point.
> 
> SysV shared memory and semaphores, done in the alsa lib.
> 
> Yes, your kernel sound access library does shared mem, semaphores,
> fork+exec and friends.

FYI, fork+exec was removed long time ago.  shmem and semaphores still
remain, though.


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Mon, 25 Jun 2007 14:44:42 +0200,
Olivier Galibert wrote:
> 
> On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote:
> > So, do you mean the soft-mixing is the biggest issue?  That's just a
> > part of a design issue, and if we want to go to that way, the
> > impelemtation would be trivial, regardless on ALSA or not.  Totally 
> > irrelevant argument regarding "remove ALSA".
> 
> Soft mixing is actually the biggest issue because if you had
> generalized soft-mixing in the kernel-visible audio ports[1] you would
> win two things:
> 
> - programs could use the OSS API without interfering with the ALSA one
>   or which each other
> 
> - programs coult use the ALSA kernel API directly without interfering
>   either, which would allow alternative libalsa implementations for
>   those who hate the current one
> 
> Frankly, mandatory libraries are extremely annoying, and mandatory
> extremely complex overdesigned libraries are simply unbearable.

Hm...  I don't agree much with the virtual relay device solution.
I once experimentally implemented an ALSA-OSS virtual kernel driver.
But, it just gives more complexity.

Yes, the library solution has merits and demerits.  The library should
have been differently designed.  But, I don't think the virtual relay
is the best solution just because you can use a bare kernel
interface...


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Gabor Gombas]

On Mon, Jun 25, 2007 at 01:36:23PM +0200, Tomasz Kłoczko wrote:

> ALSA still does not provides good soud devices virtualization for more then 
> one application. Each day I'm using bludy words when I'm try to use skype 
> which oppens /dev/mixer [...]

Not true anymore:

skype   32381 gombasg  mem       CHR      116,7               4663 /dev/snd/pcmC0D0p
skype   32381 gombasg   32r      CHR      116,2               4301 /dev/snd/timer
skype   32381 gombasg   34u      CHR      116,7               4663 /dev/snd/pcmC0D0p
skype   32381 gombasg   35u      CHR      116,9               4674 /dev/snd/controlC0

I do not even have the OSS compat interface enabled in my kernel.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday 25 June 2007, Tomasz Kłoczko wrote:
> On Mon, 25 Jun 2007, Takashi Iwai wrote:
> [..]
> >> Any plans for doing this ?
> >
> > Did you count the number of devices that tree supports?
> 
> What is harder ? Bring ALSA API to the same level of functionalities as 
> OSS provides or port (FOSS) ALSA device drivers to OSS ?

This is impossible to answer unless somebody does the both
(as usual with the software).

> > You'll loose the support of all new laptops and mobos sold in the last
> > year :)
> 
> You are loosing point lack of will ALSA developers to make this useable, 
> and well documented. OSS it is stabkle API specyfication with good 
> reputation. ALSA still is in development stage.

Talking ALSA developers into adapting OSS seems to be a dead end road.

> > Honestly, I'm not fully against changing the current code base (or
> > crap, whatever, any childish name).  There are indeed many misdesigns.
> > But, replacing with the above is no option, IMO.  The OSS have also
> > many misdesigns, so the same argument would start again.  One should
> > learn something from history...
> 
> OSS is at all misdesigned ? or in some points ? if partialy it was bad (in 
> time start work on ALSA) why was not improved ?

Probably because of "two steps forward and one step back" rule. :)

Learning from history would mean moving forward and creating next generation
sound subsystem better than both ALSA and OSS.  This of course would require
cooperation between ALSA and OSS developers which may be the biggest problem.

> For me it looks like ALSA developers don't know "don't move - improve" 
> sentence.
> kloczek
> PS. /me still waiting for simple yes or no answer on my qustion from 
> responsible people.
> For example: if Hannu or other OSS developer will bring some patches it 
> will be integrated or not in main tree ?

Depends on patches, just bring them on!

Having some competition would be a good thing for both ALSA and OSS.

Thanks,
Bart

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Olivier Galibert]

On Mon, Jun 25, 2007 at 02:58:02PM +0200, Takashi Iwai wrote:
> Hm...  I don't agree much with the virtual relay device solution.
> I once experimentally implemented an ALSA-OSS virtual kernel driver.
> But, it just gives more complexity.

So instead you move the complexity in the library where it is worse.


> Yes, the library solution has merits and demerits.  The library should
> have been differently designed.  But, I don't think the virtual relay
> is the best solution just because you can use a bare kernel
> interface...

Whatever you do in the library won't solve the problem of properly
supporting the OSS interface.

  OG.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Adrian Bunk]

On Mon, Jun 25, 2007 at 02:44:42PM +0200, Olivier Galibert wrote:
> On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote:
> > So, do you mean the soft-mixing is the biggest issue?  That's just a
> > part of a design issue, and if we want to go to that way, the
> > impelemtation would be trivial, regardless on ALSA or not.  Totally 
> > irrelevant argument regarding "remove ALSA".
> 
> Soft mixing is actually the biggest issue because if you had
> generalized soft-mixing in the kernel-visible audio ports[1] you would
> win two things:
> 
> - programs could use the OSS API without interfering with the ALSA one
>   or which each other

This works with aoss.

If people often run into this problem it might make sense to deprecate 
the in-kernel OSS emulation and point people to the userspace emulation 
instead?

> - programs coult use the ALSA kernel API directly without interfering
>   either, which would allow alternative libalsa implementations for
>   those who hate the current one
>...

Allowing for some hypothetical implementation noone might ever write is 
not sucha strong point...

>   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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Renato S. Yamane]

Tomasz Kłoczko wrote:
> ALSA still does not provides good soud devices virtualization for more 
> then one application. Each day I'm using bludy words when I'm try to use 
> skype which oppens /dev/mixer after run galeon with flash plugin which 
> opens /dev/snd/pcm* or when I start GNOME session with soud enabled 
> (handled by esd whuich uses ALSA).


Install alsa-oss fix this problem?
<http://www.skype.com/help/guides/soundsetup_linux.html>

Best regards,
Renato

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1172 bytes --]

On Mon, 25 Jun 2007, Gabor Gombas wrote:

> On Mon, Jun 25, 2007 at 01:36:23PM +0200, Tomasz Kłoczko wrote:
>
>> ALSA still does not provides good soud devices virtualization for more then
>> one application. Each day I'm using bludy words when I'm try to use skype
>> which oppens /dev/mixer [...]
>
> Not true anymore:
>
> skype   32381 gombasg  mem       CHR      116,7               4663 /dev/snd/pcmC0D0p
> skype   32381 gombasg   32r      CHR      116,2               4301 /dev/snd/timer
> skype   32381 gombasg   34u      CHR      116,7               4663 /dev/snd/pcmC0D0p
> skype   32381 gombasg   35u      CHR      116,9               4674 /dev/snd/controlC0
>
> I do not even have the OSS compat interface enabled in my kernel.

Sorry but skype does not for me after switching to ALSA (on skype cfg 
level). 
Probably ALSA developers can explain why :>
All above on fresh FC6 and 1.3.53 skype.

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/25/2007 01:36 PM, Tomasz Kłoczko wrote:

> Please recall history of (for example) esound.
>> From esound README:
> 
> "Esound is an audio mixing server that allows multiple
> applications to output sound to the same audio device."
> 
> It was started in time when most cheap sound cards was without hw mixer.

The same situation as today, that is.

> And .. when today you use ALSA on sound card without hw mixer still all 
> this (past ?) problems are actual.

ALSA mixes by default since something like 1.0.10 (november 2005).

> Look on main reasons developing arts ..

Which started at a time there was no ALSA, has been basically dead for 6 
years now and has at the moment finally been dropped by its last user.

> In documentation many other user space APIs you can find the same or 
> similar reasons. Look .. I'm talkimg about real facts. Your disagreement
> completly ommits *reasons* spending some time on preapare this soud
> APIs.

The "linux audio jungle" picture you posted a link to:

http://blogs.adobe.com/penguin.swf/linuxaudio.png

shows more arrows pointing to OSS than it does to ALSA and with a number of 
those coming from things that existed before there even was an ALSA and yet 
somehow you maintain this userspace audio jungle is ALSA's fault?

The Linux userspace audio situation is improving; since software mixing, 
plain vanilla ALSA is a good, single solution to a majority of uses and 
something like Phonon which is going to arrive later this year seems poised 
to provide a nice high level API, including for people who believe that 
audio is about playing you-got-mail jingles.

The reason we're not there yet is in part _due_ to people maintaining that 
OSS is somehow a valid choice on Linux. Ie:

> ALSA still does not provides good soud devices virtualization for more 
> then one application. Each day I'm using bludy words when I'm try to use
> skype which oppens /dev/mixer after run galeon [ ... ]

/dev/mixer is an OSS device. Recent versions of skype should (as far as I've 
been told) be able to use native ALSA but if you're using an older version 
you get what you asked for. Should the ALSA OSS emulation try its damndest 
to support proprietary, bugridden closed source junk such as skype? Opinions 
probably vary but I'd say yes. Let's not make it, old versions of it at 
that, into the reference application though.

Video is a much more significant problem for desktop Linux than audio is and 
solutions are going to arrive combined as they are both userspace (ie, not 
kernel, not DRI, not ALSA, not OSS) multimedia problems. I have high hopes 
especially for the new technologies that went into KDE4. Haven't payed much 
attention to GNOME though so not sure what they're upto. Non-stellar 
cooperation between those two large desktop initiatives in the field of 
multimedia is another reason for things not being there yet. Go bark up 
those trees instead.

Rene.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2479 bytes --]

On Mon, 25 Jun 2007, Renato S. Yamane wrote:

> Tomasz Kłoczko wrote:
>> ALSA still does not provides good soud devices virtualization for more then 
>> one application. Each day I'm using bludy words when I'm try to use skype 
>> which oppens /dev/mixer after run galeon with flash plugin which opens 
>> /dev/snd/pcm* or when I start GNOME session with soud enabled (handled by 
>> esd whuich uses ALSA).
>
>
> Install alsa-oss fix this problem?
> <http://www.skype.com/help/guides/soundsetup_linux.html>

No. Read above again and you will see I'm taking about using OSS emulation 
on top ALSA. It does not work with above scenario.

# lsmod | grep snd
snd_emu10k1_synth      11073  0
snd_emux_synth         35681  1 snd_emu10k1_synth
snd_seq_virmidi        11336  1 snd_emux_synth
snd_seq_midi_emul      10049  1 snd_emux_synth
snd_emu10k1           131121  2 snd_emu10k1_synth
snd_intel8x0           36837  5
snd_seq_dummy           7877  0
snd_ac97_codec         98941  2 snd_emu10k1,snd_intel8x0
snd_seq_oss            34257  0
snd_mpu401             12521  0
snd_mpu401_uart        12633  1 snd_mpu401
snd_seq_midi_event     11337  2 snd_seq_virmidi,snd_seq_oss
snd_rawmidi            27233  3 snd_seq_virmidi,snd_emu10k1,snd_mpu401_uart
snd_seq                52377  8 snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
ac97_bus                6721  1 snd_ac97_codec
snd_seq_device         12245  7 snd_emu10k1_synth,snd_emux_synth,snd_emu10k1,snd_seq_dummy,snd_seq_oss,snd_rawmidi,snd_seq
snd_pcm_oss            44129  0
snd_mixer_oss          19785  4 snd_pcm_oss
snd_util_mem            8904  2 snd_emux_synth,snd_emu10k1
snd_pcm                76653  5 snd_emu10k1,snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_hwdep              13133  2 snd_emux_synth,snd_emu10k1
snd_timer              25565  3 snd_emu10k1,snd_seq,snd_pcm
snd                    55301  21 snd_emux_synth,snd_seq_virmidi,snd_emu10k1,snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_mpu401,snd_mpu401_uart,snd_rawmidi,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_timer
soundcore              11809  4 snd
snd_page_alloc         13897  3 snd_emu10k1,snd_intel8x0,snd_pcm

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Gabor Gombas]

On Mon, Jun 25, 2007 at 03:41:44PM +0200, Tomasz Kłoczko wrote:

> Sorry but skype does not for me after switching to ALSA (on skype cfg 
> level). Probably ALSA developers can explain why :>
> All above on fresh FC6 and 1.3.53 skype.

$ dpkg -l | grep skype
ii  skype                             1.4.0.74-1

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Lennart Sorensen]

On Sun, Jun 24, 2007 at 07:51:38PM +0200, Tomasz K?oczko wrote:
> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than 
> with current ALSA.
> 
> Any plans for doing this ?

In my experience OSS is a pile of crap compared to ALSA.  The only thing
it has ever had was support for sound chips that requried an NDA to get
the specs.

Keep alsa, but possibly add support to alsa for whichever devices are
missing support.

--
Len Sorensen

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 436 bytes --]

On Mon, 25 Jun 2007, Lennart Sorensen wrote:
[..]
> In my experience OSS is a pile of crap compared to ALSA.

Could you say something more detailed about this compare ?

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 8607 bytes --]

On Mon, 25 Jun 2007, Takashi Iwai wrote:
[..]
>> ALSA still does not provides good soud devices virtualization for more
>> then one application. Each day I'm using bludy words when I'm try to use
>> skype which oppens /dev/mixer after run galeon with flash plugin which
>> opens /dev/snd/pcm* or when I start GNOME session with soud enabled
>> (handled by esd whuich uses ALSA).
>
> So, do you mean the soft-mixing is the biggest issue?  That's just a
> part of a design issue, and if we want to go to that way, the
> impelemtation would be trivial, regardless on ALSA or not.  Totally
> irrelevant argument regarding "remove ALSA".

I dont know is soft mixing is biggest issue but ..
Few minutes ago I'm upgrade to skype 1.4.x.

Lets try again above experiment:

$ strace -f -e trace=file galeon 2>&1 | grep dev/snd
[pid 28593] open("/dev/snd/controlC0", O_RDWR) = 46
[pid 28593] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 47

OK .. now I'm enter on www.youtube.com and start playing random video.
Look on above: soud device was oppened in non bloking mode.

After few seconds I'm close tab with video in galeon.
Just after this I'm start skype and try call to test123 and calling isn't 
possible:

$ strace -f -e trace=file skype 2>&1 | grep dev/snd
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC3", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC4", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC5", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC6", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC7", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC8", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC9", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC10", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC11", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC12", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC13", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC14", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC15", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC16", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC17", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC18", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC19", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC20", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC21", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC22", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC23", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC24", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC25", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC26", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC27", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC28", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC29", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC30", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC31", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC3", O_RDONLY <unfinished ...>
[pid 30173] open("/dev/snd/controlC4", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC5", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC6", O_RDONLY <unfinished ...>
[pid 30173] open("/dev/snd/controlC7", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC8", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC9", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC10", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC11", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC12", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC13", O_RDONLY <unfinished ...>
[pid 30173] open("/dev/snd/controlC14", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC15", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC16", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC17", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC18", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC19", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC20", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC21", O_RDONLY) =tory)
[pid 30173] open("/dev/snd/controlC23", O_RDo such file or directory)
[pid 30173] open("/dev/snd/controlC24", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/control O_RDONLY) = -1 ENOENT (No suchfile or directory)
[pid 30173] open("/dev/snd/controlC26", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC27", O_RDONLY) = -1 ENOENsuch file or directory)
[pid 30173] open("/ev/snd/controlC28", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC29", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC30", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_ASYNC) = -1 EBUSY (Device or resource busy)
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/pcmC0D0c", O_RDWR|O_NONBLOCK|O_ASYNC) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/pcmC0D0c", O_RDWR|O_NONBLOCK|O_ASYNC) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR|O_NONBLOCK) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 44
[pid 30173] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_ASYNC) = -1 EBUSY (Device or resource busy)
[..]

/dev/snd/pcmC0D0p is busy ? YES because it was oppened by another 
application in non blocking mode which makes device .. unavalable to other :)
Welcome in wonderful ALSA word ..

And interesting .. why skype tries to open so meny devices (?)

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*

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Lennart Sorensen]

On Mon, Jun 25, 2007 at 05:48:21PM +0200, Tomasz K?oczko wrote:
> On Mon, 25 Jun 2007, Lennart Sorensen wrote:
> [..]
> >In my experience OSS is a pile of crap compared to ALSA.
> 
> Could you say something more detailed about this compare ?

Well the last time I bothered to look at OSS, it was still stuck at
supproting stereo only.  It believed that if a card supported SB
emulation, then adding support for that was good enough.  it also
thought supporting the GUS PnP through emulation of the original GUS
counted as support.  Essentially it was all about having a long list of
supported chips, where support simply meant it could make some sounds,
and if you were lucky it might even do stereo.  At the time ALSA was
already far beyond that in supporting all the inputs and outputs of many
cards, supporting their true native capabilities, rather than some
mediocre emulation mode.  The fact ALSA was open source sure didn't hurt
either.

OSS being willing to sign NDAs also didn't help the rest of the linux
community in any way when it came to trying to get hardware makers to
release specs so drivers could actually be written for inclusion in the
kernel.

--
Len Sorensen

Handling xruns in OSS (was re:whatever)

[Hannu Savolainen]

Takashi Iwai kirjoitti:
> At Mon, 25 Jun 2007 10:06:18 +0100,
> Alan Cox wrote:
>   
>>> If it is native ALSA driver then it will restart after each underrun
>>> and overrun. It is the applications job to do this, alsa-lib provides
>>> all support for this. I have no idea of OSS and OSS emulation in ALSA.
>>>       
>> OSS should autorestart on underrun and just moan about overruns and drop
>> bits. So if it's not following that behaviour he is IMHO correct for the
>> OSS emulation case.
>>     
>
> I think he is right in the case of read (although I don't remember his
> post as my buffer overran).  The playback is automaically reset and
> restarted at underrun.
>
> But, the patch there is wrong.  It should handle -EPIPE, which means
> XRUN, while -ESTRPIPE means the suspend state.
>   
To be exact the OSS should not even stop the device when a xrun occurs. 
Instead it should keep playing silence until the application writes more 
output data and to discard the oldest recorded data when an overrun 
occurs. This is more effective than stopping and restarting the device.

Best regards,

Hannu

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Hannu Savolainen]

Tomasz Kłoczko kirjoitti:
> On Sun, 24 Jun 2007, Jan Engelhardt wrote:
>
>>
>> On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
>>> Try to answer on question "ALSA or OSS ?" using *only* technical 
>>> arguments.
>>
>> Ok: The OSS cs46xx driver did not support the rear 2 channels.
The cs46xx OSS driver in the kernel is not our work. This discussion is 
about _our_ OSS 4.0 so the above is not a valid argument.
> Yes it is true .. OSS (Hannu tree) dos not provide rear 2 channels in
> cs46xx driver because .. in this OSS tree there is no cs46xx driver :>
The driver for cs46xx/cs4280 devices in OSS 4.0 is called cs4280.c. It's 
based on the same sample sources from Crystal than the kernel cs46xx 
one. It doesn't support the rear channels any better which could be an 
argument. However OSS is now an open source community project so anybody 
has freedom to fix this problem.

Best regards,

Hannu

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Hannu Savolainen]

Takashi Iwai kirjoitti:
> At Sun, 24 Jun 2007 19:51:38 +0200 (CEST),
> Tomasz Kłoczko wrote:
>   
>> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
>> for Linux:
>>
>> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
>>
>> So this source without problems code can be integragrated in Linus tree 
>> and after this Linux can provide much better soud supoport than 
>> with current ALSA.
>>
>> Any plans for doing this ?
>>     
>
> Did you count the number of devices that tree supports?
> You'll loose the support of all new laptops and mobos sold in the last
> year :)
>   
They are all based on HD audio which is supported by OSS. Ok, our HDA 
driver driver still needs some work which was one of the reasons why we 
are moving to the community development model.
> Honestly, I'm not fully against changing the current code base (or
> crap, whatever, any childish name).  There are indeed many misdesigns.
> But, replacing with the above is no option, IMO.  The OSS have also
> many misdesigns, so the same argument would start again.  One should
> learn something from history...
>   
Exactly. Good to know that we are both thinking in the same way.
> Anyway, if it's going to be more constructive, I'm willing to join in.
>   
I think it's going to be constructive.

We have no intention to push OSS back to the kernel or to replace ALSA. 
That alternative is not realistic any more. In addition OSS is a 
cross-platform product and staying more or less outside various kernel 
trees should provide better flexibility.

What we would like to push is that the old "deprecated" OSS/Free are 
removed from the kernel. OSS/Free is based on about years old OSS API 
version which was too limited for many applications. Having OSS/Free in 
the kernel doesn't serve any purpose.

Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
rather different. Both of them have some good points and bad points. For 
ordinary users it doesn't matter which API is used by the applications 
as long as they work. Just the application developers can see the real 
difference. Some of them prefer OSS while some other prefer ALSA and 
this should be their "freedom of choice".

I think the ideal solution would be that both ALSA and OSS APIs can 
co-exist by sharing the same low level drivers (which has already been 
demonstrated). The low level driver interfaces in both systems are 
practically identical. This means that ALSA's core can work with OSS' 
drivers and vice versa.

Today both OSS and ALSA teams have to spend significant amounts of time 
in emulating the "alien" APIs. Making OSS and ALSA to co-exist will 
require some work in both sides but that should be nothing when compared 
to the effort required for emulation.

Just my 2 cents.

Best regards,

Hannu

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/25/2007 07:00 PM, Tomasz Kłoczko wrote:

> $ strace -f -e trace=file galeon 2>&1 | grep dev/snd
> [pid 28593] open("/dev/snd/controlC0", O_RDWR) = 46
> [pid 28593] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 47

[ ... ]

> [pid 30173] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_ASYNC) = -1 
> EBUSY (Device or resource busy)
> [..]
> 
> /dev/snd/pcmC0D0p is busy ? YES because it was oppened by another 
> application in non blocking mode which makes device .. unavalable to 
> other :)

Nothing to do with O_NONBLOCK:

$ strace -f -e trace=file firefox 2>&1 | grep dev/snd
[pid  1889] ....
[pid  1889] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 38
[pid  1889] open("/dev/snd/controlC0", O_RDONLY) = 37
[pid  1889] open("/dev/snd/timer", O_RDONLY|O_NONBLOCK) = 37

$ strace -f -e trace=file ogg123 foo.ogg 2>&1 | grep dev/snd
[pid  1916] ...
[pid  1916] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_APPEND) = 5
[pid  1916] open("/dev/snd/controlC0", O_RDONLY) = 4
[pid  1916] open("/dev/snd/timer", O_RDONLY|O_NONBLOCK) = 4

And both the youtube video (flash 9) and my ogg file play fine. Now, I don't 
actually know about that O_ASYNC thing you have in there but it looks as 
though you're simply not using dmix. Which card, and if you specify an ALSA 
device somewhere, is it the "default" device?

And fix your inbound mailer -- it's rejecting my posts.

Rene.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Adrian Bunk]

On Tue, Jun 26, 2007 at 12:18:05AM +0300, Hannu Savolainen wrote:
>...
> What we would like to push is that the old "deprecated" OSS/Free are 
> removed from the kernel. OSS/Free is based on about years old OSS API 
> version which was too limited for many applications. Having OSS/Free in the 
> kernel doesn't serve any purpose.

I am slowly removing all parts of the in-kernel OSS with ALSA drivers 
for the same hardware.

The remaining drivers can roughly be divided into two categories:
- some ISA cards not supported by ALSA
- some drivers for unusual hardware (read: not a PC) not supported by ALSA

As long as we don't have ALSA drivers for them (which might in some 
cases never happen) I'd prefer to keep them for now.

> Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
> rather different. Both of them have some good points and bad points. For 
> ordinary users it doesn't matter which API is used by the applications as 
> long as they work. Just the application developers can see the real 
> difference. Some of them prefer OSS while some other prefer ALSA and this 
> should be their "freedom of choice".
>...

I'm glad to hear this.  :-)

> Best regards,
>
> Hannu

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

Re: Handling xruns in OSS (was re:whatever)

[Takashi Iwai]

At Mon, 25 Jun 2007 23:09:21 +0300,
Hannu Savolainen wrote:
> 
> Takashi Iwai kirjoitti:
> > At Mon, 25 Jun 2007 10:06:18 +0100,
> > Alan Cox wrote:
> >   
> >>> If it is native ALSA driver then it will restart after each underrun
> >>> and overrun. It is the applications job to do this, alsa-lib provides
> >>> all support for this. I have no idea of OSS and OSS emulation in ALSA.
> >>>       
> >> OSS should autorestart on underrun and just moan about overruns and drop
> >> bits. So if it's not following that behaviour he is IMHO correct for the
> >> OSS emulation case.
> >>     
> >
> > I think he is right in the case of read (although I don't remember his
> > post as my buffer overran).  The playback is automaically reset and
> > restarted at underrun.
> >
> > But, the patch there is wrong.  It should handle -EPIPE, which means
> > XRUN, while -ESTRPIPE means the suspend state.
> >   
> To be exact the OSS should not even stop the device when a xrun occurs. 
> Instead it should keep playing silence until the application writes more 
> output data and to discard the oldest recorded data when an overrun 
> occurs. This is more effective than stopping and restarting the device.

Ah, thanks for the hint!

BTW, in this case, how the fragment is aligned to the newly given
samples?  Since the stream is running, and apps may feed the new
samples at any time.  Especially when it uses a small double-buffer
(two short fragments), the wake-up timing is tight, and may introduce
another underrun soon again.


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Tue, 26 Jun 2007 00:18:05 +0300,
Hannu Savolainen wrote:
> 
> Takashi Iwai kirjoitti:
> > At Sun, 24 Jun 2007 19:51:38 +0200 (CEST),
> > Tomasz Kłoczko wrote:
> >   
> >> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> >> for Linux:
> >>
> >> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> >>
> >> So this source without problems code can be integragrated in Linus tree 
> >> and after this Linux can provide much better soud supoport than 
> >> with current ALSA.
> >>
> >> Any plans for doing this ?
> >>     
> >
> > Did you count the number of devices that tree supports?
> > You'll loose the support of all new laptops and mobos sold in the last
> > year :)
> >   
> They are all based on HD audio which is supported by OSS. Ok, our HDA 
> driver driver still needs some work which was one of the reasons why we 
> are moving to the community development model.

The HD-audio is still messy on ALSA, too.
There are a lot room to improve there.

> > Honestly, I'm not fully against changing the current code base (or
> > crap, whatever, any childish name).  There are indeed many misdesigns.
> > But, replacing with the above is no option, IMO.  The OSS have also
> > many misdesigns, so the same argument would start again.  One should
> > learn something from history...
> >   
> Exactly. Good to know that we are both thinking in the same way.
> > Anyway, if it's going to be more constructive, I'm willing to join in.
> >   
> I think it's going to be constructive.
> 
> We have no intention to push OSS back to the kernel or to replace ALSA. 
> That alternative is not realistic any more. In addition OSS is a 
> cross-platform product and staying more or less outside various kernel 
> trees should provide better flexibility.
> 
> What we would like to push is that the old "deprecated" OSS/Free are 
> removed from the kernel. OSS/Free is based on about years old OSS API 
> version which was too limited for many applications. Having OSS/Free in 
> the kernel doesn't serve any purpose.
> 
> Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
> rather different. Both of them have some good points and bad points. For 
> ordinary users it doesn't matter which API is used by the applications 
> as long as they work. Just the application developers can see the real 
> difference. Some of them prefer OSS while some other prefer ALSA and 
> this should be their "freedom of choice".

Fully agreed, and I'm glad that we can go to constructive discussions
:)

> I think the ideal solution would be that both ALSA and OSS APIs can 
> co-exist by sharing the same low level drivers (which has already been 
> demonstrated). The low level driver interfaces in both systems are 
> practically identical. This means that ALSA's core can work with OSS' 
> drivers and vice versa.

Yeah, that's in my mind, too.
The ALSA driver codes are fairly modularized and have separate core
and accessor codes.  The latter, lowlevel driver code, could be
relatively easily adapted to different frameworks.  This can be a
win-win.

However, the question again is a "bigger picture" of the whole sound
system -- what to be included in the kernel side and what to be in
user-space.  For example, a typical problem is software mixing.  Also,
we can't forget the sample rate conversion since SRC may influence
much more on the sound quality than mixing.  More discussions about
such a system design should be done at this time.


thanks,

Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Jeff Garzik]

Hannu Savolainen wrote:
> Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
> rather different. Both of them have some good points and bad points. For 
> ordinary users it doesn't matter which API is used by the applications 
> as long as they work. Just the application developers can see the real 
> difference. Some of them prefer OSS while some other prefer ALSA and 
> this should be their "freedom of choice".
> 
> I think the ideal solution would be that both ALSA and OSS APIs can 
> co-exist by sharing the same low level drivers (which has already been 
> demonstrated). The low level driver interfaces in both systems are 
> practically identical. This means that ALSA's core can work with OSS' 
> drivers and vice versa.
> 
> Today both OSS and ALSA teams have to spend significant amounts of time 
> in emulating the "alien" APIs. Making OSS and ALSA to co-exist will 
> require some work in both sides but that should be nothing when compared 
> to the effort required for emulation.

Speaking as another OSS driver author and maintainer, who ACK'd the move 
to ALSA...

In Linux we typically do not do two APIs and codebases for the same 
purpose.  If we do, like sys_mmap and sys_mmap2, it's an older legacy 
interface that never changes, that we are moving people AWAY from, and a 
newer interface.

I see no reason to change from the path at which upstream has arrived: 
OSS is a legacy API that's frozen in time, and ALSA provides the new stuff.

If you have ALSA criticisms, the right thing to do is fix ALSA. 
Upstream OSS was a dead-end code duplication & maintenance nightmare.  I 
know.  I was doing some of that maintenance and driver writing.

	Jeff

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Wakko Warner]

Adrian Bunk wrote:
> On Tue, Jun 26, 2007 at 12:18:05AM +0300, Hannu Savolainen wrote:
> >...
> > What we would like to push is that the old "deprecated" OSS/Free are 
> > removed from the kernel. OSS/Free is based on about years old OSS API 
> > version which was too limited for many applications. Having OSS/Free in the 
> > kernel doesn't serve any purpose.
> 
> I am slowly removing all parts of the in-kernel OSS with ALSA drivers 
> for the same hardware.

I have a motherboard with an intel chipset and onboard audio.  I have a
problem with alsa.  There's no pcm* files in /proc/asound/card0.

I tried quake on it which didn't work.  I remembered the problem with oss
use on alsa and tried to do the echo "..." as stated in the kernel docs only
to find out the path doesn't exist.  Here's what I see:

[wakko@gohan:/proc/asound/card0] ls -l
total 0
dr-xr-xr-x  2 root root 0 Jun 26 12:26 codec97#0/
-r--r--r--  1 root root 0 Jun 26 12:26 id
-r--r--r--  1 root root 0 Jun 26 12:26 intel8x0
-rw-r--r--  1 root root 0 Jun 26 12:26 oss_mixer
[wakko@gohan:/proc/asound/card0] lspci -vns 1f.5
0000:00:1f.5 0401: 8086:24c5 (rev 02)
        Subsystem: 414c:4730
        Flags: bus master, medium devsel, latency 0, IRQ 5
        I/O ports at e000 [size=256]
        I/O ports at e400 [size=64]
        Memory at e0581000 (32-bit, non-prefetchable) [size=512]
        Memory at e0582000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <available only to root>

[wakko@gohan:/proc/asound/card0] dmesg|tail -4
[  313.942182] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5
(level, low) -> IRQ 5
[  313.942229] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[  314.293944] intel8x0_measure_ac97_clock: measured 52586 usecs
[  314.294097] intel8x0: clocking to 48000
[wakko@gohan:/proc/asound/card0] uname -a
Linux gohan 2.6.21 #1 PREEMPT Sat Jun 23 23:36:48 EDT 2007 i686 GNU/Linux
[wakko@gohan:/proc/asound/card0] 

This is a BCM IN845GV board.

What is interesting is the same driver (kernel 2.6.20) and the same pciid
(except for subsystem) works fine on another machine.
[wakko@vegeta:/proc/asound/card0] ls -l
total 0
dr-xr-xr-x 2 root root 0 Jun 26 12:29 codec97#0/
-r--r--r-- 1 root root 0 Jun 26 12:29 id
-r--r--r-- 1 root root 0 Jun 26 12:29 intel8x0
-rw-r--r-- 1 root root 0 Jun 26 12:29 oss_mixer
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm0c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm0p/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm1c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm2c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm3c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm4p/
[wakko@vegeta:/proc/asound/card0] lspci -vns 1f.5
00:1f.5 0401: 8086:24c5 (rev 02)
        Subsystem: 15d9:4080
        Flags: bus master, medium devsel, latency 0, IRQ 24
        I/O ports at 2000 [size=256]
        I/O ports at 2400 [size=64]
        Memory at b0000c00 (32-bit, non-prefetchable) [size=512]
        Memory at b0000800 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

[wakko@vegeta:/proc/asound/card0] 

Dmsg for this driver:
[  110.504446] ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 24
[  110.504636] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[  110.818894] intel8x0_measure_ac97_clock: measured 52791 usecs
[  110.818949] intel8x0: clocking to 48000

This is a Supermicro X5DA8 board (This one works fine!).

I don't know what to do with the BCM board other than just use OSS drivers
which work just fine on this board.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Takashi Iwai]

At Tue, 26 Jun 2007 12:25:16 -0400,
Wakko Warner wrote:
> 
> Adrian Bunk wrote:
> > On Tue, Jun 26, 2007 at 12:18:05AM +0300, Hannu Savolainen wrote:
> > >...
> > > What we would like to push is that the old "deprecated" OSS/Free are 
> > > removed from the kernel. OSS/Free is based on about years old OSS API 
> > > version which was too limited for many applications. Having OSS/Free in the 
> > > kernel doesn't serve any purpose.
> > 
> > I am slowly removing all parts of the in-kernel OSS with ALSA drivers 
> > for the same hardware.
> 
> I have a motherboard with an intel chipset and onboard audio.  I have a
> problem with alsa.  There's no pcm* files in /proc/asound/card0.

Set CONFIG_SND_VERBOSE_PROCFS=y.


Takashi

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Wakko Warner]

Takashi Iwai wrote:
> At Tue, 26 Jun 2007 12:25:16 -0400,
> Wakko Warner wrote:
> > I have a motherboard with an intel chipset and onboard audio.  I have a
> > problem with alsa.  There's no pcm* files in /proc/asound/card0.
> 
> Set CONFIG_SND_VERBOSE_PROCFS=y.

GAH!  Thanks, I didn't think I needed it but it is set on the one that
works.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Nix]

On 25 Jun 2007, Adrian Bunk stated:
> If people often run into this problem it might make sense to deprecate 
> the in-kernel OSS emulation and point people to the userspace emulation 
> instead?

So now people need to know internal implementation details like if a
program uses ALSA or OSS interfaces before they know how to *run* it?

That doesn't sound especially nice to use (and before you say
`distributors will do it', not all programs are built by distributors).

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/28/2007 08:30 PM, Nix wrote:

> On 25 Jun 2007, Adrian Bunk stated:
>> If people often run into this problem it might make sense to deprecate 
>> the in-kernel OSS emulation and point people to the userspace emulation 
>> instead?
> 
> So now people need to know internal implementation details like if a
> program uses ALSA or OSS interfaces before they know how to *run* it?

Point, but one that does hinge on whether or not you feel you can call using 
the ALSA or OSS interface an implementation detail.

ALSA has been the Linux soundsystem for a number of years now and as such, 
an application that runs under Linux and produces sound more and more can be 
expected to do so using the Linux API. The only reason it _can_ be seen as a 
detail is due to the Just Works nature of the OSS emulation but that is 
changing due to the software mixing. Binary apps are also moving to ALSA 
currently, ie, flash, skype, ...

Anyways, I suspect at least Takashi Iwai would simply say "no" to removing 
or deprecating the in kernel emulation anyway, although it's not likely to 
grow features anymore.

Rene.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Lee Revell]

On 6/28/07, Rene Herman <rene.herman@gmail.com> wrote:
> ALSA has been the Linux soundsystem for a number of years now and as such,
> an application that runs under Linux and produces sound more and more can be
> expected to do so using the Linux API. The only reason it _can_ be seen as a
> detail is due to the Just Works nature of the OSS emulation but that is
> changing due to the software mixing. Binary apps are also moving to ALSA
> currently, ie, flash, skype, ...

If your disto ships with any OSS apps using the in-kernel emulation
you should file a bug report, as it results in bizarre and undesirable
behavior - a single app opening /dev/dsp will block audio for every
other app (OSS or ALSA) on the vast majority of hardware out there.

Lee

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Jeff Garzik]

Rene Herman wrote:
> Anyways, I suspect at least Takashi Iwai would simply say "no" to 
> removing or deprecating the in kernel emulation anyway, although it's 
> not likely to grow features anymore.


Even if he fails to say "no" in such a case, many other people would 
stand up and do so :)  In Linux we generally do not want to remove 
binary userspace interfaces.  Breaking (i.e. changing) the in-kernel API 
is fine, but breaking the userspace ABI is quite another matter.

	Jeff

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Adrian Bunk]

On Thu, Jun 28, 2007 at 04:20:45PM -0400, Lee Revell wrote:
> On 6/28/07, Rene Herman <rene.herman@gmail.com> wrote:
>> ALSA has been the Linux soundsystem for a number of years now and as such,
>> an application that runs under Linux and produces sound more and more can 
>> be
>> expected to do so using the Linux API. The only reason it _can_ be seen as 
>> a
>> detail is due to the Just Works nature of the OSS emulation but that is
>> changing due to the software mixing. Binary apps are also moving to ALSA
>> currently, ie, flash, skype, ...
>
> If your disto ships with any OSS apps using the in-kernel emulation
> you should file a bug report, as it results in bizarre and undesirable
> behavior - a single app opening /dev/dsp will block audio for every
> other app (OSS or ALSA) on the vast majority of hardware out there.

There's software like mplayer that supports both and tries OSS first...

> Lee

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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Adrian Bunk]

On Thu, Jun 28, 2007 at 07:30:36PM +0100, Nix wrote:
> On 25 Jun 2007, Adrian Bunk stated:
> > If people often run into this problem it might make sense to deprecate 
> > the in-kernel OSS emulation and point people to the userspace emulation 
> > instead?
> 
> So now people need to know internal implementation details like if a
> program uses ALSA or OSS interfaces before they know how to *run* it?
> 
> That doesn't sound especially nice to use (and before you say
> `distributors will do it', not all programs are built by distributors).

The interesting point is that what you call "internal implementation 
details" is much _more_ exposed with the OSS emulation in the kernel
_enabled_.

Why?

Linux software not supporting ALSA has becoming quite esoteric.

But software like mplayer supporting both and trying OSS first and 
software supporting both and letting the user choose is today much more 
common. And that's exactly the case where users run into the results of 
the "internal implementation detail" that their application used the 
in-kernel OSS emulation instead of ALSA resulting in exactly these 
problems.

There is also a userspace OSS emulation for ALSA not suffering from 
these problems.

It's not my decision whether or not to remove the in-kernel OSS emulation, 
all I'm saying is that removing it might actually result in less users 
having problems.

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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/28/2007 11:06 PM, Adrian Bunk wrote:

> The interesting point is that what you call "internal implementation 
> details" is much _more_ exposed with the OSS emulation in the kernel 
> _enabled_.
> 
> Why?
> 
> Linux software not supporting ALSA has becoming quite esoteric.
> 
> But software like mplayer supporting both and trying OSS first and 
> software supporting both and letting the user choose is today much more 
> common. And that's exactly the case where users run into the results of 
> the "internal implementation detail" that their application used the 
> in-kernel OSS emulation instead of ALSA resulting in exactly these 
> problems.
> 
> There is also a userspace OSS emulation for ALSA not suffering from these
> problems.
> 
> It's not my decision whether or not to remove the in-kernel OSS
> emulation, all I'm saying is that removing it might actually result in
> less users having problems.

For what it's worth -- I do agree with this...

Rene.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Nix]

On 28 Jun 2007, Adrian Bunk outgrape:
> Linux software not supporting ALSA has becoming quite esoteric.

Indeed. This is why I haven't moaned much (or at all): aoss is ugly,
sure, but you only need it for those rare apps which run for a long time
or while other sounds are playing, on non-mixing-capable hardware, for
which the in-kernel emulation won't suit... and most non-sound-
specialist apps are using esd, arts or pulseaudio anyway, so that does
the mixing for you (and pulseaudio also does it for every ALSA app if
the pulseaudio plugin is installed). And the sound-specialist apps
are the ones that actually *benefit* from ALSA's ludicrous degree of
low-levelness, so they're using it, or something even more flexible
like JACK.

I use quite a lot of sound apps, and I can count the number of times
I've had to use aoss in the last year on the fingers of one hand.


But still it's conceptually ugly. Doing stuff in userspace, yes: but the
kernel should be calling *back* to userspace to do it, not depending on
things being done in the client's address space by a client library for
proper function. (See also others' rants regarding the nasty
quasi-unstable nature of the ALSA ioctl() kernel interface...)

Isn't this sort of big user-to-and-from-kernelspace data-transfer job
what we have relayfs for? (Or is it unidirectional?)

> common. And that's exactly the case where users run into the results of 
> the "internal implementation detail" that their application used the 
> in-kernel OSS emulation instead of ALSA resulting in exactly these 
> problems.
>
> There is also a userspace OSS emulation for ALSA not suffering from 
> these problems.

The problem is that the user has to *know* to run `aoss'. The in-kernel
OSS emulation is actually nicer than thr userspace one because it works
automatically without the user having to do a damned thing. If only it
(and ALSA as a whole) called out to userspace again to mix, we could
presumably ditch aoss, and the user would never need to care which API
the author chose to use. (There are still complexities involving reading
the user's .asoundrc to consider, but most users don't use that so
wouldn't need aoss for anything anymore.)

And then all these damn silly ALSA/OSS flamewars could go away.

> It's not my decision whether or not to remove the in-kernel OSS emulation, 
> all I'm saying is that removing it might actually result in less users 
> having problems.

I think it would lead to *more* problems. The in-kernel emulation
*almost* Just Works, and surely the ideal we should aim for is an
emulation that Just Works.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Florian Schmidt]

On Thursday 28 June 2007, Adrian Bunk wrote:

> There is also a userspace OSS emulation for ALSA not suffering from
> these problems.

Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to 
intercept library calls that open the /dev/dsp devices etc.. This doesn't 
always work.

I suppose the best way to provide OSS emu is to use something like FUSD 
[similar to the OSS2JACK package] [1] to provide the OSS device files and 
then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD 
doesn't really get actively developed anymore it seems. And FUSE can't handle 
ioctls.

[1] http://www.circlemud.org/~jelson/software/fusd/

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Miklos Szeredi]

> I suppose the best way to provide OSS emu is to use something like
> FUSD [similar to the OSS2JACK package] [1] to provide the OSS device
> files and then redirect to user space, so all ALSA pcm devices can
> be used.. Sadly FUSD doesn't really get actively developed anymore
> it seems. And FUSE can't handle ioctls.

Not as if it would be hard to add ioctl support to fuse.  What fuse
can't handle is the data argument of ioctl(), so the most it could do
is give the filesystem a pid (tid) and a virtual address.  The
userspace fs could then get/put the data through /proc/<pid>/mem.

Miklos

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Alan Cox]

On Fri, 29 Jun 2007 16:56:05 +0200
Miklos Szeredi <miklos@szeredi.hu> wrote:
> Not as if it would be hard to add ioctl support to fuse.  What fuse
> can't handle is the data argument of ioctl(), so the most it could do
> is give the filesystem a pid (tid) and a virtual address.  The
> userspace fs could then get/put the data through /proc/<pid>/mem.

Hork...

Identify the generic ioctls that are relevant to a FUSE file system and
have real meaning *and* are useful. Teach fuse to turn those to and from
messages properly and if you must add any others (ie if there is good
reason to want them then add a single FUSEFS ioctl something like

	struct fusefs_ioctl {
		u32 opcode;
		void *data_in;
		void *data_out;
		u16 size_in;
		u16 size_out;
	}

so that anything totally weird can be passed through without
horrible /proc/... hacks and without putting tons of cases into FUSE

		

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Miklos Szeredi]

> Miklos Szeredi <miklos@szeredi.hu> wrote:
> > Not as if it would be hard to add ioctl support to fuse.  What fuse
> > can't handle is the data argument of ioctl(), so the most it could do
> > is give the filesystem a pid (tid) and a virtual address.  The
> > userspace fs could then get/put the data through /proc/<pid>/mem.
> 
> Hork...
> 
> Identify the generic ioctls that are relevant to a FUSE file system and
> have real meaning *and* are useful.

I don't think there are any such.

The point in this thread was I think about emulating an OSS sound
device through a fuse fs.  In that case fuse would need _generic_
ioctl support, which simply can't be done without weird userspace
hacks.  I'm definitely not adding specific ioctls to fuse.

Miklos

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Miklos Szeredi]

> > > Not as if it would be hard to add ioctl support to fuse.  What fuse
> > > can't handle is the data argument of ioctl(), so the most it could do
> > > is give the filesystem a pid (tid) and a virtual address.  The
> > > userspace fs could then get/put the data through /proc/<pid>/mem.
> > 
> > Hork...
> > 
> > Identify the generic ioctls that are relevant to a FUSE file system and
> > have real meaning *and* are useful.
> 
> I don't think there are any such.
> 
> The point in this thread was I think about emulating an OSS sound
> device through a fuse fs.  In that case fuse would need _generic_
> ioctl support, which simply can't be done without weird userspace
> hacks.

Well, had a look at what FUSD does.  It assumes that the ioctl
argument is stuctured according to the command.  If all OSS ioctls are
like that, then fine, fuse can support it properly.

The drawback of this is that ioctls which aren't structured properly
could cause weird failures due to wrong data being accessed by the
poor unknowing kernel.

Miklos

OSS vs ALSA API (was Re: Is it time for remove (crap) ALSA from kernel tree ?)

[Pavel Machek]

Hi!

> >Today both OSS and ALSA teams have to spend significant 
> >amounts of time in emulating the "alien" APIs. Making 
> >OSS and ALSA to co-exist will require some work in both 
> >sides but that should be nothing when compared to the 
> >effort required for emulation.
> 
...
> In Linux we typically do not do two APIs and codebases 
> for the same purpose.  If we do, like sys_mmap and 
> sys_mmap2, it's an older legacy interface that never 
> changes, that we are moving people AWAY from, and a 
> newer interface.
> 
> I see no reason to change from the path at which 
> upstream has arrived: OSS is a legacy API that's frozen 
> in time, and ALSA provides the new stuff.

While I agree that ALSA is better than OSS... I don't actually think
ALSA kernel<>user api is... at least for my purposes. I'm still using
OSS emulation, because I could not get alsa proper to work... and the
advanced stuff just does not work in emulation.

In OSS days, if you wanted to test kernel sound driver, you did:

mknod /dev/dsp
cat /bin/bash > /dev/dsp.

With alsa+oss emulation, you need

mknod /dev/mixer
install aumix
aumix
mknod /dev/dsp
cat /bin/bash > /dev/dsp.

With alsa proper, it is

install alsalib
create about 5 device nodes
install alsautils
maybe do some config?
aplay some.wav

..provided you have .wav near you. I'm not sure if it is possible to
produce sounds using normal shell scripting? (w/o alsautils)?

I can even test kernel graphics drivers by cat /bin/bash > /dev/fb0...
it would be nice to have equivalent for audio... OSS API seems to be
the equivalent these days, but please don't deprecate it.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Pavel Machek]

Hi!
> > 
> > Soft mixing is actually the biggest issue because if you had
> > generalized soft-mixing in the kernel-visible audio ports[1] you would
> > win two things:
> > 
> > - programs could use the OSS API without interfering with the ALSA one
> >   or which each other
> 
> This works with aoss.
> 
> If people often run into this problem it might make sense to deprecate 
> the in-kernel OSS emulation and point people to the userspace emulation 
> instead?

Without in-kernel OSS emulation, it is very hard to verify if kernel
sound support works properly. OSS could been driven from shell for
testing, and I believe that's still important feature to keep.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Florian Schmidt]

On Friday 29 June 2007, Miklos Szeredi wrote:
> > > > Not as if it would be hard to add ioctl support to fuse.  What fuse
> > > > can't handle is the data argument of ioctl(), so the most it could do
> > > > is give the filesystem a pid (tid) and a virtual address.  The
> > > > userspace fs could then get/put the data through /proc/<pid>/mem.
> > >
> > > Hork...
> > >
> > > Identify the generic ioctls that are relevant to a FUSE file system and
> > > have real meaning *and* are useful.
> >
> > I don't think there are any such.
> >
> > The point in this thread was I think about emulating an OSS sound
> > device through a fuse fs.  In that case fuse would need _generic_
> > ioctl support, which simply can't be done without weird userspace
> > hacks.
>
> Well, had a look at what FUSD does.  It assumes that the ioctl
> argument is stuctured according to the command.  If all OSS ioctls are
> like that, then fine, fuse can support it properly.
>
> The drawback of this is that ioctls which aren't structured properly
> could cause weird failures due to wrong data being accessed by the
> poor unknowing kernel.
>
> Miklos

Included with the docs there's a list of the OSS ioctls. I don't understand 
enough of the problem to judge whether they are suitable to be handled by 
FUSE:

http://manuals.opensound.com/developer/ioctl.html [version 4]
http://www.4front-tech.com/pguide/oss.pdf [version 3]

I don't know which API version is supposed to be supported though.

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Miklos Szeredi]

> > Well, had a look at what FUSD does.  It assumes that the ioctl
> > argument is stuctured according to the command.  If all OSS ioctls are
> > like that, then fine, fuse can support it properly.
> >
> > The drawback of this is that ioctls which aren't structured properly
> > could cause weird failures due to wrong data being accessed by the
> > poor unknowing kernel.
> 
> Included with the docs there's a list of the OSS ioctls. I don't understand 
> enough of the problem to judge whether they are suitable to be handled by 
> FUSE:
> 
> http://manuals.opensound.com/developer/ioctl.html [version 4]
> http://www.4front-tech.com/pguide/oss.pdf [version 3]
> 
> I don't know which API version is supposed to be supported though.

Thanks, but these docs are about what the ioctls do, and I'm totally
uninterested in that.  What I'm interested is how the ioctl data is
_structured_.

OK, had a look at <linux/soundcard.h>, it does define a data
structuring based on the ioctl numbers, and it's just slightly
different from the structuring defined by <asm-generic/ioctl.h>.  Oh,
the beauty of the ioctls.

So answering my own question: no, it's not sanely possible to support
ioctls through fuse without userspace hacks or significant effort.

A possibly acceptable option is to add a plugin mechanism, whereby
people could write small ioctl interpreter kernel modules for their
specific needs (such as parsing OSS ioctls), which would
serialize/deserialize any type of ioctl input/output making them
suitable for transfering between the kernel and the userspace
filesystem.

Another, much more complex option is to design a generic ioctl data
interpreter language, and let the filesystem upload their ioctl
parsers into the kernel.

Miklos

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Darren]

Tomasz Kłoczko wrote:
>
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and 
> GLPv2 for Linux:
>
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
>
> So this source without problems code can be integragrated in Linus 
> tree and after this Linux can provide much better soud supoport than 
> with current ALSA.
>
> Any plans for doing this ?
>
> kloczek

I know this may sound kind of stupid, but how about not deprecating 
either, and fully supporting both sound systems? Maybe we can get them 
to work together, and the distro or user can choose whether they would 
like to use alsa or oss for that particular card (or have the distro 
choose the sound drivers that are best supported for that particular 
card). As it is now, most apps already support oss and alsa.

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Adrian Bunk]

On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>
> I know this may sound kind of stupid, but how about not deprecating either, 
> and fully supporting both sound systems? Maybe we can get them to work 
> together, and the distro or user can choose whether they would like to use 
> alsa or oss for that particular card (or have the distro choose the sound 
> drivers that are best supported for that particular card). As it is now, 
> most apps already support oss and alsa.

It does not sound stupid and sounds good at first sight.

But there are problems we've already seen with similar situations in 
different parts of the kernel:

They would have different hardware support, features and bugs.

And then a user user whose sound card is only supported by sound system A
needs a feature only available in sound system B.

And the quality decreases since people will often not report bugs in 
sound system A if sound system B works for them.

OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's 
mostly a difference for application developers. And since (as you say) 
most applications already support both, there's no compelling reason for 
providing more than one of them.

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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2599 bytes --]

On Wed, 4 Jul 2007, Adrian Bunk wrote:

> On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>>
>> I know this may sound kind of stupid, but how about not deprecating either,
>> and fully supporting both sound systems? Maybe we can get them to work
>> together, and the distro or user can choose whether they would like to use
>> alsa or oss for that particular card (or have the distro choose the sound
>> drivers that are best supported for that particular card). As it is now,
>> most apps already support oss and alsa.
>
> It does not sound stupid and sounds good at first sight.
>
> But there are problems we've already seen with similar situations in
> different parts of the kernel:
>
> They would have different hardware support, features and bugs.
>
> And then a user user whose sound card is only supported by sound system A
> needs a feature only available in sound system B.
>
> And the quality decreases since people will often not report bugs in
> sound system A if sound system B works for them.
>
> OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
> mostly a difference for application developers. And since (as you say)
> most applications already support both, there's no compelling reason for
> providing more than one of them.

>From Hannu message:
"I think the ideal solution would be that both ALSA and OSS APIs can 
co-exist by sharing the same low level drivers (which has
already been demonstrated). The low level driver interfaces in both 
systems are practically identical. This means that ALSA's
core can work with OSS' drivers and vice versa."

So Hannu have plan for share ALSA low level drivers without changes 
(porting to OSS will not be neccessary and/or will need only small 
amount of time .. IMO much less than make ALSA fully functional).
Main diffrences between ALSA and OSS are above low level drivers so IMO it 
is completly possible have ALSA and OSS in the same tree.
OSS wtil not dies (and try resurect) ALSA still (after few years) was not 
born and still isn't rock solid point odf Linux desktop (IMO it is most 
weeknes ponit of LD). IMO it will be better if Hannu will start pushing 
any OSS chages to Linus tree. Current OSS code in Linus tree is more or 
less not useable so allow maintain this code in main tree can't hurd 
anything outside this area.

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*