:) yes, but some times you are not able to run ALSA specific apps on ALSA ... and exactly this is the problem with ALSA support for pd, once added it was constantly breaking on each update. I have been assured that this is not going to happen that often now the API is stable, but still this was the main reason I stopped implementing things in ALSA some years ago, ...
This is a worn-out (and at this point anything but true!) argument against ALSA. You should have checked it out in the past 4-6 months, and (apart from the anemic documentation) would have realized not only that it's API is pretty much frozen (i.e. no backwards compatibility-breaking changes), but also that it is now a 2.5 kernel API as well (Linus just recently posted a note about this in an e-mail saying that he just simply did not yet get around it, but it should be in there any day now). Besides, give me one Alsa app that does not run under Alsa (that is still being maintained -- in other words, it is still current). Granted, not all OSS-only apps work well with Alsa (at least not yet, due to primary focus of the Alsa devel team to finish-up the main portions of the API, and then worry about OSS emulation), but that is still much, much better than the other way around (where no Alsa apps work with the OSS)...
- OSS uses "interleaved" approach to provide multi-channel
capabilities,
even for RME that does not have interleaved output. This results in redundant software resampling (unless something has been
dramatically
changed in recent incarnations of the OSS architecture of which I am
not
aware, please correct me if I am wrong)
this is wrong for the RME Hammerfall.
In what sense? I am 100% sure that Hammerfall is one of the few non-interleaved cards. So does this mean that your OSS driver addresses this issue or is it that you believe that Hammerfall is interleaved after all?
- OSS is a standard propelled by a commercial company (and that is
included in the open-source kernel, somehow I find it hard to
believe
that the mix between commercial and open-source is good for the long-term growth, although retrospectively speaking I am very
thankful
to the 4fronttech for providing sound support for the Linux platform when it needed it the most and when no one else was able/willing to provide one)
wrong too, OSS used to be the native linux sound API.. (AFAIK still
is,
I haven't looked at 2.5)
I don't see anything wrong with this statement, so I am not quite sure what are you labeling *wrong*. Linus originally gave 4fronttech the "thumbs-up" to build these drivers because Linux needed audio support. But it WAS and still IS a commercially driven API. Just because it resides in kernel space, it does not mean that it still is [or that it will remain to be] a *default* API. 2.5 kernel is introducing ALSA in the kernel space, so things are about to change (and from the hints I've been getting, OSS will be slowly phased out)...
- OSS's interest is in multiple platform support, rather than the
maximum platform-specific performance
- Finally, last time I tried OSS RME Hammerfall driver (v0.8 a
couple of
days ago), nothing worked as it was supposed to (although obviously
I
did not give it enough of a chance, I am sure).
... well who knows, at least this way we won't find it out.
Guenter
Please don't get me wrong, but I have no time to fiddle with a driver that has little or no docs. While ALSA has a similar problem of lack of documentation, I found ALSA's mailing lists more than helpful. If one can point a good OSS mailing list (other than 4fronttech's), I will possibly reconsider delving into the OSS version of the driver (at least for the time being and for particular tasks, until the OSS emulation gets better in ALSA)...
Sincerely,
Ico