Sound support on potato
There's some confusion to be cleared up here.
> o esd: this program depends on alsa
No it doesn't. For esd to run there have to be some sound drivers
installed but these drivers can be either OSS or ALSA (or any other).
> IMHO such programs shouldn't depend on alsa, or any specific sound
> driver. That should be flexible. All gnome packages depend on alsa
No they do not. GNOME requires esd if sound is enabled in the
control-center, but esd will work with either OSS or ALSA.
One problem I do see with GNOME, however, is that when sound
is enabled and esd isn't running, a GNOME application pauses
each time it tries and fails to play a sound. Something needs
to be done about this.
> o alsa: still we have the 0.4.x versions in potato. And may I remind you
> that 0.4.x versions are obsolete?
Yes they are obsolete. However, in order to release Debian it is
necessary to freeze versions at some point so that everything can
be made to work together. It would be nice to upgrade to 0.5.x,
but this would break some sound packages because the ALSA API
and libraries changed from 0.4.x to 0.5.x.
> Is it a custom to make obsolete software to go in the "stable"
> version?
For the reasons given above, yes.
> 0.5.x are the stable upstream releases. There
> might be a few things that will work better with the old versions, so either
> i) throw those packages away, since most of the stuff works well with oss
> emulation. if they don't work with the new modules, who cares?
So just toss out all packages that work with 0.4.x but not (yet) with
0.5.x ? Some people might want to use those packages.
> ii) if they require old versions of the libs, those libs could be maintained
> in oldlibs section.
True. But what makes more sense is upgrade all ALSA-related sound packages
to the 0.5.x level. When this is done, people can upgrade their whole
sound system to 0.5.x. But this ypgrade hasn't been completed yet, SFAIK.
> o alsa packages: These packages have slight problems. I think the decomposition
> of alsa into alsa-base and alsa-modules... hasn't been studied enough. Don't
> ask me for advice, it doesn't look good...
The reason for splitting off the modules is that they are kernel version
dependent. Some people who compile their own kernels need also to compile
their ALSA modules from source; but they can use everything in alsa-base
as it is.
> o "other" sound drivers: I think it's a good idea to make other kernel sound
> drivers as module packages as they are available. For instance, there's a not-very-good
> SB Live! driver from creative.
I am using alsa-modules-2.2.15_0.5.8a-1+2.2.15-1 downloaded from
http://incoming.debian.org *the same day* that the 0.5.8a ALSA
drivers were released. If there are other sound drivers you'd
like packaged up, perhaps alien can be of help; or perhaps you'll
become a maintainer.
> The problems with the alsa packages are, IMHO, quite urgent and should be fixed
> some time. I don't think that the maintainer reads the bug reports at all, anyway.
What makes you think that?
> For the argument that "These packages are stable, and many prudent packages use them",
> I would like to suggest taking the author's opinion on this subject. I'm quite confident
> that the author will suggest the latest stable releases for distribution. (version
> 0.5.7)
Once one takes into account the problem of actually getting a release
out the door, one understands that the release can't include the very
latest version of every software package.
Having said that, I'll agree with you that Debian's releases come
too slowly. Many people think that something needs to change.
> In addition, there seem to be some sound applications which could be included in potato.
> Perhaps those could be made into one of those mythical "potato updates" that people have
> been talking about.
Which applications do you have in mind?
Cheers,
Thomas Hood
jdthoodREMOVEME@mail.com
Reply to: