2009/1/3 Bruce Dubbs <[email protected]>: > Thanks Alex. As I look at nas, I don't think that the change above will do > anything for nas because it is shipped with pre made Makefiles. They are not > regenerated. It would appear that my XPLIB= workaround is the most pragmatic > solution for now.
Yes. > From your description, this seems to be a Imake related thing. We are not > using Imake in xorg any more and nas really is a throwback. Is it worth the > time to investigate this problem more? No. > Your comment is something that has been nagging me for a while. There are > several packages that reference nas: arts, mpg123, mplayer, sdl, libao, qt, > qt4, > and openoffice -- all optional. > > When we look at these programs most reference multiple sound servers like NAS, > MAS, JACK, ESoundD (Gnome), aRTs (KDE), and PulseAudio. > > Some of these are oss based (I think deprecated) and some alsa based. Some > can > do both. So far, right. > AFAIK, only one sound server can run at a time. It appears that several > applications like qt can link into whatever is running. Correct, but the program must produce the sound through qt then, instead of through the native means. Nobody does that. E.g., nearly all KDE3 applications produce sound through aRts, not through qt. > The question is how do we handle this in BLFS. I think that all the sound > servers cna be built on one system and the user run one at a time, but that > is, > IMO, a lot more trouble than its worth. This is a different issue. The original issue is that NAS is simply obsolete, doesn't provide a complete solution (as in "I can route output from all programs through it"), and is kept in the book purely for historical reasons. As for your question, IMHO, the ultimate purpose of each sound server should be shown, and a use case defined that cannot be efficiently covered by other solutions. E.g., JACK is the standard application for audio production in studios. It has a design based on shared memory and zero copying that minimizes latency. It is well-suited for working with multichannel audio cards. It is the only way to output sound through FireWire (with the optional ffado dependency). It is unsuitable for desktop uses, because an application due to which a buffer underrun occurs is immediately killed with the KILL signal. If alsa-plugins are installed, every ALSA application can function as a JACK client, though. But we don't have any professional audio programs (as a very minimum, if we want to cover this topic at all, Audacity, Rosegarden, Fluidsynth) in BLFS, so no real use cases for JACK. aRts is the standard sound server for KDE3. Many KDE3 programs know no other way to produce sound. Same goes for GNOME and Esound. There are "artsdsp" and "esddsp" wrappers that can route output of most OSS programs through these sound servers, PulseAudio (for me) is an attempt to rewrite the mixing code in ALSA. It has a unique feature of being able to control the volume of each program's output separately. Also, it can route output of ALSA and OSS programs through it. > An even bigger problem is how do we handle 64-bit issues in general when LFS > goes to that and BLFS follows. Exactly as we handle any other unsolvable (for non-programmers) problem, e.g.,UTF-8 issues: apply third-party patches, warn the readers, and, in worst cases, drop packages. The real issue is where to get the bug reports from. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
