Subject: Re: [linux-audio-dev] Re: [linux-audio-user] Audio routing issues for linux..
From: Juan Linietsky (coding_AT_reduz.com.ar)
Date: Tue Jun 11 2002 - 00:02:57 EEST
Great! of all people I think you understood what my point was with
this proposal.
I really have to work on improving my engish grammar.
> > 3-You may also want to put just any program that uses native
> > OSS/ALSA through this. Imagine running xmms and wanting to put the
> > sound thru a better equalizer than the one included. Instead of
> > botherering in writing a SPECIALIZED equalizer plugin for xmms,
> > you just redirect the output to an equalizer program that takes
> > many inputs/outputs.
>
> http://eca.cx/screenshots/jack_alsaplayer_and_ecamegapedal_20020302.jpg
>
> Notice the date. In other words this is certainly possible with JACK
> and has been for a while!
I've been dreaming with this for years, but not only
with apps you have to convert to jack, but with native ones too :)
> > 5-You know you cant force application owners to convert their
> > stuff to jack/arts/etc. You'd also rather not waste your time
> > converting their applications to that, and the application owners
> > would rather not having to support multiple apis. So, this saves
> > us time to all.
>
> Maybe you are right, promoting JACK (or any other new framework) is
> a very difficult task indeed. On the other hand I really think JACK
> is something very exciting. I've already started to work on adding
> JACK support to a few of my favorite linux audio apps so I can use
> them in combination with ecasound. What can I say... it's like a
> whole new ball game! :) Like it or not, JACK as it is now can do
> things that simple weren't possible before. It's here, it's real and
> it works! :)
Maybe if we all do the effort, jack will become a standard.
I'd really like this happening, and probably if it does, jack will
be somewhat naturally merged to alsa..
>
> > Probably the easier and more natural approach to this is just
> > integrating JACK to ALSA in some way.
>
> This is not as easy as it sounds. I've thought about this a few
> times when I was working on Ladplex (my own implementation of the
> LAAGA concept which I later abandoned in favor of JACK). You could
> implement most of jackd's functionality in the alsa-lib layer, but
> not without problems:
>
> - you'd need a separate server (and with it all the
> installation/user-support
> problems you mentioned as problems of JACK); otherwise you'd have
> no sane way of resolving the user-privilege problem
> - only with ALSA apps that behave like JACK-clients would
> efficient low-latency operation be possible (in other words
> the ALSA API, although certainly allows it, doesn't force app
> writers to make their apps efficient for lowlatency operation)
> - no transport control
> - you'd need a separate API for making connections and querying
> current network configuration
> - it's a big task; even with a very limited interface, JACK has
> required quite a lot of developer effort; ALSA PCM API is,
> well, it's just larger
>
> If we don't worry about low-latency too much, then the situation
> changes. It shouldn't be too big of a task to write an ALSA PCM
> plugin that interfaces with jackd using libjack. This would allow
> all ALSA and OSS apps to interact with JACK. I'm certain someone
> will write this bridge sooner or later.
Yes! This is super just exactly accuratedly the point of what I was
proposing. My point is simply that not all apps you'd like to
route/interconnect need low latency, thus there is no need to use JACK
natively on them. When the app tries to open an audio in / audio out
channel with alsa, it registers as a plug into the JACK subsystem.
Since It doesnt need to work low latencyish, the JACK programs will
work perfect with them.
> A simplified version would
> do:
>
> - lock the ALSA hw parameter space to the values given by jackd
> - treat JACK like a soundcard
> - pcm plugin layer is used to convert between formats used
> by JACK and ALSA (here JACK is the 'hw' device)
> - when JACK delivers an interrupt, the bridge code
> updates the "hwptr" and checks whether ALSA app should be
> woken up
> - sw-params like avail_min, and start/stop threshold can
> be used to control to bridge operation
> - ... you get the picture
>
> There shouldn't be any great technical difficulties in implementing
> this. But ALSA and OSS apps using this bridge won't be as efficient
> as native JACK clients and don't have access to all JACK functions.
> And yup, for many uses this isn't a problem. But as efficiency and
> low-latency is what most current JACK developers are interested in,
> this type of bridge code doesn't yet have top-priority.
>
The concept is that while apps dont have access to all JACK functions,
and that the approach is not as efficient for low latency shouldnt not
be something to worry about. Because as I said before,
most apps that need to use this approach dont need low latency.
I think this is something that should be taken in consideration
by the JACK developers for a couple of reasons. First because it would
proovide normal users with a very powerful tool for managing their
audio. Allowing them to play with global parameters of the sound
output (such as managing treble/bass, adding a bit of reverb,
3D/surround enhacements,etc) as well as adjusting certain apps,
capturing back the audio without da/ad problems, sharing the output in
consumer cards, and more.
This also can make life easier for ALSA driver developers who can
give less priority to supporting such features in the soundcard
hardware, because users will be able to have them much sooner.
> PS You can also think of this bridge as JACK embedded in alsa-lib
> if that sounds nicer to you. >;)
>
> --
Sounds nice :)
Juan Linietsky.
This archive was generated by hypermail 2b28 : Mon Jun 10 2002 - 23:51:43 EEST
