[linux-audio-dev] What parts of Linux audio simply suck ?

[ix at replic.net]

> As I said many times It's not that I hate Linux Audio, but mainly that I 

mmh, i love it,

> believe that it is too poor
> in features/API for my taste. I tried very hard for several years to 
> make my apps play together
> with jack/alsa, but I find myself very limited in many areas as a 
> programmer and user:
> 
> -Alsa/Jack integration in timestamping is poor, syncronizing audio to 
> midi is a pain

so use Jack MIDI

> -I have no way to ask from a sequencer, the patch names available in a 
> softsynth to list them

i do this all the time, grabbing lists of automatable params and patches from my sequencer, using OSC aware apps like PD, Om etc as the LADSPA/DSSI hosts. sounds like a sequencer limitation if it's not exposing these things programatticaly for you..

> -Jack lack of midi

false..

> -Jack lack of OSC or any way to do parameter automation from the sequencer

im glad jack concentrates on audio and not "OSC parameter automation". its the UNIX way, a utility doing one thing and doing it well, but if Jack could deliver sample-accurate OSC messages in a more convenient manner than UDP, im all for it, but the UI thing you speak of is a level above that.

> -It is Impossible to do any sort of offline render, or high quality 
> render of a song (like, in 32/192khz) using JACK/Alsa

so you want to be able to run the JACK samplerate at 'infinite' or at least a high as possible until processing finishes. an interesting idea, to have offline render across the entire chain.. but last i asked about even so much as multiple samplerates or vari-speed scrub across all jack spps,  they had reasons, not the least of which was it would be useless without everyone supporting it..

> -Saving/Restoring your project is just painfully hard. LASH doesnt help, 
> and even when I came up with the idea of it in the first place.

this could be improved, but monolithic Cubase-esque hosts is not the way id prefer it to be done. personally i just have my sequencer spawn off a few shell processes coupled with rohan drape's excellent patching utils to handle app launches, while storing all the params&patches id want to recall in the sequence database..

> -Adding/Removing softsynths, linking connections, etc takes a while 
> having to use qjackctl, etc

''

> -Lack of send%.. I just cant have a jack client doing a very high 
> quality reverb, only as wet processing and have clients send different 
> amounts of the signal to it, thus saving CPU

so you want jack to do mixing + connections, instead of just connections. take it up with them, but variable wet/dry requires a 100% connection, so im not sure thats not a UI issue a level above jack too..


> -Lack of tempo-map based transport, I cant adapt my midi-only sequencer 
> , which works in bars,
> beats, etc to a frame-based transport.  Say I want to run my sequencer, 
> then go thru softsynths
> and record/edit in ardour.. no go.

confused here.. as to why it wouldnt work, other than your unwillingless to make a simple function to cnovert between beats/bars to samples..

> 
> But overall, what mostly annoys me of linux audio is that most API 
> programmers just implement
> the features THEY use and need, and not what others may need. And since 
> they mantain the thing,

is this not what the economics dictate? if someone sat down with major backing to implement a 'grand vision' API, wouldnt we be talking about Apple?

> even adding them yourself is pointless, as they will most certainly not 
> accept patches. Ok, that's

not true, even my small trivial bugfix and usability patches have been incorporated into various projects.. if youre talking about something enormous, maybe a branch is better at least until its utility/superiority/whatever is proven..

> fine, they are on their right to do it, after all i'm not paying them to 
> do it, they work for themselves.
> 
> All this has simply led me to decide to not use such APIs anymore and 
> integrate everything I do
> in big, and monolithic apps, such as reason, cubase, etc and not care 

have fun, im personally glad to get away from that..

> about the outside world anymore.
> After all, it takes me less time to write the features I need for 
> myself, and into my own than dealing with people's religious software 
> views to get them integrated into other projects.

wish i could code that fast!

> 
> Cheers!
cheers,
carmen
> 
> Juan
> 
> 
>