Forem: chama-chomo

Lyrion Music Server - A Comprehensive Solution for Home Music Listening

chama-chomo — Tue, 27 Jan 2026 20:31:33 +0000

I would like to introduce you to a somewhat lesser-known, yet in my opinion unjustly overlooked solution for music listening – whether from local storage or through paid streaming services.

Setting up LMS may seem not entirely trivial at first and requires some time to gather the necessary information and understand the entire architecture. Therefore, I decided to try to describe how I use this seemingly complex system at first glance.

While setting up LMS is not entirely trivial and requires some time, I believe my overview will motivate you to try this community-driven open-source solution that I use for listening through both headphones and speakers.

Note: In this presentation, I focus exclusively on the LMS ecosystem. Other components of the audio chain (DAC, amplifier, headphones...) are intentionally omitted for clarity.

LMS SERVICE SETUP (NETWORK LAYER/SERVER)

The core of the entire solution is Lyrion Music Server (LMS) – an open-source implementation of the former Squeezebox platform. It features an extensive ecosystem of compatible clients, modular extensions, and user interfaces (more at https://lyrion.org).

System Architecture:

LMS utilizes a distributed client-server architecture:

Server layer – a service running on a computing node (PC/NAS) that manages the music library and aggregates access to streaming platforms as well as locally stored files. It does not require direct physical connection to the audio chain.
Client layer – a software renderer that initiates requests for streamed data and transforms it into a digital audio signal directed to the end audio device (DAC, active speakers, DSP...).

Implementation in my environment:

Since I personally use the TrueNAS system for my home storage, it was a natural choice for me to install LMS directly on this device. TrueNAS offers LMS in its native application repository, which greatly simplifies the entire installation – there's no need to handle dependencies or manual service configuration.

For alternative operating systems, comprehensive documentation is available: https://lyrion.org/getting-started/

The configuration involved defining paths to music files stored within the same storage system.

INTERFACE SETUP FOR AUDIO CHAIN INTEGRATION (CLIENT)

The LMS ecosystem offers a wide range of hardware and software clients capable of receiving audio streams from the server and integrating into the existing audio chain as a full-fledged digital source.

Squeezelite – headless software renderer

In my implementation, I use the squeezelite application (https://lyrion.org/players-and-controllers/squeezelite)

Squeezelite is a minimalist headless client (i.e., an application without a graphical interface); squeezelite can work as a service "invisibly" in the background of the system.

This application enables the transmission of digital signal, for example, via USB interface directly to a D/A converter (i.e., a device that converts digital signal to analog for headphones/speakers), while supporting advanced settings for techniques such as upsampling, frequency filtering, and precise control over audio buffers.

Some advantages of this solution:

Minimal system requirements – consumes less CPU and RAM
Elimination of interfering processes
Stability
Advanced configuration

Real Configuration Example

To illustrate the configuration possibilities of squeezelite, I'm showing my current initialization script:

#!/bin/sh
exec 2>&1
iw dev wlp3s0 set power_save off # deactivate WiFi card power saving mode to ensure stable connection

exec /opt/lms/player/squeezelite -o hw:CARD=DX9 -a 100:4:: -b 40000:400000 -p 45 -c flac,pcm,mp3 -r 352800 -R -u v:1A:1:32:95.4:104.6:46 >/var/log/squeezelite.log 2>&1

Brief explanation of individual parameters:

Audio output configuration:
- -o hw:CARD=DX9 – direct communication with audio device via ALSA (Advanced Linux Sound Architecture). This approach bypasses the system audio mixer, ensuring so-called bit-perfect transmission (if required) – audio data reaches the DAC exactly in the format in which it was originally stored, without any modifications.
Buffer management:
- -a 100:4:: – audio buffer settings (initial size : period : format : mmap)
- -b 40000:400000 – stream buffer (40MB output : 400MB input). A larger buffer means greater resistance to temporary fluctuations in network connection (so-called network jitter).
- -p 45 – process priority. A higher value ensures that the operating system gives this process priority over others, minimizing the risk of audio underruns (a situation when the buffer empties and music is necessarily interrupted).
Codec and sample rate:
- -c flac,pcm,mp3 – supported audio formats in order of preference
- -r 352800 – maximum supported sampling frequency (sample rate) 352.8 kHz; higher value theoretically means higher quality.
- -R – activation of resampling if needed
Upsampling configuration:
- The goal is to move demanding digital processing outside the DAC and provide it with already "prepared" data.
- -u v:1A:1:32:95.4:104.6:46 – upsampling algorithm definition

The upsampling conversions in this case will look like below:

96kHz → 192kHz
44kHz → 352kHz
88kHz → 352kHz
192kHz → 192kHz (passed through)

For detailed parameter configuration, I recommend studying: https://archimago.blogspot.com/2017/12/howto-musings-playing-with-digital_23.html

I use Squeezelite in two different configurations depending on the type of listening:

Headphone listening:

Passively cooled miniPC (HP T640) with a minimalist Linux distribution and squeezelite running in the background. Connection to the server is wireless, connection to the audio system is via USB interface to the D/A converter. The system is configured to activate automatic sleep when no connected D/A converter is detected, so the PC has minimal maintenance requirements.

Speaker listening:

Dedicated network streamer Holo Audio Red (https://kitsunehifi.com/products/holoaudio-red-ddc-network-streamer-1).

Connection to the audio system is also via USB interface to the D/A converter. For connection to the LMS server, I use LAN via a standard network cable.

The original operating system is replaced with piCorePlayer distribution (https://www.picoreplayer.org/landingzone_option1.html) – a dedicated system for audio applications compatible with the device's RPi architecture. This approach again allows me to utilize the advanced settings offered by squeezelite, i.e., custom DSP settings, filter curves, and upsampling methods.

CONTROL AND USER INTERFACES

I would like to emphasize that both mentioned variants (miniPC and Holo Red) represent purely headless solutions – applications without their own graphical interface. For actual control, music selection, and metadata display (information about album, artist, cover art...), I use:

Material UI – web interface

A modern responsive web interface running directly on the server, accessible from any device with a web browser. It is one of the most popular community interfaces for LMS, offering:

Intuitive navigation in the music library
Multi-room support (each client can play different content)
Display of advanced metadata and visualizations
Playlist and playback queue management
Responsive design optimized for mobile devices

The 'Material UI' web user interface provided by my NAS, where LMS provides this interface in my case at the address http://mynasserver.local:31101/

If multiple clients are detected, you can choose what content to play on each one separately.

A brief presentation of the 'Material' web interface...

XTUNE Player for iOS

In the second case, I often use an application created for the iOS ecosystem called XTune (https://x-music.app/en)

Although it is paid, the developer continuously improves it and provides one of the highest quality mobile interfaces within the LMS ecosystem. Of course, various more or less successful applications are available for different platforms (iOS, Android, Linux, Web, etc.).

COMMUNITY EXTENSIONS

An undeniable advantage of LMS architecture is the ability to use community plugins. I personally use several of them, which in my opinion can often provide comfort comparable to other, even commercial and professional solutions, but without the monthly fees associated with these services.

Therefore, I would like to dwell on some of these extensions.

1. Streaming Platform Integration

LMS allows extension with support for additional streaming services (Tidal, Qobuz...). Configuration is straightforward – in most cases, it's enough to install the appropriate plugin and provide login credentials for the given platform.

Note on Tidal integration: The Tidal implementation via LMS unfortunately does not yet support playback of music files in full Hi-Res quality, but sufficient lossless quality is still available.

2. Material Skin – advanced web interface

As already mentioned, Material UI represents one of the most popular web interfaces for LMS with modern design and rich customization options.

Key features:

Responsive design optimized for desktops, tablets, and mobile devices
Multi-room playback support with independent control of individual clients
Visualization of metadata, album covers, and artists
Advanced playlist and playback queue management
Theme customization options

3. SqueezeDSP – parametric equalizer

I came across this extension relatively recently, but it ranks among my most valuable extensions. SqueezeDSP provides a full-featured parametric equalizer (PEQ – Parametric Equalizer) integrated directly into the LMS architecture.

What is a parametric equalizer?

PEQ is a tool enabling precise correction of audio signal frequency characteristics. Unlike simple "bass/treble" controls, PEQ offers:

Precise control over specific frequencies (for example, 1.2 kHz)
Adjustment of the affected frequency band width (so-called Q factor)
Setting the gain or attenuation level in decibels (±dB)
Ability to create complex filter curves with multiple correction points

Installation:

SqueezeDSP requires several system dependencies (libraries for DSP processing), but the installation itself is not complicated and is well documented within the official LMS plugin repository.

In my case, I use SqueezeDSP primarily for correcting the frequency characteristics of headphones.

TIP: SqueezeDSP supports importing ready-made EQ profiles from the squig.link service (https://squig.link/)

Configuration example:

This is what the final form of the DSP extension looks like in practice – in my case, a full-featured parametric equalizer optimized for the headphones used:

CONCLUSION

I hope my journey has inspired you to at least try LMS. If you have any questions, feel free to contact me.

Happy listening!

Setting up neovim for web development in Golang

chama-chomo — Thu, 26 Sep 2024 08:02:49 +0000

Since I primarily use Neovim for all my development, configuring my environment for comfortable development of my new web project wasn't a quick task. I've decided to share my experience in hopes that it helps others get started as quickly as possible.

The main topics I want to cover are:

Neovim LSP and Treesitter updates
Templ formatting configuration
TailwindCSS configuration
Enabling HTMX in the project
Setting up file watchers

As for the structure of my project, I simply follow conventions.

Neovim LSP and Treesitter updates

To make the LSP aware of Templ files, I had to introduce a few changes to the "lspconfig." However, before doing that, I needed to ensure that all the necessary components would be installed automatically. For this, we use Mason:

    ensure_installed = {
        "templ",
        "html",
        "htmx",
        "tailwindcss",
        "html",
        "cssls",
        "efm",
        "gopls",
    },

Now, we are ready to update the 'lspconfig' configuration:

    -- templ
    lspconfig.templ.setup({
        capabilities = capabilities,
        on_attach = on_attach,
    })

    -- html
    lspconfig.html.setup({
        on_attach = on_attach,
        capabilities = capabilities,
        filetypes = { "html", "templ" },
    })

    -- htmx
    lspconfig.htmx.setup({
        on_attach = on_attach,
        capabilities = capabilities,
        filetypes = { "html", "templ" },
    })

    -- tailwindcss
    lspconfig.tailwindcss.setup({
        on_attach = on_attach,
        capabilities = capabilities,
        filetypes = { "templ", "astro", "javascript", "typescript", "react" },
        init_options = { userLanguages = { templ = "html" } },
        settings = {
            tailwindCSS = {
                includeLanguages = {
                    templ = "html",
                },
            },
        },

For proper semantic highlighting provided by Treesitter, I installed the following TS plugins:

ensure_installed = {
            "javascript",
            "go",
            "html",
            "templ",
            "css",
        },

Templ formatting

This was possibly the most complicated part to automate. Through EFM, I was unable to get the LSP to trigger formatting specifically for Templ files (format on save). I suspect this might be because multiple LSP servers are running for Templ files, which may confuse the LSP.

After some struggle, I decided to offload this operation to another plugin called 'conform.'

I installed the 'conform' plugin in my editor.

Below is my 'conform' configuration:

return {
    "stevearc/conform.nvim",
    opts = {
        formatters_by_ft = {
            templ = { "templ" },
        },
    },
    config = function()
        require("conform").setup({
            format_on_save = {
                timeout_ms = 500,
                lsp_format = "fallback",
            },
        })
    end,
}

Once set up, it's time to make 'format on save' for Templ files semi-automatic using 'autocmd.'

Insert the following snippet somewhere in your Lua config:

-- conform format
vim.api.nvim_create_autocmd("BufWritePre", {
    pattern = "*.templ",
    callback = function(args)
        require("conform").format({ bufnr = args.buf })
    end,
})

Originally the pattern part looked like this:
pattern = "*."
However, I experienced some formatting issues in my Go files, so I tried to be more specific. While I'm not convinced that these problems were solely caused by this change, I no longer experience such issues (perhaps it was just a coincidence).

TailwindCSS configuration

As for TailwindCSS, the setup has been quite straightforward. I simply followed the installation manual. Just make sure that 'lspconfig' is aware of 'tailwindcss,' as described in the LSP setup section.

Enabling htmx inside the project

This part is also quite straightforward. To enable HTMX in your project, import the HTMX library from a CDN. In my case, I included it in my base.templ file:

<head>
  <title>MyProject</title>
  <link rel="icon" type="image/x-icon" href="/public/favicon.ico" />
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <link rel="stylesheet" href="/public/styles.css" />
  <script src="https://unpkg.com/htmx.org@1.9.9" defer></script>
</head>

Setting up file watchers

Here’s a refined version of that section:

An important part of the workflow is ensuring that all my edited files are being watched for changes, so that my web project gets updated 'on-the-fly.'

We need to watch for:

TailwindCSS changes
Go file changes
Templ changes

Optionally, you can include all file-watching commands in your Makefile.

.PHONY: build
build: tailwind-build templ-gen
    @go build -o bin/app .

.PHONY: tailwind-watch
tailwind-watch:
    npx tailwindcss -i views/css/app.css -o public/styles.css --watch

.PHONY: tailwind-build
tailwind-build:
    npx tailwindcss -i views/css/app.css -o public/styles.min.css --minify

.PHONY: templ-watch
templ-watch:
    templ generate --watch

.PHONY: templ-gen
templ-gen:
    templ generate

For each part, there is a specific way to set up the watcher.

tailwind watcher

npx tailwindcss -i views/css/app.css -o public/styles.css --watch

For production you might want to run with --minify flag, not --watch

Go watcher

To detect changes in standard Go files, we can use the 'AIR' tool. Follow the fairly simple AIR manual. Essentially, all I had to do was execute air init inside the project to create the config file, and I updated it if needed. Finally, executing the air command should suffice.

My configuration for reference:

root = "."
tmp_dir = "tmp"

[build]
  bin = "./tmp/main"
  cmd = "go build -tags dev -o ./tmp/main ."

  delay = 20
  exclude_dir = ["assets", "tmp", "vendor"]
  exclude_file = []
  exclude_regex = [".*_templ.go"]
  exclude_unchanged = false
  follow_symlink = false
  full_bin = ""
  include_dir = []
  include_ext = ["go", "tpl", "tmpl", "templ", "html"]
  kill_delay = "0s"
  log = "build-errors.log"
  send_interrupt = false
  stop_on_error = true

[color]
  app = ""
  build = "yellow"
  main = "magenta"
  runner = "green"
  watcher = "cyan"

[log]
  time = false

[misc]
  clean_on_exit = false

Templ changes

'Templ' tooling provides a convenient way for .templ files monitoring inside your project
templ generate --watch

For production, you may want to run just templ generate without the --watch flag; otherwise, after running your binary, you might encounter some errors about missing files.

Conclusion

Thank you for reading! If you come across any inaccuracies or if you would like to delve deeper into any topic, please feel free to contact me. I welcome your feedback and insights.

Let me know if you'd like any adjustments!

How to Debug Golang app running in K8S (Okteto) using Neovim

chama-chomo — Sat, 29 Oct 2022 09:26:18 +0000

Introduction

Since it is fairly complicated to achieve state described in a title, I've decided to create this post and share my findings. Without too much splattering around, let's right jump to it.

Please note, I'm not going to describe all technologies I use in my workflow. Since this is quite specific topic, I assume everyone to be on the same wave.

What we need to make remote debugging in Neovim real:

delve debugger installed in Okteto's container (this is where our application will be running
Neovim >= 0.8.0
set of DAP plugins to be installed for Neovim

Kubernetes (Okteto) part

In order to replace original container with our development container, let's create a manifest for Okteto first.

In my case it looks like this (your may vary, of course):

name: t-s-generator
build:
  t-s-generator:
    image: golang:1.18-alpine3.14
    dockerfile: ./Dockerfile

deploy:
  - <replace by the command you use to deploy your app in k8s>

dev:
  t-s-generator:
    sync:
      rescanInterval: 15
      folders:
        - t-s-generator:/t-s-generator
    forward:
      - 8080:8080
      - 38697:38697  # this port definition is important, it's  port we are going to use for our debugger running inside Okteto and we need to have it accessible from our local PC, so our DAP client can connect to it

Once we have Okteto environment set up for our GO application and we're able to execute okteto up successfully, we need to prepare application's binary, so it can be inspected by the debugger.
This is done by compiling our code with some specific parameters. I do it by running below command on my local PC, where my go.mod can be normally found.

GOOS=linux GOARCH=amd64 go build -gcflags=all="-N -l" .

As you can see, I'm creating a binary that can run inside K8S container, which is Alpine Linux in my case, that's why all these Linux related flags. However, those gcflags are important at the moment.

Since we're syncing our local folder with code with container's remote folder, this binary should appear also in our dev container inside K8S, once created.

Okteto set up, binary ready, the next step is to install and run our debugger in a dev container:

...
✓  Images successfully pulled
✓  Files synchronized
    Context:   kg01.i2.w.com
    Namespace: chama-chomo
    Name:      t-s-generator
    Forward:   8080 -> 8080
               38697 -> 38697
/app # go install github.com/go-delve/delve/cmd/dlv@latest
       ...
       ..
       .
/app # dlv dap -l 127.0.0.1:38697 --log --log-output="dap"
DAP server listening at: 127.0.0.1:38697
...

At this stage, we're ready to proceed with debug client setup inside Neovim.

Neovim part

I'm not going to describe how to install plugins in Neovim, I'll leave it up to you, use your preferred way. As I use Astronvim for configuring Neovim, I'm going to outline exactly what I have inserted into plugins table in init.lua:

  plugins = {
    init = {
      { "mfussenegger/nvim-dap" },
      {
        "rcarriga/nvim-dap-ui",
        config = function() require("dapui").setup() end,
      },
      {
        "theHamsta/nvim-dap-virtual-text",
        config = function() require("nvim-dap-virtual-text").setup() end,
      },
...
..
.

Above plugins have certain prerequisites, such as Treesitter etc., please make sure you have all of them installed.

DAP configuration

For using DAP in Neovim we need to configure DAP 'configurations' and 'adapters'. I personally prefer creating one wrapper function that I named DapDebug(), where I set up all previously mentioned and additionally call real DAP client at the end.

Please note, that for specifying binary that is supposed to be inspected I use an anonymous function that interactively asks for a binary path.

local dap = require "dap"

function DapDebug()
  dap.configurations.go = {
    {
      type = "delve",
      name = "Debug (Remote binary)",
      request = "launch",
      mode = "exec",
      hostName = "127.0.0.1",
      port = "38697",
      program = function()
        local argument_string = vim.fn.input "Path to binary: "
        vim.notify("Debugging binary: " .. argument_string)
        return vim.fn.split(argument_string, " ", true)[1]
      end,
    },
  }

  -- we want to run delve manually
  dap.adapters.delve = {
    type = "server",
    host = "127.0.0.1",
    port = 38697,
  }

  require("dap").continue()
end

Even though it is fully optional, I've set few key bindings for interacting with debugger inside Neovim. I will share them for you, so you can create your own set of bindings as you like.

      ["<leader>ds"] = { "<cmd>lua DapDebug()<CR>", desc = "start-dap-debugger" },
      ["<leader>dC"] = { "<cmd>lua require('dapui').close()<CR>", desc = "close-dap-ui" },
      ["<leader>dT"] = { "<cmd>lua require('dapui').toggle()<CR>", desc = "toggle-dap-ui" },
      ["<leader>dO"] = { "<cmd>lua require('dapui').open()<CR>", desc = "open-dap-ui" },
      ["<leader>dc"] = { "<cmd> lua require'dap'.continue()<CR>", desc = "dap-continue" },
      ["<leader>do"] = { "<cmd> lua require'dap'.step_over()<CR>", desc = "dap-step-over" },
      ["<leader>di"] = { "<cmd> lua require'dap'.step_into()<CR>", desc = "dap-step-into" },
      ["<leader>du"] = { "<cmd> lua require'dap'.step_out()<CR>", desc = "dap-step-out" },
      ["<leader>db"] = { "<cmd>lua require'dap'.toggle_breakpoint()<CR>", desc = "set-breakpoint" },
      ["<leader>"] = {
        "<cmd>lua require'dap'.set_breakpoint(vim.fn.input('breakpoint condition: '))<CR>",
        desc = "set-conditional-breakpoint",
      },

Running debugger

In this part I wanted share with you how debugging session in Neovim for the application deployed in Kubernetes (using Okteto) may look like. Enjoy the fruits!

starting debugging session with :lua DapDebug()

it's going to ask to provide where the binary is located on the remote side

and finally..