Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Mark Constable (markc_AT_renta.net)
Date: Sat Dec 15 2001 - 12:33:00 EET
On Sat, 15 Dec 2001 07:49, Ivica Bukvic wrote:
Wow, you are a real LAD surviver, congrats :-)
> My thought is to develop a sound daemon that would be compatible with
> older apps using esd and artsd, based on alsa-server, with the
> efficiency of jack, and ability to share audio resource(s) with the
> priority settings (so that the desktop warning bleep would have less
> audio priority than the real-time 8-channel recording/playback going on
> at the same time), as well as patchbay-like ability to route signals,
> making Alsa the backbone of the audio system on linux, while
> phasing-out/replacing the inefficient OSS aspects.
Please, no more half-way compromises with OSS... kill it, do
not even consider "backwards compatibility" for old OSS apps!
Are there any worthwhile salavaging in light of newer developments ?
Every ounce of effort towards maintaining (crappy) backwards
compatibility for old OSS mainly/only systems takes away effort
from enhancing true ALSA apps.
> On top of that
> documenting Alsa should be the highest priority at this point, thus
> stimulating developers to use Alsa instead of OSS.
Absolutely, but quality programmer docs to the level of, for
example, the Trolltech QT documentation will take _years_, so
the best shorter term solution is to look at a series of SMALL
example, but useful, apps/trinkets that truly take advantage
of ALSA semantics. Concise, no bullshit HOWTOs on anything to
do with producing various types of code to take advantage of
as much of the ALSA libs and utilities as possible.
I'm sure there a 1000s of people waiting to dive in and dabble,
but for these type of people it's just too much of a deep hack
to get anything working right now... these same people are the
birthplace for 1000s of audio app(let)s in a few years... the
sooner they can start coding with some guidance the sooner we
will all benifit from this oncoming onslaught.
The hard core developers on this list are "already there" so
the best bang for bucks in my view is getting the next round
of newbies up and coding asap.
> A joint effort would make this not only doable but relatively quickly
> achievable. Imagine just how much time does each programmer waste on
> implementing their own version of efficient sound signal pooling process
> within their own application. Now multiply that by the number of linux
> sound apps out there. If we used that same time invested by all
> developers on implementing their own version of the solution to this
> problem, and concentrated on developing one universal solution to this
> issue... Well, you get the idea.
That's part of the deal with open source and personal development.
Who wants to really work on someone elses project when you can do
yer own !
Sure, better coordination would get us there sooner but the upside
of the way it is is exactly that there are so many different routes
being explored... and all clearly outlined in mostly GNU available
source code. This is the "metric" that is not part of the other OSs
that will get played out on the emerging linux a/v scene... and the
more complex and digital things become the more "hacking" may be
generally accepted as the prime way to achieve excellence (as opposed
to just practising those licks over and over again).
> Now, I must admit that there are aspects of this daemon stuff that I am
> not too familiar with and am not sure whether this kind of architecture
> would be capable of producing sample-synced and at the same time
> low-latency output (as Paul has pointed out), so I am not sure whether
> this would in the end be an universal solution. But even if that
> wouldn't be the case, it could still be used to improve audio resource
> sharing issue, while making extreme low-latency stuff something that
> would have to be dealt with on individual basis (maybe the daemon could
> be circumvented through a reserved high-priority thread, while still
> offering a user-friendly way of "feeding" the /dev/dsp with audio
> buffers in a highly efficient manner).
Anything strictly ALSA based (particularly so newbies don't get
confused by two seperate code paths) and the smaller and finishable
the better, lot's of people have big grand plans for larger projects
but getting usable (good demonstration) apps in a timely manner
would also be beneficial for a lot of LAD fringe-dwellers.
--markc
This archive was generated by hypermail 2b28 : Sat Dec 15 2001 - 12:29:52 EET