Galaxy 21.05 upgrade and cluster_venv

As part of my (rather prolonged) work towards a M.Sc. in bioinformatics, I maintain a Galaxy server at SANBI. I've recently upgraded to Galaxy 21.05, at the time of this writing the latest Galaxy release. You can read more about that release here.

My Galaxy server is deployed using Ansible with a combination of the standard Galaxy roles and ones developed at SANBI to match our infrastructure. Specifically, we have roles for integrating with our infrastructure's authentication, monitoring and CephFS filesystem. I also wrote a workaround for deploying letsencrypt based SSL. You can find this configuration in this repository.

The Galaxy server integrates with our cluster, the worker nodes of which are running Ubuntu 18.04 (the Galaxy server is on Ubuntu 20.04). For a number of tasks, Galaxy requires tools to have some access to Python libraries that are not part of core Python for the business of "finishing" jobs (i.e. feeding results back into Galaxy) and so on. In the past I have found that using the single virtualenv that the Galaxy roles configure on the Galaxy server causes problems when running jobs on the cluster. Thus I have a specific venv for running on the cluster that is configured on the cluster. I.e. after the Galaxy server install was completed, I logged into one of the cluster worker nodes as root, deleted the old cluster_venv and ran:

cd /projects/galaxy/pvh_masters_galaxy1
export GALAXY_VIRTUAL_ENV=$(pwd)/cluster_venv
cd server
scripts/ --skip-client-build --skip-samples

Obviously it would be better to automate the above, but I have not got around to doing so yet. I'm not sure if this is the best approach but it works at least for our environment, so I'm writing this blog post in case it is useful to others (or to jog my own memory down the line!). This cluster_venv setup is exposed to the job runners in job_conf.xml - here is a snippet of my configuration:

    <plugins workers="4">
        <plugin id="local" type="runner" load=""/>
        <plugin id="slurm" type="runner" load=""/>
    <destinations default="dynamic">
        <destination id="slurm" runner="slurm">
            <param id="tmp_dir">True</param>
            <env id="GALAXY_VIRTUAL_ENV">/projects/galaxy/pvh_masters_galaxy1/cluster_venv</env>
            <env id="GALAXY_CONFIG_FILE">/projects/galaxy/pvh_masters_galaxy1/config/galaxy.yml</env>
        <destination id="local" runner="local"/>
        <destination id="dynamic" runner="dynamic">
            <param id="tmp_dir">True</param>
            <param id="type">dtd</param>
        <destination id="cluster_default" runner="slurm">
            <param id="tmp_dir">True</param>
            <env id="SLURM_CONF">/tools/admin/slurm/etc/slurm.conf</env>
            <env id="GALAXY_VIRTUAL_ENV">/projects/galaxy/pvh_masters_galaxy1/cluster_venv</env>
            <env id="GALAXY_CONFIG_FILE">/projects/galaxy/pvh_masters_galaxy1/config/galaxy.yml</env>
            <param id="nativeSpecification">--mem=10000</param>
            <resubmit condition="memory_limit_reached" destination="cluster_20G" />

P.S. this was the only manual task I had to perform (on the Galaxy side of things). Mostly the update consisted of updating our SANBI ansible roles to support Ubuntu 20.04 (and Ceph octopus), switching to the latest roles (as described in the training material for Galaxy admins), flicking the version number from release_20.09 to release_21.05 and running the Ansible playbook.

Solving Bluetooth Audio Delay on Ubuntu 20.04

For quite some time I've been frustrated at the state of Ubuntu's support for Bluetooth audio. As a result, I've always gone with wired headphones. Now maybe its something about me but I've not had the best of luck with this. Headphones last a few months before some plug or wire breaks. In the worst case scenario the headphone jack on my laptop starts giving issues... so wireless is great. If it works.

I had to replace my headset recently and bought a HAVIT H2590BT, a fairly entry-level thing, and it worked fine for listening to music but as soon as I wanted more "real time" audio there were problems. I first noticed this on Duolingo and a bit of debugging showed that the problem was a delay in the audio. This became rather embarasing when doing a call with colleagues.

Turns out that Bluetooth has audio profiles that affect the operation of the headset. A2DP focuses on giving best audio quality, whereas HFP and HSP are more focused on real-time responsiveness. Unfortunately with the standard PulseAudio (13.99.1) on my Ubuntu 20.04 I could only connect to the headphones using A2DP. I came across posts on from 2015 onwards talking about this issue and some suggested switching profiles but I couldn't seem to get that right.

Then I found this post from @normankev141. Unfortunately the plugin that he suggested has been deprecated by the author, who suggested moving to PipeWire. I switched to PipeWire using the instructions from this askubuntu post, rebooted and now I've got a much richer selection of profiles:

$ pactl list cards
Card #54
Name: bluez_card.C5_78_21_3A_9F_DB
Driver: module-bluez5-device.c
Owner Module: n/a
    off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
    a2dp-sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 0, available: yes)
    headset-head-unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 0, available: yes)
    a2dp-sink-sbc: High Fidelity Playback (A2DP Sink, codec SBC) (sinks: 1, sources: 0, priority: 0, available: yes)
    headset-head-unit-cvsd: Headset Head Unit (HSP/HFP, codec CVSD) (sinks: 1, sources: 1, priority: 0,    available: yes)
Active Profile: a2dp-sink-sbc

I can now switch profiles with pactl set-card-profile bluez_card.C5_78_21_3A_9F_DB a2dp-sink or pactl set-card-profile bluez_card.C5_78_21_3A_9F_DB headset-head-unit. I've made these two aliases for my shell:

alias goodaudio="pactl set-card-profile $(pactl list cards |grep 'Name: bluez' |awk '{print $2}') a2dp-sink"
alias headset="pactl set-card-profile $(pactl list cards |grep 'Name: bluez' |awk '{print $2}') headset-head-unit"

I haven't yet got around to linking these to some kind of Gnome utility so that I can toggle the profiles yet. Its on the TODO list.