Subject: Re: [linux-audio-dev] Audio routing issues for linux..
From: Robert Jonsson (robert.jonsson_AT_dataductus.se)
Date: Mon Jun 10 2002 - 13:56:20 EEST
Hi guys,
being mainly a lurker (and (potentially) a user) I may not have a say, but anyway...
>
> No, allow me to explain better why I think supporting JACK is
> pointless and why I wouldnt do it. I'll give you all the reasons I can
> think of.
>
> 1-It's not a standard. ALSA/OSS are. If i want to write a driver, i
> will do for those.
>
> 2-If i need low latency, i'm perfect with SCHED_FIFO and low
> fragmentsize in eithe alsa/oss.
>
> 3-Device sharing is pointless for me if most other programs dont
> support JACK.
>
> 4-There's not really any useful reason I can think for my app sharing
> data with JACK apps, and i'm not going to write eveything
> jack-oriented for an API that's not really popular.
>
> 5-As I described in my previus mail, Most apps that i'd find cool that
> would support jack, just dont do.
>
> 6-If dozens of users mail me per month with problems compiling
> Cheesetracker because of misconfigured GTK installs, think of the hell
> it would be if they had to compile jack.
>
> 7-I cant use other apps transparently with JACK to alter their sound
> and re-route it.
>
> 8-I dislike the design, I really do. I think the functionality of
> audio routing must be withing alsa-lib. This makes things harder and
> more confusing for end users. Esound and arts are confusing enough,
> and adding an extra layer is worse.
>
Since I have hardly looked at Jack, and definately not tried to use it (as a
developer) I can't really comment on the design.
- Is there a contradiction between Jacks design and potentially merging it INTO
ALSA-lib ? I mean, without changing the design?
>
> For these reasons, I will not support or use JACK until something like
> it becomes part of alsa. Why? because I think jack is a mere hack to
> go around alsa/linux limitations instead of contributing to them or
> improving them. Sorry about my "rant" on JACK, I am not a driver/alsa
> programmer, I am an application programmer and I want to make things
> easy for users and for myself.
I have many times also wondered what the benefits are to NOT bundle Jack with
ALSA, I can think of some:
+ platform independence
+ no design dependencies
+ (potentially) easier to develop
but, mainly I see some downsides:
- the enduser needs one more package installed
- another runtime dependency to worry about
- harder to understand "what" goes "where", Jörn has made some nice schemantics
but the design is rather complex, a novice would not understand it.
- another framework-application to promote
- another framework-application to spread confusion for developers
- applications need specific support
The opposite has some very clear benefits:
+ one package; ALSA (technically several packages)
+ one framework to promote (both towards developers and endusers)
...I'm sure there are more
To this list it would be nice to add, ONE API also, but I'm reluctant to do
that. I lack the technical skills to verify what design routes are possible, the
callback based interface which is the chosen route may for all I know be the
best solution... I'm not the one to decide...
But, framework vice I think Jack should be renamed Alsa and made part of Alsa.
If it was possible to make it a transparent part of alsa-lib, it would be
astronomically great but then someone has to "show us the code" I suppose ;-).
Regards,
Robert
This archive was generated by hypermail 2b28 : Mon Jun 10 2002 - 14:00:14 EEST