login
Search
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
On Sun, 24 Jun 2007 19:51:38 +0200 (CEST) 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: 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
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. -
The cs46xx OSS driver in the kernel is not our work. This discussion is 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 -
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 -
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. -
I sent a patch to the ALSA developers 4 years ago. It was never included in the kernel :/ Here's the comment from a script that I once wrote to make some closed-source dinosar code run (speech recognition) on modern linux: # Note that ALSA (Advanced Linux Sound Architecture), the sound drivers that # replace the older OSS as of kernel 2.5, also introduce a problem for some # soundcards: unlike the OSS drivers, the ALSA drivers limit the recording # buffer to the hardware limit of your sound card. For example, the SB Live! # only has two 'period' buffers (called fragments before), and although # viavoice requests an 'arbitrary number of periods, size 1024 bytes', it # only gets two periods of 1024 bytes: 2048 bytes in total! The ViaVoice # engine however doesn't even process sound until it sees at least 6102 bytes. # The 'solution' for this is to increase the buffer size (from 1024 to say # 8192), this script also takes care of that. Unfortunately, also that is # possibly not enough: the sound is read from the hardware in chunks of # 'period size' and having only two buffers this is often causing an underrun. # When ALSA sees an underrun... it stops the sound stream. My (four year old) patch can be found here: http://www.xs4all.nl/~carlo17/alsa/index.html I STILL think that ALSA should restart the stream after an underrun, but I am not someone who asks twice :p usually. -- Carlo Wood <carlo@alinoe.com> -
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. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -
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 ...
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. -
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. -
At Mon, 25 Jun 2007 10:06:18 +0100, I think he is right in the case of read (although I don't remember his post as my buffer overran). The playback is automaically reset and restarted at underrun. But, the patch there is wrong. It should handle -EPIPE, which means XRUN, while -ESTRPIPE means the suspend state. Takashi -
To 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 -
At Mon, 25 Jun 2007 23:09:21 +0300, 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 -
How better and where better ? 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 OSS provides ALSA emulation too. 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 So .. why ALSA provides so ...
At Mon, 25 Jun 2007 11:51:59 +0200 (CEST), 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: "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
At Mon, 25 Jun 2007 13:36:23 +0200 (CEST), 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 -
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 -- -
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. -
At Mon, 25 Jun 2007 14:47:50 +0200, FYI, fork+exec was removed long time ago. shmem and semaphores still remain, though. Takashi -
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. -
At Mon, 25 Jun 2007 14:44:42 +0200, 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 -
Whatever you do in the library won't solve the problem of properly supporting the OSS interface. OG. -
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
Allowing for some hypothetical implementation noone might ever write is
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
-
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). -
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. -
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 -
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 -
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
-
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
-
For what it's worth -- I do agree with this... Rene. -
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 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.) 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 ...
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 -
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
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
-
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 -
Well, had a look at what FUSD does. It assumes that the ioctl argument is stuctured according to the command. If all OSS ioctls are like that, then fine, fuse can support it properly. The drawback of this is that ioctls which aren't structured properly could cause weird failures due to wrong data being accessed by the poor unknowing kernel. Miklos -
Included with the docs there's a list of the OSS ioctls. I don't understand enough of the problem to judge whether they are suitable to be handled by FUSE: http://manuals.opensound.com/developer/ioctl.html [version 4] http://www.4front-tech.com/pguide/oss.pdf [version 3] I don't know which API version is supposed to be supported though. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org -
Thanks, but these docs are about what the ioctls do, and I'm totally uninterested in that. What I'm interested is how the ioctl data is _structured_. OK, had a look at <linux/soundcard.h>, it does define a data structuring based on the ioctl numbers, and it's just slightly different from the structuring defined by <asm-generic/ioctl.h>. Oh, the beauty of the ioctls. So answering my own question: no, it's not sanely possible to support ioctls through fuse without userspace hacks or significant effort. A possibly acceptable option is to add a plugin mechanism, whereby people could write small ioctl interpreter kernel modules for their specific needs (such as parsing OSS ioctls), which would serialize/deserialize any type of ioctl input/output making them suitable for transfering between the kernel and the userspace filesystem. Another, much more complex option is to design a generic ioctl data interpreter language, and let the filesystem upload their ioctl parsers into the kernel. Miklos -
Without in-kernel OSS emulation, it is very hard to verify if kernel sound support works properly. OSS could been driven from shell for testing, and I believe that's still important feature to keep. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
On Mon, 25 Jun 2007, Takashi Iwai wrote: I dont know is soft mixing is biggest issue but .. Few minutes ago I'm upgrade to skype 1.4.x. Lets try again above experiment: $ strace -f -e trace=file galeon 2>&1 | grep dev/snd [pid 28593] open("/dev/snd/controlC0", O_RDWR) = 46 [pid 28593] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 47 OK .. now I'm enter on www.youtube.com and start playing random video. Look on above: soud device was oppened in non bloking mode. After few seconds I'm close tab with video in galeon. Just after this I'm start skype and try call to test123 and calling isn't possible: $ strace -f -e trace=file skype 2>&1 | grep dev/snd [pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43 [pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43 [pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43 [pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43 [pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43 [pid 30173] open("/dev/snd/controlC1", O_RDWR) = 43 [pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43 [pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43 [pid 30173] open("/dev/snd/controlC2", O_RDWR) = 43 [pid 30173] open("/dev/snd/controlC3", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC4", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC5", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC6", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC7", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC8", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC9", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC10", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC11", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30173] open("/dev/snd/controlC12", O_RDONLY) = -1 ...
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. -
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, 25 Jun 2007, Gabor Gombas wrote: > On Mon, Jun 25, 2007 at 01:36:23PM +0200, Tomasz K
$ dpkg -l | grep skype
ii skype 1.4.0.74-1
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
-
Install alsa-oss fix this problem? <http://www.skype.com/help/guides/soundsetup_linux.html> Best regards, Renato -
On Mon, 25 Jun 2007, Renato S. Yamane wrote: > Tomasz K
Which started at a time there was no ALSA, has been basically dead for 6 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 /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. -
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 -
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 -
At Sun, 24 Jun 2007 19:51:38 +0200 (CEST), 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 -
On Mon, 25 Jun 2007, Takashi Iwai wrote: What is harder ? Bring ALSA API to the same level of functionalities as You are loosing point lack of will ALSA developers to make this useable, and well documented. OSS it is stabkle API specyfication with good 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
Hi, This is impossible to answer unless somebody does the both 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 Depends on patches, just bring them on! Having some competition would be a good thing for both ALSA and OSS. Thanks, Bart -
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 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 -
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
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
-
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 ...At Tue, 26 Jun 2007 12:25:16 -0400, Set CONFIG_SND_VERBOSE_PROCFS=y. Takashi -
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??? -
At Tue, 26 Jun 2007 00:18:05 +0300, The HD-audio is still messy on ALSA, too. 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 -
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 -
While I agree that ALSA is better than OSS... I don't actually think ALSA kernel<>user api is... at least for my purposes. I'm still using OSS emulation, because I could not get alsa proper to work... and the advanced stuff just does not work in emulation. In OSS days, if you wanted to test kernel sound driver, you did: mknod /dev/dsp cat /bin/bash > /dev/dsp. With alsa+oss emulation, you need mknod /dev/mixer install aumix aumix mknod /dev/dsp cat /bin/bash > /dev/dsp. With alsa proper, it is install alsalib create about 5 device nodes install alsautils maybe do some config? aplay some.wav ..provided you have .wav near you. I'm not sure if it is possible to produce sounds using normal shell scripting? (w/o alsautils)? I can even test kernel graphics drivers by cat /bin/bash > /dev/fb0... it would be nice to have equivalent for audio... OSS API seems to be the equivalent these days, but please don't deprecate it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
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: Could you say something more detailed about this compare ? kloczek -- ----------------------------------------------------------- *Ludzie nie maj
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 -
I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. -
It does not sound stupid and sounds good at first sight.
But there are problems we've already seen with similar situations in
different parts of the kernel:
They would have different hardware support, features and bugs.
And then a user user whose sound card is only supported by sound system A
needs a feature only available in sound system B.
And the quality decreases since people will often not report bugs in
sound system A if sound system B works for them.
OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
mostly a difference for application developers. And since (as you say)
most applications already support both, there's no compelling reason for
providing more than one of them.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
"I think the ideal solution would be that both ALSA and OSS APIs can co-exist by sharing the same low level drivers (which has already been demonstrated). The low level driver interfaces in both systems are practically identical. This means that ALSA's core can work with OSS' drivers and vice versa." So Hannu have plan for share ALSA low level drivers without changes (porting to OSS will not be neccessary and/or will need only small amount of time .. IMO much less than make ALSA fully functional). Main diffrences between ALSA and OSS are above low level drivers so IMO it is completly possible have ALSA and OSS in the same tree. OSS wtil not dies (and try resurect) ALSA still (after few years) was not born and still isn't rock solid point odf Linux desktop (IMO it is most weeknes ponit of LD). IMO it will be better if Hannu will start pushing any OSS chages to Linus tree. Current OSS code in Linus tree is more or less not useable so allow maintain this code in main tree can't hurd anything outside this area. kloczek -- ----------------------------------------------------------- *Ludzie nie maj
