Subject: Re: [linux-audio-dev] Audio routing issues for linux..
From: Paul Davis (pbd_AT_op.net)
Date: Mon Jun 10 2002 - 16:36:30 EEST
>Yeah, but what I mean is 2 things, first that you should be able to
>change transparently where the app is sending the data, without the
>app noticing, and second that such configuration shouldnt be stored by
>the app but from an abstracted app/interface that handles connections.
You're asking for something that can't be done satisfactorily without
an API change. You're resisting the particular API change that is
required. Then you say:
>1-Saves a _huge_ amount of time to programmers since the only thing
>they have to do is register audio in/out slots, and then route the
>external sources. How many times do we see programs use the same code
>over, over and over again? (freeverb/chorus/flange/ladspa
>chains/equalizers/normalizers/mixers/vu bars/etc). Well, this would
>put an end to that, and audio programming becomes a lot easier.
You've just defined half the rationale for JACK.
>2-Saves enormous time to the user. Why capturing/dumping/editing if
>your CPU can do everyting at once? just chain your favorite programs!
>It actually even gives you the ability to build up your own chains of
>modifiers for program to program.
You've now defined the other half.
>3-Encourages program interoperability, ala good old unix way. It's
>easy, most programmers, and specially the new ones, dont care about
>side libs such as JACK/Arts. They want to go straight to the official
>api first.
You're now continuing on with your apparent habit of partly
recognizing the need for an API change and then continuing on as if
you hadn't:
>What I propose is:
>-Audio routing/data sharing for ALL programs. For most it should be
>audio routing via api calls.
This is an API change. OSS and ALSA contain no such calls.
Repeat: you can't do this correctly with the OSS or ALSA APIs. You
seem to misunderstand something very basic:
>-Low latency/syncronous execution only for the ones that _need_ that.
Applications don't need low latency. ***USERS*** need low latency.
You can't have one system for "non-low-latency" and one for
"low latency", for the very same reasons you are now complaining
about. The latency of the system should be something that most
non-duplex applications shouldn't have to care about at all -
its just there as a property of the system.
--p
This archive was generated by hypermail 2b28 : Mon Jun 10 2002 - 16:37:14 EEST