[PD] what is the current state of the support for the Alsa Hammerfall driver?
ico at fuse.net
Wed Feb 13 21:52:49 CET 2002
> :) 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
> > even for RME that does not have interleaved output. This results in
> > redundant software resampling (unless something has been
> > changed in recent incarnations of the OSS architecture of which I am
> > 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
> > - OSS is a standard propelled by a commercial company (and that is
> > included in the open-source kernel, somehow I find it hard to
> > that the mix between commercial and open-source is good for the
> > long-term growth, although retrospectively speaking I am very
> > 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
> 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
> > days ago), nothing worked as it was supposed to (although obviously
> > did not give it enough of a chance, I am sure).
> ... well who knows, at least this way we won't find it out.
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)...
More information about the Pd-list