Mailing List Archive

kloczek,
The fact that it is now open source does mean that it's a suitable replacement.

If you actually want a productive discussion, you'd be better off making an
attempt at describing exactly _why_ ALSA is 'crap' and how in your opinion OSS
overcomes ALSA's shortfalls.

IMHO, it would be far more realistic and managable to look at the OSS codebase
and use it to make improvements to ALSA. I'm looking into one or two issues
myself and I've mentioned looking at the OSS code for possible improvements on
the alsa-devel list. I think it's generally agreed that OSS can't do much at all
that ALSA doesn't already do. Sure, if you've been smoking crack, you might want
to rip out ALSA and replace it with OSS to gain some minor functionality but
you'd also lose functionality in the process.

Unless you can describe how the actual architecture of ALSA is inferior and not
just complain about some particular device not being fully supported, the best
idea is clearly to port any lacking functionality from OSS -> ALSA. In the case
that you can actually provide valid reasons for ALSA's inferiority, I shall
respectfully eat my hat :)

Either way, have bug reports been filed for areas of ALSA that you are unhappy
with?

Ash

--
Get a Free E-mail Account at Mail.com!
Choose From 100+ Personalized Domains
Visit http://www.mail.com today

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sun, 24 Jun 2007, Ash Willis wrote:

> kloczek,
> The fact that it is now open source does mean that it's a suitable replacement.
>
> If you actually want a productive discussion, you'd be better off making an
> attempt at describing exactly _why_ ALSA is 'crap' and how in your opinion OSS
> overcomes ALSA's shortfalls.

I'm asking .. and axpecting (only) answesr on my question.

*Each* day I have problems with ALSA support and I know some fundamental
ALSA misdevelopments and few times it was by me (and not only by me)
presented on lk-ml (try look on lk-ml archive) .. so .. sory but I'm not
interested on discuss about ALSA v. OSS :> (if you want disccuss about
this please prepare for this and read anything about subject .. before).

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*

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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*

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
--

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.

If you are the one advocating using OSS, it's up to you to explain why
it's better using technical arguments, which you haven't done. I rather
doubt it is possible to do so convincingly.

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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*

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*

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
--

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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*

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*