[ubuntu-studio-devel] continued as per request, from IRC

[Kaj Ailomaa]

On Thu, Aug 20, 2015, at 10:49 PM, Len Ovens wrote:
> On Thu, 20 Aug 2015, Mike Holstein wrote:
> 
> > 15:48 < zequence> holstein: I really urge you to put your thoughts down and write
> > an email instead
> > 15:48 < holstein> well, its fashionable to not like ubuntu..  and, thats
> > something larger than ubuntustudio.. but, when folks go to #ardour, for 
> >                   example, and the major piece of advice is "whatever you do,
> > dont use ubuntustudio", i would like to think about why
> 
> That is not really true, "don't use Ubuntu" Yes I see that... and
> probably 
> with good cause. It is possible to get good results with Unity, easy to 
> get bad results. Certainly Studio sometimes just gets lumped in with 
> Ubuntu. And when suggesting a distro made for Audio, generally kxstudio
> or 
> avlinux are the two mentioned. However, I have heard UbuntuStudio 
> recommended sometimes as well. (especially lately as kxstudio has had
> some 
> issues related to KDE)
> 
> Studio has some good stuff:
>  	- xfce
>  	- a good set of applications
>  	- audio and RT allready works
> 
> On the other side:
>  	- LTS releases with sometimes the buggiest release of some
>  		required audio utilities.
>  	- LTS releases mean that by the time the next one comes out
>  		the old one is hopelessly behind. Kubuntu may have
>  		the best way of dealing with this by trying to make
>  		each release LTS-able. Anything based on debian, tends
>  		to be release based.
>  	- It is not easy to update an LTS, the policys for adding a new
>  		version for anything besides bugs is not an easy road to
>  		take.
> 
> It takes a lot of work to keep an LTS current and we just haven't been 
> able to do that. Both kx and av add the latest versions to their repos 
> within days (minutes sometimes)... they can do so because they own the 
> repos and manage them.

It's usually not that hard to do a backport. It depends on the
application. If there are a lot of dependencies that also need to be
backported, that can get complicated.

Also, for someone who is doing some kind of multimedia production
project, and not just playing with the applications might not want to
update stuff. Cause, that could lead to stuff breaking, such as not
being able to load your project files, or some other conflict.
But, that's the point with backports. They are not security updates, and
the user is able to uncheck it. However, I don't think our users are
fully aware of this, and this could become a problem should we actually
begin to backport packages.

> 
> We could set up an upgrade repo ppa, but I do not know if that is what 
> Ubuntu is all about. Ubuntu flavours are meant to use the Ubuntu repos.
>

I think we could do this in those cases where a backport is not
possible. Otherwise, we should always try to do backports first.


And for the following stuff, I think this is stuff we should make
optional and possible to adjust using -controls.
I'm going to dedicate a few weeks to that, and am really motivated to
make this happen once and for all, so I will come back to this when I
get the chance.

> Directions we could go that remain Ubuntu-ish but still make a good
> distro 
> for audio:
> 
> remove module-udev-detect from pulseaudio and run jackd as the only back 
> end. So jackdbus would start at session start and pulse would use either 
> jack or dummy as it's only backends.
> 
> Create a udev utility that replaces module-udev-detect for PA with 
> something that adds a plugged in audio IF to jack on the fly. The user in 
> -controls would be asked or allowed to determine if the new device became 
> the jack maser device or if it was added via zita-a2j/j2a. If the 
> (probably USB) new device was to be master, the internal would then get 
> added via zita-a2j/j2a.
> 
> These two things alone would make Studio unique in the Linux audio world 
> and would solve more than 50% of support requests both in ubuntuStudio
> and 
> in other places like #Ardour.
> 
> Make performance mode default with the option when battery operation is 
> detected to goto a slower speed or ondemand. (in general a slower 
> _constant_ speed is better for low latency)
> 
> Note on performance mode: I have found that performance mode runs cooler 
> at high CPU use than ondemand. Ondemand is good for mostly idle use.
> 
> Allow sw update stuff to be turned off while doing audio intensive stuff 
> (stop cron works for me).
> 
> Any place I have mentioned starting jack should include a2jmidid, using 
> a2j_control seems to be more reliable for me than using a2jmidid
> directly.
> 
> Note that this whole topic is audio only and does not address other 
> workflows in Studio. It happens to be what I know :)  Also, I have not 
> mentioned the tweaks we already do for audio which should remain.
> 
> --
> Len Ovens
> www.ovenwerks.net
> -- 
> ubuntu-studio-devel mailing list
> ubuntu-studio-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel