Downside of Ubuntu Studio -> KXStudio?

Unofficial support for the KXStudio Linux distribution and applications.
More info at http://kxstudio.linuxaudio.org/

Moderators: MattKingUSA, khz

User avatar
odonnell
Established Member
Posts: 48
Joined: Mon Apr 16, 2012 12:27 am
Location: Greater Chicago, IL

Re recommended players

Post by odonnell »

falkTX wrote:I personally recommend you to use a different music player.
Audacious is my favorite because it has decent jack support (the client+connection is persistent :D)

for video, smplayer and vlc can properly configure the audio output.
Thanks for the recommendations. I will definitely try audacious (already use audacity for editing). Rhythmbox is a legacy choice that I haven't questioned for a while. I was starting up other players mainly to test the reaction of the Alas/Jack/KXstudio configuration. :)
User avatar
odonnell
Established Member
Posts: 48
Joined: Mon Apr 16, 2012 12:27 am
Location: Greater Chicago, IL

kxstudio-welcome should not destroy user configuration

Post by odonnell »

I went through /usr/share/kxstudio/welcome/welcome.py and found a lot of configuration files that overwrote my old versions (which I still have on a separate archive). I copied my originals back with the suffix ".user.old". I think that the KXStudio welcome needs to warn about overwriting, and make sure that the step is reversible. A script to do the reversal would even be a good idea.

I took the idea of *.user.old from my memory of dpkg updates to system configuration files, which use a similar suffix, and also warn the installer and ask for a decision between the new and the old file. The unselected one gets stored with a suffix (.user.old, or .dpkg.new as I recall). I expect that there is some code already written in the dpkg package that you can copy to do the same sort of thing for the user's configuration.

I wonder now whether the KXStudio installation changed any of my previously edited system configuration files? If so, I think it should use the same conservative approach to system config files.

I also wonder how well "apt-get purge kxstudio" would work? I now suspect that it will be somewhat broken. I don't intend to do it, but such a reversal should always be available.

None of the files in question is likely to be very important to me, but this is a sort of discipline that is good to establish early in a project. Irreversibly overwriting configuration will bite someone someday, and by the time it does some configuration may have developed to a point where it's a serious problem.

To clarify the relationship with my earlier recommendation: I think that rewriting configuration can be done during installation in a conservative and reversible fashion. But it generally should not be done at all in such a fashion during the use of an application (e.g., when restarting the Jack daemon in Cadence), unless the application itself is a configuration editor/maintainer. When multiple configurations are needed, a small trigger point should be found to select between them, rather than changing them in place.
User avatar
odonnell
Established Member
Posts: 48
Joined: Mon Apr 16, 2012 12:27 am
Location: Greater Chicago, IL

Re: Downside of Ubuntu Studio -> KXStudio?

Post by odonnell »

falkTX wrote: The wizard says perfectly clear to only use force-reset in a clean install or wanting to reset everything. Even in this situation, some important config files are not overridden if they already exist.
I see it now. I either overlooked it, or forgot (the print is rather small for my eyes). My idea of a "clean install" meant a clean new system, not clean user configuration.
falkTX wrote: I don't think renaming files to *.old would be very convenient, simply because they are too many.
But a checkbox option for it can be done, what do you think?
I still favor saving all old files. I also use RCS for version control of every configuration (except when I forget :oops: ). It's easy to do "rm *.old", so I think it's better to err on the conservative side. I also favor using established code from dpkg if at all possible, for uniformity.

I confess that I find the sequence of queries from dpkg whether to use old or new configuration tiresome, and they are not presented in the most efficient way possible, but they are improving (they already offer the chance to look at diffs, or to pause and fiddle in a shell), and I think that is a good bandwagon to get on, for uniformity with other stuff and for benefit from other people improving dpkg in the future.

Having made my point, I don't want to argue at length. If you have a different experience, you must follow your best estimate of consequences. But I've been using the sequence CDC/IBM/DEC VMS/ATT Unix/BSD/Linux since the late 1960s, and I have never regretted a conservative approach to audit trails of old configuration, while I have often regretted letting old data get away :?
User avatar
odonnell
Established Member
Posts: 48
Joined: Mon Apr 16, 2012 12:27 am
Location: Greater Chicago, IL

Trying experimental .asoundrc, no cadence-aloop-daemon

Post by odonnell »

To complete the 4 possibilities {kxstudio .asoundrc | alsa-aloop .asoundrc} * {running cadence-aloop-daemon | not running daemon }, I tried using the ~/.asoundrc file provided by falkTX to use Alsa aloop, but not starting the cadence-aloop-daemon that should go with it. I assume that I would forget to start it at least once, and perhaps it could also crash.

When I started up Totem (running gstreamer-alsa) I had a bad system crash. It seemed that there was an infinite loop of something trying to start up and failing. I got a non-graphics screeen with stuff that I couldn't read in time, and a rapid series of clicks on the speakers. I had to toggle power to reboot.

It's possible that running Totem once will set up an environment in which such a crash won't happen. But for now I think I'll use Jack/Alsa with the default bridge and PulseAudio not running. I'll write about that in a separate message.
User avatar
odonnell
Established Member
Posts: 48
Joined: Mon Apr 16, 2012 12:27 am
Location: Greater Chicago, IL

I like default Jack/Alsa without PulseAudio

Post by odonnell »

I fell back to running Jack and Alsa with the default Alsa-Jack bridge, PulseAudio turned off, and controlling all through Cadence/Catia.

Now that I have configured gstreamer properly to use Alsa (couldn't get it to use Jack directly), all of the applications that I have tried work in some fashion without PulseAudio.

The applications that really understand Jack give me visible connectors on the Catia canvas, and I can make persistent connections to them. The applications that only know Alsa, or that have a less satisfying use of Jack, give me individual visible connectors in Catia, but starting/restarting an output makes the connectors disappear/reappear with connections set back to defaults.

I would like to get systematically more informative names on the connectors in Catia (some just say alsa-jack with a meaningless number), and I would like more persistent Catia-customized connections. But I am starting to suspect that much or all of the improvement needs to be done in the individual applications, rather than in a general purpose controller.

I didn't have much use for the single catch-all connection of all Alsa applications, even though it was persistent. Perhaps there is a clever way of achieving it all at the Cadence/Catia level, but I can see that some applications sometimes should drop connections and make brand new ones, so it may be best for the individual applications to decide on and implement persistent connection to Jack.

alsa_in/alsa_out seem to do just what I need in providing input and output connectors that I can manipulate in Catia. Eventually, I will probably script an automatic alsa_in/alsa_out connection for each USB device, and eventually I expect that Catia and/or other KXStudio controls will incorporate such a thing, and probably nice sets of defaults and fallbacks for connecting particular applications.

To organize the different .asoundrc configurations, I made a bunch of different ones with suffixes, and made a symbolic link named ".asoundrc" to the one I want to use at the moment:

Code: Select all

odonnell@Psammead:~$ ls -l .asound*
lrwxrwxrwx 1 odonnell odonnell   23 May  6 17:54 .asoundrc -> .asoundrc.kxstudio.dpkg
-rw-r--r-- 1 odonnell odonnell 1689 May  5 23:24 .asoundrc.aloop.exp
-rw-r--r-- 1 odonnell odonnell  287 May  4 12:00 .asoundrc.kxstudio.dpkg
-rw-r--r-- 1 odonnell odonnell   40 May 27  2011 .asoundrc.user.old
If configuration switches get to be a regular part of control through Cadence (the switch between custom and default Alsa-Jack configuration already does this on Jack restart), I would even put the individual files under a .asound directory, and look for an even less user-dependent method of switching, probably involving a change to the Alsa program that reads ~/.asoundrc.
User avatar
odonnell
Established Member
Posts: 48
Joined: Mon Apr 16, 2012 12:27 am
Location: Greater Chicago, IL

Re: Downside of Ubuntu Studio -> KXStudio?

Post by odonnell »

falkTX wrote:I personally recommend you to use a different music player.
Audacious is my favorite because it has decent jack support (the client+connection is persistent :D)
I definitely like Audacious for playing stored files. It behaves particularly well with Jack (once I configured it for Jack---it defaulted to Alsa). I haven't found the plugin for SHOUTcast/ICEcast streams. I think that it might be in audacious-plugins-extra, which didn't make it into 12.04 yet. I hope that it will come along.

I haven't yet seen how well Audacious can handle my immense music library. Database-like search can be helpful, but Rhythmbox and several other applications that are aggressive at organizing the music database have ridiculous long startups with redundant rescans. I keep my main archive on a removable USB-connected 1/2 TB device, and I have never had real good experience with the applications that sometimes find and sometimes don't find the device connected.
Post Reply