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: [email protected]*
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
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: [email protected]*
On Sun, 24 Jun 2007 19:51:38 +0200 (CEST)
Tomasz Kłoczko <[email protected]> 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
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: [email protected]*
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 [email protected]
Home Page: http://www.roberthancock.com/
> 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
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.
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.
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 <[email protected]>
On 25/06/07, Carlo Wood <[email protected]> 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 <[email protected]>
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
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 <[email protected]>
> 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.
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
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
> 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.
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: [email protected]*
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: [email protected]*
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
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
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
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: [email protected]*
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: [email protected]*
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
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
--
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.
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.
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
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
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
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
---------------------------------------------------------
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
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.
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
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: [email protected]*
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.
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: [email protected]*
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
---------------------------------------------------------
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
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: [email protected]*
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 http://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: [email protected]*
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
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
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
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
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.
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
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
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
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
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???
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
> >
> > 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.
Okay, here's a rant.
As an interested kernel outsider and KDE developer(*), it looks to me like
most kernel people are too focused on the history and feature lists of the
particular technologies here.
The real matter with ALSA is that you get a strong "ALSA hates me" feeling
when dealing with it. There is bad documentation, bad API, and a config file
syntax that is much harder to understand than necessary.
Then there is the kernel/library split that seems to have no convincing reason
at all in its current form.
Why not put the whole sound system in userland? It has been done before. Sound
is just not performance critical at all and it's almost never mission
critical.
Plus you wouldn't have to cross the userland/kernel gap to implement new and
exciting things that way. Audio is kinda simple on the IO level (I hope I'm
right there :) ) and, ideally, on the userland API level. These places are
exactly where well-defined interfaces should be. An appropriate IO interface
and userland API should be set in stone, not something arbitrary in between.
Hell, there could even be a source compatible sound driver standard for all
Unix-like free OS kernels.
The track record of ALSA for me goes like this:
- dmix finally started working automatically (at least on my Kubuntu system)
about one year ago, about five years after everybody could see that this was
badly needed. I couldn't get it to work before. The howtos somehow didn't
work and ALSA's documentation isn't all that helpful.
- Different desktop environments have different sound daemons to paper over
the weaknesses of ALSA (no dmix by default / unfriendly API), which creates
new problems. Yes there are other reasons for sound daemons, but I doubt
anybody would have come up with the idea if it wasn't for ALSA.
- I have an Envy24HT based soundcard in my desktop PC, which also goes to show
that I'm really interested in sound issues. I have to run alsamixer after
every bootup to unmute the left channel because restoring volume only works
for the right channel. The left channel starts working after changing its
volume.
- On my IBM/Lenovo R50e notebook with Intel chipset sound didn't work before
I "muted" the "headphone jack sense" control in alsamixer. That took two
hours or so. When both the master volume and the PCM volume control are set
to 100% I get really bad clipping problems.
- Some time ago ALSA reported that my soundcard supports sampling rates it
doesn't in fact support. This was fixed by Takashi Iwai after a week and two
mails or so. Thumbs up.
Regards,
Andreas
(*) I am not representing KDE in an official way at all, but I can say that
KDE developers generally put *much* effort into making APIs as logical and
friendly as they possibly can.
Andreas Hartmetz <[email protected]> writes:
> The track record of ALSA for me goes like this:
>
> - dmix finally started working automatically (at least on my Kubuntu system)
> about one year ago, about five years after everybody could see that this was
> badly needed. I couldn't get it to work before. The howtos somehow didn't
> work and ALSA's documentation isn't all that helpful.
I don't remember when it happened, but I do remember that I suddenly
had to manually disable dmix to stop it messing around with my sound.
I don't need it, and I certainly don't like libraries doing random IPC
behind my back.
> - Different desktop environments have different sound daemons to
> paper over the weaknesses of ALSA (no dmix by default / unfriendly
> API), which creates new problems. Yes there are other reasons for
> sound daemons, but I doubt anybody would have come up with the idea
> if it wasn't for ALSA.
Those sound daemons were around long before ALSA was even conceived.
> - I have an Envy24HT based soundcard in my desktop PC, which also
> goes to show that I'm really interested in sound issues. I have to
> run alsamixer after every bootup to unmute the left channel because
> restoring volume only works for the right channel. The left channel
> starts working after changing its volume.
That sounds like a minor glitch that should be easily remedied if you
file a proper bug report. Have you tried?
> - On my IBM/Lenovo R50e notebook with Intel chipset sound didn't
> work before I "muted" the "headphone jack sense" control in
> alsamixer. That took two hours or so. When both the master volume
> and the PCM volume control are set to 100% I get really bad clipping
> problems.
Shoddy hardware. Don't blame the drivers for that.
> - Some time ago ALSA reported that my soundcard supports sampling
> rates it doesn't in fact support. This was fixed by Takashi Iwai
> after a week and two mails or so. Thumbs up.
Yes, API and configuration file syntax aside, the ALSA developers are
always friendly and responsive.
> (*) I am not representing KDE in an official way at all, but I can
> say that KDE developers generally put *much* effort into making APIs
> as logical and friendly as they possibly can.
I've still not, after all these years, managed to figure out what KDE
(or Gnome) is supposed to be good for. I'm not missing anything from
my window manager, xterm and xemacs setup.
--
M?ns Rullg?rd
[email protected]
On 06/26/2007 10:39 PM, Andreas Hartmetz wrote:
> Okay, here's a rant.
>
> As an interested kernel outsider and KDE developer(*), it looks to me
> like most kernel people are too focused on the history and feature lists
> of the particular technologies here.
>
> The real matter with ALSA is that you get a strong "ALSA hates me"
> feeling when dealing with it. There is bad documentation, bad API, and a
> config file syntax that is much harder to understand than necessary.
I'll agree to the documentation bit; the funny thing is that it's partly
caused by documentation actually being, or once having been, _better_ than
it is for the average subsystem. ALSA for example has the useful "Writing an
ALSA Driver" document from Takashi Iwai:
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html
Documentation becomes obsolete as code progresses though and yes, especially
on the userside of things the documentation is slow to follow. And then the
usual problem of noone ever removing obsolete junk from the web exacerbates
matters. Google will find you tons of useless, outdated crap but if you need
the information in the first place, you don't know that it _is_ obsolete.
And yes, this unfortunately includes http://www.alsa-project.org. For the longest
time it was advocating writing ~/.asoundrc files for example through generic
driver boilerplate texts while that was actually at that point mostly
counter productive in getting ALSA functional.
As to the config file -- well, sure. The best thing about is that normally
you don't need it...
The "bad API" I find interesting since you are a KDE developer. I'm not an
audio application developer myself so I don't have (m)any well thought out
opinions on it, but isn't the only thing in KDE4 that talks to ALSA the
Phonon ALSA backend? If you are talking in that context, I'm quite sure the
alsa-user and/or alsa-devel lists (@alsa-project.org) would like to hear
about any specific comments/problems. Getting the Phonon backend right from
the start is something that seems important.
> Then there is the kernel/library split that seems to have no convincing
> reason at all in its current form. Why not put the whole sound system in
> userland? It has been done before. Sound is just not performance critical
> at all and it's almost never mission critical
Heh. Sound may not be, but audio is. For the longest time, audio users stuck
with 2.4 kernels and the low-latency patches that were availabe for it due
to latency issues. Large parts of ALSA already are in userland in the form
of libasound and I expect moving over everything would not so much help.
[ ... ]
> The track record of ALSA for me goes like this:
>
> - dmix finally started working automatically (at least on my Kubuntu
> system) about one year ago, about five years after everybody could see
> that this was badly needed. I couldn't get it to work before. The howtos
> somehow didn't work and ALSA's documentation isn't all that helpful.
dmix was really only implemented (or at least, made default) for casual
users. Hope it'll not come across as elitist but people who are serious
about music or audio don't actually need or want it. It's a consumer thing.
To have software mixing work you have to resample to a common rate and this
an absolute unthinkable horror to a serious user. It's a good thing it's now
default, but only because a majority of sound users is not serious (simply
because it's mostly all computer users).
> - Different desktop environments have different sound daemons to paper
> over the weaknesses of ALSA (no dmix by default / unfriendly API), which
> creates new problems. Yes there are other reasons for sound daemons, but
> I doubt anybody would have come up with the idea if it wasn't for ALSA.
Given that they existed before ALSA did this seems to be a somewhat odd doubt.
> - I have an Envy24HT based soundcard in my desktop PC, which also goes to show
> that I'm really interested in sound issues.
Nice chip. I don't have one, and am not too sure about its native supported
rates but if you are mostly playing 44100 through it (ie, CD source audio)
I'd consider doing without dmix. A nice sounding chip like that shouldn't be
subjected to resampling really. Someone recently informed me on the ALSA
list that Envy24 indeed doesn't do hardware mixing though, so I guess you
may need it if you really do want the also have the card available for
desktop sounds.
> I have to run alsamixer after every bootup to unmute the left channel
> because restoring volume only works for the right channel. The left
> channel starts working after changing its volume.
Sounds like a rather debugable problem. I'm (almost) sure someone will try
to get you a useful answer if you post to the [email protected]
list :)
> - On my IBM/Lenovo R50e notebook with Intel chipset sound didn't work
> before I "muted" the "headphone jack sense" control in alsamixer. That
> took two hours or so. When both the master volume and the PCM volume
> control are set to 100% I get really bad clipping problems.
First problem I don't know about but is no doubt related to alsa developers
not having proper documentation. On lots of hardware, there's many bits to
flip, with no information from the manufacturer forthcoming. You can't hold
that against ALSA so much.
As to the second bit -- most cards mame any audio that passes through them
when you set a volume to above 0 dB. dB scales were recently implemented for
many drivers. If also for yours, I expect 100% is more than 0 dB?
> - Some time ago ALSA reported that my soundcard supports sampling rates
> it doesn't in fact support. This was fixed by Takashi Iwai after a week
> and two mails or so. Thumbs up.
Yes, Takashi Iwai is very responsive.
> (*) I am not representing KDE in an official way at all, but I can say
> that KDE developers generally put *much* effort into making APIs as
> logical and friendly as they possibly can.
Not so much that I'm likely to be of great help myself, not being an audio
application developer, but if there's any problem's with the new KDE4 stuff
in relation to ALSA, I hope you or someone else will bring them up on the
alsa list(s)...
Rene.
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???
> > The track record of ALSA for me goes like this:
> > - dmix finally started working automatically (at least on my Kubuntu
> > system) about one year ago, about five years after everybody could see
> > that this was badly needed.
>
> I don't remember when it happened, but I do remember that I suddenly
> had to manually disable dmix to stop it messing around with my sound.
> I don't need it, and I certainly don't like libraries doing random IPC
> behind my back.
>
I don't like random applications blocking my sound card.
Joe user wants to play sound, and he couldn't care less about "random IPC" or
what-fucking-ever.
Dmix using the low quality sampling rate converter by default was another bad
decision.
You are concerned about your precious audio quality? Me too. Most people,
however, are using god-awful plastic speakers for twenty euros and shitty
onboard sound chips. Sad but true.
> > - Different desktop environments have different sound daemons to
> > paper over the weaknesses of ALSA (no dmix by default / unfriendly
> > API), which creates new problems. Yes there are other reasons for
> > sound daemons, but I doubt anybody would have come up with the idea
> > if it wasn't for ALSA.
>
> Those sound daemons were around long before ALSA was even conceived.
>
ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of
technology) was released in october 2000.
Linux 2.6.0 seems to have appeared in 2003, so you are right for realistic
values of "being around".
> That sounds like a minor glitch that should be easily remedied if you
> file a proper bug report. Have you tried?
>
No, I kinda gave up on ALSA after reading its API (rather "functions
that happen to be exported") documentation and kinda hoped it would go away
ASAP.
[long rant on ALSA's developer "friendliness"]
If you want to see an example try this one:
http://www.alsa-project.org/alsa-doc/alsa-lib/hcontrol.html
or this one
http://www.alsa-project.org/alsa-doc/alsa-lib/group___h_control.html#g881a1bbb1e95b7bcadc5c2a88124c3d1
and now program against it! Having fun already?
Observe how "HCTL"s seem to be used everywhere, and the documentation is
"typedef struct _snd_hctl_elem snd_hctl_elem_t : HCTL element handle". Wow.
the struct looks like this:
struct _snd_hctl_elem {
snd_ctl_elem_id_t id; /* must be always on top */
struct list_head list; /* links for list of all helems */
int compare_weight; /* compare weight (reversed) */
/* event callback */
snd_hctl_elem_callback_t callback;
void *callback_private;
/* links */
snd_hctl_t *hctl; /* associated handle */
};
Notice how compare_weight should probably be called comparison_weight or
priority, or relative_priority, or rel_priority or (...). The comment is
worse than no comment. The author couldn't be bothered to use a dictionary? I
think he wanted to tell us whether higher priorities have higher or lower
numbers, but I still don't know which.
callback_private should be callback_opaque. The construct has always been
called opaque pointer. If it was private it wasn't in this struct.
What about "must be always on top"??? Is it trying to tell us that you should
not randomize the struct layout?
Bonus points for using abbrvns ("helems") in cmts, thy r mch mr nformtv tht
wy.
There are two other structs of the same quality in the same header file
alsa-lib/control/control_local.h.
(control_local? As opposed to... remote? With a different interface or what?
It doesn't make any sense.)
This mess probably couldn't have survived a real review by the kernel
community.
For comparison, a comment taken from KDE's Phonon, copyright Matthias Kretz:
/**
* This signal is emitted whenever the volume has changed. As the
* volume can change without a call to setVolume (calls over dbus)
* this is important
* to keep a widget showing the current volume up to date.
*/
void volumeChanged(qreal newVolume);
Spot the difference?
Kernel or user space, again:
Put everything in kernel OR userspace but not both. Either is OK, but the
arguably more "modern" approach is userspace for error resilience and easy
hacking (i.e. more features faster). Latency is an issue? - Well you can't
play sound without userspace creating it so you're not adding any new
problems.
Kernel only would have the advantage of being able to present "everything as a
file" which is a good tradition. And no IPC.
ALSA took the disadvantages of both approaches and added the disadvantage of
having to get two chunks of code to get it working. It takes a twisted mind
to have two obvious right options and pick the third, obscure, and wrong
option. So sampling rate conversion is hard ("too dangerous for the kernel"),
boo hoo. It sure isn't more difficult to get right than a filesystem. Deal
with it.
History of ALSA:
I examined the lkml archive 1999 to 2002 a bit. There was much talk about
using all the DSP, bass boost, and other sundry hardware capabilities of
cards just appearing at the time. The focus was on adding support for
everything which
a) didn't happen (DSPs almost never get used to their full potential, I think)
b) somehow became uninteresting over the years. I don't want to "enhance" my
sound with cheap DSP effects, I'll take a good stereo, thank you very much.
c) is only relevant for games because you don't want to use any effect off
your card in professional audio applications
d) is plain stupid if you don't know what exactly you are going to need
beforehand.
Sorry for the long rant - I've regularly gotten worked up about ALSA in the
last few years whenever I got in touch with it. Mostly as a user and once as
a potential client developer, but I was disgusted and turned away.
> > - On my IBM/Lenovo R50e notebook with Intel chipset sound didn't
> > work before I "muted" the "headphone jack sense" control in
> > alsamixer. That took two hours or so. When both the master volume
> > and the PCM volume control are set to 100% I get really bad clipping
> > problems.
>
> Shoddy hardware. Don't blame the drivers for that.
>
Random quote from the internet: "It all sounds perfectly reasonable until you
have to explain to your granny why her PC sounded like shit over the last
couple of months."
This can be fixed in the driver. It's called a quirk.
> Yes, API and configuration file syntax aside, the ALSA developers are
> always friendly and responsive.
>
Yes. It just seems like nobody feels in charge to revisit the big picture
issues where things really went wrong.
The last signals from Jaroslav Kysela I found on the net look like he is
convinced of having created a great architecture, especially for professional
audio applications(*). He is employed by Novell like Takashi, apparently,
which won't make Takashi feel too adventurous, right? My guess is that
Jaroslav is (officially or not) assigned to everything but drivers, and he is
just not doing anything ALSA at all.
Meanwhile, ALSA continues to be crap and annoy people.
(*) ALSA is not lacking in raw capability, to be sure.
> > (*) I am not representing KDE in an official way at all, but I can
> > say that KDE developers generally put *much* effort into making APIs
> > as logical and friendly as they possibly can.
>
> I've still not, after all these years, managed to figure out what KDE
> (or Gnome) is supposed to be good for. I'm not missing anything from
> my window manager, xterm and xemacs setup.
Maybe you could try a recent KDE or show me the command-line equivalents of
Amarok or KPDF or Gwenview :)
On 06/27/2007 06:25 PM, Andreas Hartmetz wrote:
> I don't like random applications blocking my sound card.
So don't use random applications.
> You are concerned about your precious audio quality? Me too. Most people,
> however, are using god-awful plastic speakers for twenty euros and shitty
> onboard sound chips. Sad but true.
Exactly, which is why mixing has been default for some time now for most
cards. Are you only ranting about how it should've been earlier?
> ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of
> technology) was released in october 2000.
http://www.arts-project.org/gen/newsarchive/news_1998.html
>> That sounds like a minor glitch that should be easily remedied if you
>> file a proper bug report. Have you tried?
>>
> No, I kinda gave up on ALSA after reading its API (rather "functions
> that happen to be exported") documentation and kinda hoped it would go away
> ASAP.
You give up reporting small hardware problems that bother you because the
application developer documentation for something is not in great shape?
What an odd thing to do. And what a shame that this thread apparently was
unable to outlive it's originator troll and turn useful...
[ ... ]
> hacking (i.e. more features faster). Latency is an issue? - Well you can't
> play sound without userspace creating it so you're not adding any new
> problems.
Capture.
Rene.
> > I don't like random applications blocking my sound card.
>
> So don't use random applications.
>
I imitated the style of the mail I replied to. Besides, choosing apps based on
sound system is retarded if you wanted to indicate that this should be done
more often or something.
> > You are concerned about your precious audio quality? Me too. Most people,
> > however, are using god-awful plastic speakers for twenty euros and shitty
> > onboard sound chips. Sad but true.
>
> Exactly, which is why mixing has been default for some time now for most
> cards. Are you only ranting about how it should've been earlier?
>
Exactly! And the config file is hostile if you want to change it.
> > ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of
> > technology) was released in october 2000.
>
> http://www.arts-project.org/gen/newsarchive/news_1998.html
>
KDE 2 *was* released in 2000. Why would you care, I already admitted that
sound daemons were there before ALSA.
> >> ?That sounds like a minor glitch that should be easily remedied if you
> >> ?file a proper bug report. Have you tried?
> >
> > No, I kinda gave up on ALSA after reading its API (rather "functions
> > that happen to be exported") documentation and kinda hoped it would go
> > away ASAP.
>
> You give up reporting small hardware problems that bother you because the
> application developer documentation for something is not in great shape?
Yep, because I was frustrated with the whole thing. Having huge bad APIs with
no documentation is telling your fellow developers to piss off and do
something else. I did.
It's not like a little oversight to be quickly forgotten. ALSA has been there
for at least *five years* without documentation for most parts.
> > hacking (i.e. more features faster). Latency is an issue? - Well you
> > can't play sound without userspace creating it so you're not adding any
> > new problems.
>
> Capture.
>
If you are not doing DMA from the sound card to kernel memory and then
directly to disk blocks, you are using user space apps period. So what's
different with capture?
> Rene.
On 06/27/2007 09:10 PM, Andreas Hartmetz wrote:
>>> I don't like random applications blocking my sound card.
>>
>> So don't use random applications.
>>
> I imitated the style of the mail I replied to. Besides, choosing apps
> based on sound system is retarded if you wanted to indicate that this
> should be done more often or something.
What I indicated was that if someone wants to use multiple applications that
work together bringing you The One Integrated Sound Experience it might make
sense to use applications... that work together. Don't go blame ALSA for
either the fact that aRTs isn't actually useful nor KDE's decision to stick
with it for way too long. See -- the problem is again not ALSA (or OSS for
that matter) but userspace not getting its act together.
KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing by
default for some time now so we're talking history anyway. You want mixing
on your card? You got it.
Many don't -- they might not care about desktop sounds period and/or they
might use a clumsy chip/card for that and use a nice one for music without
any need for mixing on it (such as I do). Admittedly, mixing Abba's Dancing
Queen with Slayer's Angel of Death is great fun for quite a while but at
some point you do actually grow weary of it...
> Exactly! And the config file is hostile if you want to change it.
It could be a bit nicer yes. Since software mixing is enabled by default now
no configuration is generally needed though and it seems not a particularly
huge priority. Now that it's an advanced feature, maybe the flexibility pays
off in fact -- not sure, I don't use any configuration myself other than for
some testing and playing around every once in a while.
> KDE 2 *was* released in 2000. Why would you care, I already admitted that
> sound daemons were there before ALSA.
Because blaming ALSA for bad decisions made by others seems a little off and
you did exactly that a few messages back. Not nice!
>> You give up reporting small hardware problems that bother you because the
>> application developer documentation for something is not in great shape?
>
> Yep, because I was frustrated with the whole thing. Having huge bad APIs
> with no documentation is telling your fellow developers to piss off and
> do something else. I did.
You weren't having a developer problem but a user problem. Your problem was
not with the API documentation but with what would appear to be a simple
glitch in one particular driver. Mixing that in with a "ALSA sucks because
its documentation isn't upto par" is a little disingenious.
Sure the (library) documentation blows donkeys. So wat else's is new in the
land of Linux? I recently did a block-ish driver. Documentation? Whahahaha!
So that leaves that "bad" that you prefixed API with but keep in mind that
ALSA is designed as an audio system suitable for advanced/professional use
while also still filling the needs of consumer users and that it does in
fact do so is obvious from the fact that everyone's using it. A complex API
is the downside of flexibility. Perhaps it would've been better if alsa-lib
had also made a very simple API available to non-demanding users from the
start but other software can do that as well.
For my current purposes libao does, but I hope in the future something like
Phonon does. The ideal situation is that anyone in userspace is using a
single API _such_ as Phonon since userspace has to synchronise things itself
as well -- it might for example want to provide you with the option to
automatically mute your music when you get an incoming call and this is not
something which alsa-lib can do by itself.
If it looks like I'm shifting blame -- you bet I am. It's userspace which
has for years failed to get its multimedia act together, with KDE and GNOME
going out of their way to pick other infrastructure than the other one. The
kernel is not a guilty party and improvements should be sought where the
problems lie.
As said earlier, KDE4 might just be such an improvement. Personally I'm
hoping I'll even manage to start running it this time because damnit, I miss
solitaire...
>>> hacking (i.e. more features faster). Latency is an issue? - Well you
>>> can't play sound without userspace creating it so you're not adding any
>>> new problems.
>>
>> Capture.
>>
> If you are not doing DMA from the sound card to kernel memory and then
> directly to disk blocks, you are using user space apps period. So what's
> different with capture?
The latency in this case is defined as the time between data arriving at the
machine from the outside and it being available for further processing by an
application. Think looping stuff out again in realtime after doing something
to it to see why you want it to be low. If you'll grant that all those users
who were dissatisfied with early 2.6 weren't just blowing smoke, I assume
you'll grant that latency matters and that putting it all in userspace is
not an obvious step in minimising it -- even interrupt latency matters.
Note also it's certainly not (just) PCM but also very much MIDI. A musician
hitting a key on a keyboard needs to hear the sound he's making, processed,
recorded, stretched, whatever the computer does to it, with _very_ minimal
latency. Yes, this means that the userspace application(s) have to be fast
themselves but if they aren't getting their data delivered to them in time
to begin with they're SOL. Perhaps it's possible to get okay results with a
top-priority, realtime scheduled full stack in userspace which bangs I/O
ports and does all those pesky driver thingies but why do we have a kernel
again?
As to going the other way and putting it _all_ in the kernel; why? Why would
you care about the split from an API standpoint? The alsa-lib API is the
API, period. At which point it crosses over into the kernel is something an
application gets to see as an implementation detail. Rejoice -- you now
don't have to worry about floating point for example in the context of
resampling and/or soft-volume, or ...
Rene.
Rene Herman wrote:
> KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing
> by default for some time now so we're talking history anyway. You want
> mixing on your card? You got it.
I've been following this discussion with some interest, to learn more
about ALSA. I've been creating startup scripts for all of my sound-using
applications which look like this:
LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*"
I found that without libaoss.so preloaded, I wasn't getting software
mixing at all. I'm constantly running an MP3 player, and with that
library I can get sound alerts from other apps too.
I don't understand exactly what you mean by ALSA mixing by default. I
have the OSS Mixer API selected during kernel compiles. Is that what you
are referring to?
Thanks,
Patrick
On 06/28/2007 02:18 AM, Patrick Draper wrote:
Please always use Reply-to-All on this list -- subscribers here like to also
get personal copies.
> Rene Herman wrote:
>> KDE has finally dropped aRts from KDE4 and, again, ALSA has been
>> mixing by default for some time now so we're talking history anyway.
>> You want mixing on your card? You got it.
>
> I've been following this discussion with some interest, to learn more
> about ALSA. I've been creating startup scripts for all of my sound-using
> applications which look like this:
>
> LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*"
>
> I found that without libaoss.so preloaded, I wasn't getting software
> mixing at all.
This would seem to indicate that your alsaplayer (what's in a name) is setup
to output to OSS and not to ALSA...
The OSS interface -- consisting of direct access to device nodes such as
/dev/dsp0, /dev/mixer and /dev/music -- is an older interface for sound on
Linux. The newer ALSA interface works via a library API and is best used
natively. For backwards compatibility though, ALSA also provides emulation
of the older OSS interface.
It does so in two different ways in fact -- the first one is a direct kernel
space emulation where ALSA interprets accesses to those device nodes it then
manages much like real OSS would do. This kernel space emulation is made
available through the "OSS PCM/Mixer/Sequencer API" you see as options in
the ALSA kernel configuration menu.
The other way is a userspace emulation through the libaoss.so library that
you are using. That library catches accesses to the OSS device nodes in
userspace and translates them to ALSA accesses before they even get to the
kernel.
ALSA does software mixing (the act of mixing two seperate streams together
to form one) in userspace and as such, the kernelspace OSS emulation does
not support software mixing, while this userspace emulation does -- if your
ALSA default device is setup for software mixing (it is by default these
days) this also works for this libaoss route. If you run a OSS program
without the library preload it's using the kernel emulation though.
So -- the fact that mixing actually works for you when using libaoss means
software mixing is working correctly for your ALSA setup. The only thing you
should do is _use_ ALSA (natively) and not its OSS emulation so you can drop
the library preload.
I don't have alsaplayer installed (wasn't that thing dead?) so I can't walk
you through its configuration easily, but I suppose you'll be able to figure
it out. If you need to specify an ALSA device somewhere, make sure it's not
the old "hw:0" but "default" (or "default:0" for the first card, "default:1"
for the second, ...). The "hw:N" devices don't do mixing.
> I'm constantly running an MP3 player, and with that library I can get
> sound alerts from other apps too.
I myself mostly use the ogg123 and mpg321 command line players, both based
on libao and thereby only a simple:
$ echo "default_driver=alsa09" >/etc/libao.conf
away from being native ALSA players.
> I don't understand exactly what you mean by ALSA mixing by default. I
> have the OSS Mixer API selected during kernel compiles. Is that what you
> are referring to?
No. That's part of the kernel space OSS emulation. A "mixer" in that context
is the part of a soundcard that controls volumes and may mix the output of
several parts of the card/chip for playback and its inputs for capture. Ie,
that which is controlled by a mixer application such as the (ncurses) ALSA
reference mixer "alsamixer" or the mixer your desktop environment provides.
Once you have everything running as a native ALSA application you could
disable that option. In fact, since you're using the userspace emulation,
you could already. The new-ish Flash Player 9 (important for youtube these
days) for Linux is also an ALSA application and since I use it, I myself
haven't needed OSS emulation for anything anymore.
Rene.
On 06/28/2007 03:58 AM, Rene Herman wrote:
> to figure it out. If you need to specify an ALSA device somewhere, make
> sure it's not the old "hw:0" but "default" (or "default:0" for the first
> card, "default:1" for the second, ...). The "hw:N" devices don't do
> mixing.
Slight correction/expansion -- don't do _software_ mixing. Some cards can do
hardware mixing and in that case, "hw:N" or, specifically "hw:N,0", "hw:N,1"
and so on devices are available as hardware mixed devices.
Try a cat /proc/asound/card0/pcm0p/info and check the "subdevices_count" for
the number of hardware mixed playback devices you have available. If it's 1,
your card should've been configured (by ALSA itself) to use software mixing
by default and if it's higher than 1, it should not have been and will use
hardware mixing...
Rene.
Rene Herman wrote:
> So -- the fact that mixing actually works for you when using libaoss
> means software mixing is working correctly for your ALSA setup. The only
> thing you should do is _use_ ALSA (natively) and not its OSS emulation
> so you can drop the library preload.
Cool. How do I go about figuring out what every app uses? For example,
you mentioned that the flash 9 plugin, which I also use, is an ALSA
aware application. How do you know? I need the check out everything that
I use which needs sound (vmware, skype, kmplayer, etc.) I don't have
source code for at least two of those.
Thanks,
Patrick
On 6/27/07, Patrick Draper <[email protected]> wrote:
> Rene Herman wrote:
> > So -- the fact that mixing actually works for you when using libaoss
> > means software mixing is working correctly for your ALSA setup. The only
> > thing you should do is _use_ ALSA (natively) and not its OSS emulation
> > so you can drop the library preload.
>
> Cool. How do I go about figuring out what every app uses? For example,
> you mentioned that the flash 9 plugin, which I also use, is an ALSA
> aware application. How do you know? I need the check out everything that
> I use which needs sound (vmware, skype, kmplayer, etc.) I don't have
> source code for at least two of those.
Go into the sound preferences menu of the app and check which device
it uses. If it's something like /dev/dsp or /dev/audio it's using
OSS. If it looks like "default" or "hw:0" it's ALSA.
If your app does not have any sound preferences menu it's broken and
you should file a bug report.
You can determine whether an app with no configurable sound device is
using ALSA by running "strace broken_app" and grep the output for
"/dev/dsp" or "/dev/audio".
Lee
On 6/26/07, Andreas Hartmetz <[email protected]> wrote:
> Why not put the whole sound system in userland? It has been done before. Sound
> is just not performance critical at all and it's almost never mission
> critical.
There are dozens of companies selling Linux powered professional audio
gear, multiple pro audio centric distros, and hundreds of serious free
software audio apps. I suspect these developers and their users would
disagree.
I agree with you about userland drivers but at minimum this would
require merging the -rt kernel patches, otherwise the latency/jitter
will be too high to do anything but toy desktop sounds, then you need
a mergeable mechanism for doing DMA and interrupt handling in
userspace. It has been attempted before but never evolved to the
point where you could drive a complex device like the emu10k1.
Lee
On Wed, 2007-06-27 at 22:04 -0500, Patrick Draper wrote:
> Rene Herman wrote:
> > So -- the fact that mixing actually works for you when using libaoss
> > means software mixing is working correctly for your ALSA setup. The only
> > thing you should do is _use_ ALSA (natively) and not its OSS emulation
> > so you can drop the library preload.
>
> Cool. How do I go about figuring out what every app uses? For example,
> you mentioned that the flash 9 plugin, which I also use, is an ALSA
> aware application. How do you know? I need the check out everything that
> I use which needs sound (vmware, skype, kmplayer, etc.) I don't have
> source code for at least two of those.
run ldd on the binary...
On 06/28/2007 04:28 AM, Rene Herman wrote:
> On 06/28/2007 03:58 AM, Rene Herman wrote:
>
>> to figure it out. If you need to specify an ALSA device somewhere, make
>> sure it's not the old "hw:0" but "default" (or "default:0" for the
>> first card, "default:1" for the second, ...). The "hw:N" devices don't
>> do mixing.
>
> Slight correction/expansion -- don't do _software_ mixing. Some cards
> can do hardware mixing and in that case, "hw:N" or, specifically
> "hw:N,0", "hw:N,1" and so on devices are available as hardware mixed
> devices.
Correcting the correction (sorry, it was late) -- "hw:N" is card N, "hw:N,M"
is PCM interface M of card N and "hw:N,M,K" is (hardware mixed) subdevice K
on PCM interface M of card N. Normal cards have only one PCM interface
meaning that M is 0 in the above.
That is, I meant that "hw:N,0,0", "hw:N,0,1" and so on are the hardware
mixed devices.
Rene.
On Wed, 27 Jun 2007, Patrick Draper wrote:
> Rene Herman wrote:
>> So -- the fact that mixing actually works for you when using libaoss means
>> software mixing is working correctly for your ALSA setup. The only thing
>> you should do is _use_ ALSA (natively) and not its OSS emulation so you can
>> drop the library preload.
>
> Cool. How do I go about figuring out what every app uses? For example, you
> mentioned that the flash 9 plugin, which I also use, is an ALSA aware
> application. How do you know? I need the check out everything that I use
> which needs sound (vmware, skype, kmplayer, etc.) I don't have source code
> for at least two of those.
If can I join .. (again)
After upgrade to skype 1.4.x all sound output in skype I have only in left
channel. Serching for skype+left+channel on google shows many people
have this kind problem :>
ALSA does not privide application mixer settings on application level.
Some messages on skype forums suggests some workarouds in ~/.asoudrc
but where is documentation for this part ?
Anywhere are described ALSA diagnostics procedures/technics ?
kloczek
--
-----------------------------------------------------------
*Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?*
-----------------------------------------------------------
Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*
On Wed, 27 Jun 2007, Lee Revell wrote:
> On 6/26/07, Andreas Hartmetz <[email protected]> wrote:
>> Why not put the whole sound system in userland? It has been done before.
>> Sound
>> is just not performance critical at all and it's almost never mission
>> critical.
>
> There are dozens of companies selling Linux powered professional audio
> gear, multiple pro audio centric distros, and hundreds of serious free
> software audio apps. I suspect these developers and their users would
> disagree.
OK .. hundreds.
Can you list ten ?
Can you point to oppinions of this people about ALSA ?
kloczek
--
-----------------------------------------------------------
*Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?*
-----------------------------------------------------------
Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*
Tomasz Kłoczko wrote:
> On Wed, 27 Jun 2007, Patrick Draper wrote:
>
>
>> Rene Herman wrote:
>>
>>> So -- the fact that mixing actually works for you when using libaoss means
>>> software mixing is working correctly for your ALSA setup. The only thing
>>> you should do is _use_ ALSA (natively) and not its OSS emulation so you can
>>> drop the library preload.
>>>
>> Cool. How do I go about figuring out what every app uses? For example, you
>> mentioned that the flash 9 plugin, which I also use, is an ALSA aware
>> application. How do you know? I need the check out everything that I use
>> which needs sound (vmware, skype, kmplayer, etc.) I don't have source code
>> for at least two of those.
>>
>
> If can I join .. (again)
>
Heh =)
> ALSA does not privide application mixer settings on application level.
> Some messages on skype forums suggests some workarouds in ~/.asoudrc
> but where is documentation for this part ?
>
You may want to read this one:
http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php
> Anywhere are described ALSA diagnostics procedures/technics ?
>
> kloczek
>
Gabriel C
On 06/28/2007 05:04 AM, Patrick Draper wrote:
> Rene Herman wrote:
>> So -- the fact that mixing actually works for you when using libaoss
>> means software mixing is working correctly for your ALSA setup. The
>> only thing you should do is _use_ ALSA (natively) and not its OSS
>> emulation so you can drop the library preload.
>
> Cool. How do I go about figuring out what every app uses? For example,
> you mentioned that the flash 9 plugin, which I also use, is an ALSA
> aware application. How do you know?
Various methods. If all's well, the application has a config menu where you
can look at and change the settings.
Or, running ldd on the binary to see if it's linked to libasound, "grep
/proc/<pid>/maps libasound" (also catches dlopen), "strace" or usually
easiest and what I tended to do -- "lsmod" to see if starting the app
triggered the automatic loading of snd-pcm-oss and snd-mixer-oss which I
don't normally have loaded.
This is the "[things are still not great] partly _due_ to people maintaining
OSS is somehow a valid choice on Linux" that I stated early in this thread.
I actually believe the kernel space OSS emulation has been fairly counter
productive -- it's allowed applications to stay with an obsolete interface
since the users didn't even have to _know_ due to it all just working. At
least with the userspace emulation, people know they are using an OSS
emulation if they are starting the application with an library preload.
The kernel space emulation is a bit more bullet-proof in the sense that the
userspace emulation would not for example help with applications that use
direct syscalls to open device nodes and I guess that was important.
When OSS/Free was replaced with ALSA inside the Linux kernel this was a big
change in an area most users use and any such change inevitably opens up big
cans of change resistant wankers who understand the old interface and have
no need for the new one and will tell you that you did it all wrong, it was
all for nothing and you suck period. They'll keep it up for years and years
generally. The kernel-space OSS emulation _does_ mostly just work, which is
the kind of thing that you need in this environment to be allowed to tell
these people to go sexually entertain themselves.
Perhaps it's now finally coming to the time where the kernel space emulation
can be deprecated and eventually removed. Or not...
> I need the check out everything that I use which needs sound (vmware,
> skype, kmplayer, etc.) I don't have source code for at least two of
> those.
I don't know if vmware by now supports native ALSA but it didn't use to. The
current version of skype (1.4, still called a beta it seems) does.
kmplayer seems to be a frontend for various mediaplayer solutions. Don't you
just love that mess? Its backends include MPlayer and Xine, and both these
can talk native ALSA fine at least. For mplayer, use a "ao=alsa" line in the
.mplayer/config file (or just start it with -ao alsa) and for xine, look in
its setup menu (audio tab, having set the interface level to beter than
"beginner").
Rene.
On 06/28/2007 01:50 PM, Tomasz Kłoczko wrote:
> If can I join .. (again)
Welcome...
> After upgrade to skype 1.4.x all sound output in skype I have only in
> left channel. Serching for skype+left+channel on google shows many
> people have this kind problem :>
This would seem to be a (fairly, it's no doubt just outputting mono) skype
specific problem and given that skype is a proprietary closed source
application, you now get to go suck on a Skype support engineer! Hurrah!
Or this might be helpful:
http://forum.skype.com/lofiversion/index.php/t85880.html
No, no idea why skype would require you to do this yourself. Maybe you
should ask them. This is now _really_ no longer a kernel issue though.
Rene.
Our developers chose ALSA over OSS as the sound API for a VOIP-like
fullduplex application and one of the reasons was API - OSS mixer API
was not flexible enough (something to do with separating muting and
volume control IIRC).
--
Meelis Roos
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).
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.
On 6/28/07, Rene Herman <[email protected]> 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
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
On Thu, Jun 28, 2007 at 04:20:45PM -0400, Lee Revell wrote:
> On 6/28/07, Rene Herman <[email protected]> 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
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
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.
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
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
> 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
On Fri, 29 Jun 2007 16:56:05 +0200
Miklos Szeredi <[email protected]> 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
> Miklos Szeredi <[email protected]> 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
> > > 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
