planet.linuxaudio.org

April 25, 2024

News – Ubuntu Studio

Ubuntu Studio 24.04 LTS Released

The Ubuntu Studio team is pleased to announce the release of Ubuntu Studio 24.04 LTS, code-named “Noble Numbat”. This marks Ubuntu Studio’s 34th release. This release is a Long-Term Support release and as such, it is supported for 3 years (36 months, until April 2027).

Since it’s just out, you may experience some issues, so you might want to wait a bit before upgrading. Please see the release notes for a more complete list of changes and known issues. Listed here are some of the major highlights.

You can download Ubuntu Studio 24.04 LTS from our download page.

Special Notes

The Ubuntu Studio 24.04 LTS disk image (ISO) exceeds 4 GB and cannot be downloaded to some file systems such as FAT32 and may not be readable when burned to a standard DVD. For this reason, we recommend downloading to a compatible file system. When creating a boot medium, we recommend creating a bootable USB stick with the ISO image or burning to a Dual-Layer DVD.

Minimum installation media requirements: Dual-Layer DVD or 8GB USB drive.

Images can be obtained from this link: https://cdimage.ubuntu.com/ubuntustudio/releases/24.04/beta/

Full updated information, including Upgrade Instructions, are available in the Release Notes.

Please note that upgrading from 22.04 before the release of 24.04.1, due August 2024, is unsupported.

Upgrades from 23.10 should be enabled within a month after release, so we appreciate your patience.

New This Release

All-New System Installer

In cooperation with the Ubuntu Desktop Team, we have an all-new Desktop installer. This installer uses the underlying code of the Ubuntu Server installer (“Subiquity”) which has been in-use for years, with a frontend coded in “Flutter”. This took a large amount of work for this release, and we were able to help a lot of other official Ubuntu flavors transition to this new installer.

Be on the lookout for a special easter egg when the graphical environment for the installer first starts. For those of you who have been long-time users of Ubuntu Studio since our early days (even before Xfce!), you will notice exactly what it is.

PipeWire 1.0.4

Now for the big one: PipeWire is now mature, and this release contains PipeWire 1.0. With PipeWire 1.0 comes the stability and compatibility you would expect from multimedia audio. In fact, at this point, we recommend PipeWire usage for both Professional, Prosumer, and Everyday audio needs. At Ubuntu Summit 2023 in Riga, Latvia, our project leader Erich Eickmeyer used PipeWire to demonstrate live audio mixing with much success and has since done some audio mastering work using it. JACK developers even consider it to be “JACK 3”.

PipeWire’s JACK compatibility is configured to use out-of-the-box and is zero-latency internally. System latency is configurable via Ubuntu Studio Audio Configuration.

However, if you would rather use straight JACK 2 instead, that’s also possible. Ubuntu Studio Audio Configuration can disable and enable PipeWire’s JACK compatibility on-the-fly. From there, you can simply use JACK via QJackCtl.

With this, we consider audio production with Ubuntu Studio so mature that it can now rival operating systems such as macOS and Windows in ease-of-use since it’s ready to go out-of-the-box.

Deprecation of PulseAudio/JACK setup/Studio Controls

Due to the maturity of PipeWire, we now consider the traditional PulseAudio/JACK setup, where JACK would be started/stopped by Studio Controls and bridged to PulseAudio, deprecated. This configuration is still installable via Ubuntu Studio Audio Configuration, but we do not recommend it. Studio Controls may return someday as a PipeWire fine-tuning solution, but for now it is unsupported by the developer. For that reason, we recommend users not use this configuration. If you do, it is at your own risk and no support will be given. In fact, it’s likely to be dropped for 24.10.

Ardour 8.4

While this does not represent the latest release of Ardour, Ardour 8.4 is a great release. If you would like the latest release, we highly recommend purchasing one-time or subscribing to Ardour directly from the developers to help support this wonderful application. Also, for that reason, this will be an application we will not directly backport. More on that later.

Ubuntu Studio Audio Configuration

Ubuntu Studio Audio Configuration has undergone a UI overhaul and contains the ability to start and stop a Dummy Audio Device which can also be configured to start or stop upon login. When assigned as the default, this will free-up channels that would normally be assigned to your system audio to be assigned to a null device.

Meta Package for Music Education

In cooperation with Edubuntu, we have created a metapackage for music education. This package is installable from Ubuntu Studio Installer and includes the following packages:

  • FMIT: Free Musical Instrument Tuner, a tool for tuning musical Instruments (also included by default)
  • GNOME Metronome: Exactly what it sounds like (pun unintended): a metronome.
  • Minuet: Ear training for intervals, chords, scales, and more.
  • MuseScore: Create, playback, and print sheet music for free (this one is no stranger to the Ubuntu Studio community)
  • Piano Booster: MIDI player/game that displays musical notes and teaches you how to play piano, optionally using a MIDI keyboard.
  • Solfege: Ear training program for harmonic and melodic intervals, chords, scales, and rhythms.

New Artwork

Thanks to the work of Eylul and the submissions to the Ubuntu Studio Noble Numbat Wallpaper Contest, we have a number of wallpapers to choose from and a new default wallpaper.

Deprecation of Ubuntu Studio Backports Is In Effect

As stated in the Ubuntu 23.10 Release Announcement, the Ubuntu Studio Backports PPA is now deprecated in favor of the official Ubuntu Backports repository. However, the Backports repository only works for LTS releases and for good reason. There are a few requirements for backporting:

  • It must be an application which already exists in the Ubuntu repositories
  • It must be an application which would not otherwise qualify for a simple bugfix, which would then qualify it to be a Stable Release Update. This means it must have new features.
  • It must not rely on new libraries or new versions of libraries.
  • It must exist within a later supported release or the development release of Ubuntu.

If you have a suggestion for an application for which to backport that meets those requirements, feel free to join and email the Ubuntu Studio Users Mailing List with your suggestion with the tag “[BPO]” at the beginning of the subject line. Backports to 22.04 LTS are now closed and backports to 24.04 LTS are now open. Additionally, suggestions must pertain to Ubuntu Studio and preferably must be applications included with Ubuntu Studio. Suggestions can be rejected at the Project Leader’s discretion.

One package that is exempt to backporting is Ardour. To help support Ardour’s funding, you may obtain later versions directly from them. To do so, please one-time purchase or subscribe to Ardour from their website. If you wish to get later versions of Ardour from us, you will have to wait until the next regular release of Ubuntu Studio, due in October 2024.

We’re back on Matrix

You’ll notice that the menu links to our support chat and on our website will now take you to a Matrix chat. This is due to the Ubuntu community carving its own space within the Matrix federation.

However, this is not only a support chat. This is also a creativity discussion chat. You can pass ideas to each other and you’re welcome to it if the topic remains within those confines. However, if a moderator or admin warns you that you’re getting off-topic (or the intention for the chat room), please heed the warning.

This is a persistent connection, meaning if you close the window (or chat), it won’t lose your place as you may only need to sign back in to resume the chat.

Frequently Asked Questions

Q: Does Ubuntu Studio contain snaps?
A: Yes. Mozilla’s distribution agreement with Canonical changed, and Ubuntu was forced to no longer distribute Firefox in a native .deb package. We have found that, after numerous improvements, Firefox now performs just as well as the native .deb package did.

Thunderbird also became a snap during this cycle for the maintainers to get security patches delivered faster.

Additionally, Freeshow is an Electron-based application. Electron-based applications cannot be packaged in the Ubuntu repositories in that they cannot be packaged in a traditional Debian source package. While such apps do have a build system to create a .deb binary package, it circumvents the source package build system in Launchpad, which is required when packaging for Ubuntu. However, Electron apps also have a facility for creating snaps, which can be uploaded and included. Therefore, for Freeshow to be included in Ubuntu Studio, it had to be packaged as a snap.

Q: Will you make an ISO with {my favorite desktop environment}?
A: To do so would require creating an entirely new flavor of Ubuntu, which would require going through the Official Ubuntu Flavor application process. Since we’re completely volunteer-run, we don’t have the time or resources to do this. Instead, we recommend you download the official flavor for the desktop environment of your choice and use Ubuntu Studio Installer to get Ubuntu Studio – which does *not* convert that flavor to Ubuntu Studio but adds its benefits.

Q: What if I don’t want all these packages installed on my machine?
A: Simply use the Ubuntu Studio Installer to remove the features of Ubuntu Studio you don’t want or need!

Looking Toward the Future

Plasma 6

Ubuntu Studio, in cooperation with Kubuntu, will be switching to Plasma 6 during the 24.10 development cycle. Likewise, Lubuntu will be switching to LXQt 2.0 and Qt 6, so the three flavors will be cooperating to do the move.

New Look

Ubuntu Studio has been using the same theming, “Materia” (except for the 22.04 LTS release which was a re-colored Breeze theme) since 19.04. However, Materia has gone dead upstream. To stay consistent, we found a fork called “Orchis” which seems to match closely and will be switching to that. More on that soon.

Minimal Installation

The new system installer has the capability to do minimal installations. This was something we did not have time to implement this cycle but intend to do for 24.10. This will let users install a minimal desktop to get going and then install what they need via Ubuntu Studio Installer. This will make a faster installation process but will not make the installation .iso image smaller. However, we have an idea for that as well.

Minimal Installation .iso Image

We are going to research what it will take to create a minimal installer .iso image that will function much like the regular .iso image minus the ability to install everything and allow the user to customize the installation via Ubuntu Studio Installer. This should lead to a much smaller initial download. Unlike creating a version with a different desktop environment, the Ubuntu Technical Board has been on record as saying this would not require going through the new flavor creation process. Our friends at Xubuntu recently did something similar.

Get Involved!

A wonderful way to contribute is to get involved with the project directly! We’re always looking for new volunteers to help with packaging, documentation, tutorials, user support, and MORE! Check out all the ways you can contribute!

Our project leader, Erich Eickmeyer, is now working on Ubuntu Studio at least part-time, and is hoping that the users of Ubuntu Studio can give enough to generate a monthly part-time income. Your donations are appreciated! If other distributions can do it, surely we can! See the sidebar for ways to give!

Special Thanks

Huge special thanks for this release go to:

  • Eylul Dogruel: Artwork, Graphics Design
  • Ross Gammon: Upstream Debian Developer, Testing, Email Support
  • Sebastien Ramacher: Upstream Debian Developer
  • Dennis Braun: Upstream Debian Developer
  • Rik Mills: Kubuntu Council Member, help with Plasma desktop
  • Scarlett Moore: Kubuntu Project Lead, help with Plasma desktop
  • Zixing Liu: Simplified Chinese translations in the installer
  • Simon Quigley: Lubuntu Release Manager, help with Qt items, Core Developer stuff, keeping Erich sane and focused
  • Steve Langasek: Help with livecd-rootfs changes to make the new installer work properly.
  • Dan Bungert: Subiquity, seed fixes
  • Dennis Loose: Ubuntu Desktop Provision (installer)
  • Lukas Klingsbo: Ubuntu Desktop Provision (installer)
  • Len Ovens: Testing, insight
  • Wim Taymans: Creator of PipeWire
  • Mauro Gaspari: Tutorials, Promotion, and Documentation, Testing, keeping Erich sane
  • Krytarik Raido: IRC Moderator, Mailing List Moderator
  • Erich Eickmeyer: Project Leader, Packaging, Development, Direction, Treasurer

A Note from the Project Leader

When I started out working on Ubuntu Studio six years ago, I had a vision of making it not only the easiest Linux-based operating system for content creation, but the easiest content creation operating system… full-stop.

With the release of Ubuntu Studio 24.04 LTS, I believe we have achieved that goal. No longer do we have to worry about whether an application is JACK or PulseAudio or… whatever. It all just works! Audio applications can be patched to each other!

If an audio device doesn’t depend on complex drivers (i.e. if the device is class-compliant), it will just work. If a user wishes to lower the latency or change the sample rate, we have a utility that does that (Ubuntu Studio Audio Configuration). If a user wants to have finer control use pure JACK via QJackCtl, they can do that too!

I honestly don’t know how I would replicate this on Windows, and replicating on macOS would be much harder without downloading all sorts of applications. With Ubuntu Studio 24.04 LTS, it’s ready to go and you don’t have to worry about it.

Where we are now is a dream come true for me, and something I’ve been hoping to see Ubuntu Studio become. And now, we’re finally here, and I feel like it can only get better.

-Erich Eickmeyer

by eeickmeyer at April 25, 2024 03:16 PM

rncbc.org

qpwgraph v0.7.1 - A Spring'24 Beta Release Hot-Fix

Hi all,

qpwgraph v0.7.1 (spring'24 hot-fix) is released!

Change-log:

  • Hot-fix: disable thumbview interactivity: prevent dragging nodes over to extremely severe off-limits by accident.

Description:

qpwgraph is a graph manager dedicated to PipeWire, using the Qt C++ framework, based and pretty much like the same of QjackCtl.

Project page:

https://gitlab.freedesktop.org/rncbc/qpwgraph

Downloads:

Git repos:

https://gitlab.freedesktop.org/rncbc/qpwgraph.git (official)
https://github.com/rncbc/qpwgraph.git
https://gitlab.com/rncbc/qpwgraph.git
https://codeberg.org/rncbc/qpwgraph.git

License:

qpwgraph is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

Cheers!

Donate to rncbc.org using PayPal Donate to rncbc.org using Liberapay

by rncbc at April 25, 2024 11:00 AM

April 24, 2024

blog4

Pictures from Elektronengehirn concert in Aarhus 2/2

Impressions from last Saturday’s (20.April 2024) concert by Elektronengehirn in Aarhus. Here you can see Malte Steiner's new visuals software in action on three independent screens. Pictures by Per Hoier and Rene Holm.





by herrsteiner (noreply@blogger.com) at April 24, 2024 04:08 PM

April 23, 2024

blog4

Pictures from Elektronengehirn concert in Aarhus 1/2

Impressions from last Saturday’s (20.April 2024) concert by Elektronengehirn in Aarhus. Pictures by Morten Slet.









by herrsteiner (noreply@blogger.com) at April 23, 2024 10:30 AM

April 22, 2024

rncbc.org

qpwgraph v0.7.0 - A Spring'24 Beta Release

Hi all,

qpwgraph v0.7.0 (spring'24) is out!

Change-log:

  • Whether to show the System-tray informational and/or active Patchbay warning messages, respectively on Close and/or Quit, is now optional (cf. Help > Enable System Tray Message and/or Help > Enable Patchbay Message, resp.)
  • Introducing the View/Thumbview option as a whole graph thumbnail overview helper.

Description:

qpwgraph is a graph manager dedicated to PipeWire, using the Qt C++ framework, based and pretty much like the same of QjackCtl.

Project page:

https://gitlab.freedesktop.org/rncbc/qpwgraph

Downloads:

Git repos:

https://gitlab.freedesktop.org/rncbc/qpwgraph.git (official)
https://github.com/rncbc/qpwgraph.git
https://gitlab.com/rncbc/qpwgraph.git
https://codeberg.org/rncbc/qpwgraph.git

License:

qpwgraph is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

Cheers!

Donate to rncbc.org using PayPal Donate to rncbc.org using Liberapay

by rncbc at April 22, 2024 05:00 PM

April 21, 2024

Linux Archives - CDM Create Digital Music

VCV Rack 2.5: powerful stackable inputs, cable color customization

VCV Rack, the free and open-source virtual module platform, gets a tidy refresh with input cable stackings and cable color customization. That input stacking opens up more than you might think, too.

The post VCV Rack 2.5: powerful stackable inputs, cable color customization appeared first on CDM Create Digital Music.

by Peter Kirn at April 21, 2024 10:21 PM

April 20, 2024

Development update - what's going on with Ardour

Hey, Paul here. I’ve become a little concerned that the public impression of Ardour recently has been dominated by cases of entirely valid bug reports that go unnoticed and unresolved. Someone who is not quite connected to our development process might understandably get the sense that we’ve stopped working on the software.

This is absolutely not the case. Instead, what has been going on is that for the last several months, both myself and @x42 have been involved in work that has no immediate payoff for Ardour but we believe has long term significance. This has been going on in several development “branches”, and below I’ll go over these branches and what we’re up to:

  1. “Pianorule” : this branch contains a massive refactoring and rearrangement of code so that we can implement MIDI editing anywhere we feel like it, without duplicating code. This is primarily focused on providing a MIDI editor for the cue (“clip”) page, but may later make it feasible to add a standalone “piano roll editor”. This branch is currently stuck because the changes have exposed that the (hidden) assumption that the left edge of the editor track canvas is zero on the timeline has turned into a much more pervasive part of our code than was ever intended.

  2. “cliprec” : this branch is rather young but is a test bed for ideas about how to do clip recording in Ardour. This is surprisingly hard to do correctly, mostly because of assumptions and decisions that go back to the early 2000s. We have some good ideas though, and I’m optimistic that the experiments going on will land successfully.

  3. “livetrax” : this is where @paul has been focused for much of the last month, and is a resuscitation of the ideas behind Waves Tracks Live, a commercial GPL’ed product from about 2015 that was based on Ardour. There is a vague idea that this will become an additional DAW available from both ardour.org and also from other commercial partners. The main idea for WTL is that is a “front-of-house” recording tool for live sound engineers. It has no plugin support, no MIDI support, and is massively simpler to use than Ardour. It also has a clever trick to help with so-called virtual soundchecks, where you use a recording of a previous live gig to do most of the work for a soundcheck at the current one.

  4. “mode-clamping” : this is where experiments with adding ideas orbiting the concept of “this thing has a scale” are happening. This is much more complex than most people imagine when they voice their desire to “tell Ardour what scale I’m using”. Lots and lots of music from all over the world doesn’t work with scales in a simplistic way (even a lot of western pop). Currently the most promising idea is a heirarchy of objects that can each have their own scale, starting at the session level and going all the way down to individual regions. If a scale is not assigned, an object inherits one from its parent (ultimately the session).

  5. “region-fx” : @x42 has been busy with adding per-region plugins in this branch, and it is currently being tested/evaluated by some of our early beta-testers.

On top of all this, both myself and @x42 were quite involved in the work done on Ardour to provide support for Dolby Atmos now present in Harrison Mixbus 10. Sadly because Atmos is proprietary technology, Ardour itself cannot use this work at present. Nevertheless, we designed things so that should somebody create something broadly equivalent that is GPL compatible, it would be relatively easy to make it work with Ardour.

So, that’s what’s going on in the background. All this stuff does tend to mean that most new bug reports are not being attended to, and many already-known bugs too. Obviously if we had a larger development group, we could be doing both types of things, but we don’t, and so we aren’t. I’m not offering to change what we do, but let us know what you think of this prioritization/allocation of resources.

15 posts - 12 participants

Read full topic

by Paul Davis at April 20, 2024 05:58 PM

fundamental code

The DIY Mark I CPU

Every once in a while I get the urge to reminisce about a past project. So, today let’s look back on one of my favorite projects from my undergrad computer engineering degree:

Building a Custom CPU Because Writing Software Was Easier Than Designing Hardware

One of my lab courses focused on building a collection group projects with increasing complexity for each one. Most of them ended up being games with a focus on a FPGA development board, a serial connection, and some custom software running on a desktop computer. The individual projects that have stuck around in my mind are:

  1. A GAL (Generic Array Logic) and discrete component based traffic light control system with a pedestrian button.

  2. An etch a sketch application where the FPGA acted as a hardware controller and the desktop computer translated move operations and whether the cursor was depressed into a displayed image

  3. A game of hangman where the hardware system read key events from a PS1 keyboard and then submitted full words as guesses to the computer for updating the display.

  4. A signal capture tool using an ADC/DAC set of chips with an on desktop visualizer

  5. A student selected project which for my team was a two player game of pong displayed on an analog oscilloscope.

2024 04 gal traffic light

The whole sequence of projects started out with a GAL+discrete logic based assignment. We were tasked with building up a system for a standard 4 way intersection with an set of pedestrian crossings and associated pedestrian crossing request button.

2024 04 traffic

We had lookup tables in the GAL, counters, timers, logic to decode our state into which lights were on, binary to 7 segment decoder chips, it was a lot. As you might be able to see what we might have needed the most was some more rigor in terms of our wiring job, but we managed to complete the task. The project was a combination of loosely planning things and organically patching any mistakes we had made while watching the system through a logic squid. It was remarkable how much physical devices slowed down development.

The subsequent projects took us one step back from 80s style of physically building out logic and defining it in a hardware description language, namely VHDL. This sped things up considerably, though the tooling available to students was subpar at the time, so I wanted to make another technological leap and move into software. That required us to have a CPU of some sort and the assignments were always about turning in the hardware description of a system, so it couldn’t be imported from a project like OpenCores. I knew from my tinkering in open source software that the later projects would be either take less time or be more fun with a basic CPU that could be reused from project to project, so I set off and made one. Certainly it was creating something bespoke with no online resources, but at the time resources for VHDL were *sparse*.

The classes focused around state machines, so how much harder could it be to build up a programmable state machine? A computer or in our case a very very terrible minimal computer was born. The CPU itself was copied between projects with near zero changes and just enough custom peripherals were created per assignment to get the system over the finish line.

System Overview

2024 04 DE1

The DE1 development board we worked with has a bunch of LEDs, some switches, a few momentary buttons, some RAM, and a few electrical connections to the rest of the world in the form of a serial port, a PS2 keyboard connection, and some general purpose IO pins. There are some other bells and whistles, but they aren’t particularly relevant.

The custom Mark 1 CPU was built to handle the orchestration between these peripherals and was as simple as you could reasonably get. At the time I was often tinkering around with some of the AVR processors and I enjoyed dealing with the simplicity of an 8 bit system, so I made the Mark 1 a fully 8 bit system. 8 bits of addressable memory, 8 bits of addressable program ROM, and only 4x8 bit or less registers. By the last project the instruction set had grown to 22 opcodes and it was running at a blazing fast 50MHz. It was certainly stripped down with no interrupts, no relative jumps, no pipelines, and no variable cycle instructions, but it worked well enough for the course.

Architecture

The CPU was thoroughly an 8-bit system, 8-bit addressable memory, 8-bit program ROMS, 8-bit operands, and four 8-bit or less registers.

  • the Status register (SR)

  • the general purpose register (REG)

  • the indexing register (IDX)

  • the program counter (PC)

SR stored system flags such as the is-equal flag, the is-zero flag, and other application specific flags. REG is used to for general loading from memory, arithmetic operations, comparisons, and temporary storage. IDX is used for stack management, indirect memory access, and iteration. PC is used to track the current position in the system ROM, which determines the current instruction; In other systems this is referred to as an Instruction Pointer (IP).

Memonic Arg. PC SR REG IDX ALU Bus Cycles Notes

read

Ar

.

.

W

.

i..

R

2

$REG := (Ar)

load

V

.

.

W

.

i..

.

1

$REG := V

send

Ar

.

.

R

.

i..

W

1

(Ar) := $REG

test

V

.

W

.

.

i..

.

1

\$SR ⇐ $REG==V

jsrr

.

W

.

R

.

…​

.

1

\$PC := $REG

goto

Ap

W

.

.

.

…​

.

1

\$PC := Ap

brnz

Ap

W

R

.

.

i..

.

1

$PC := Ap if $REG!=0

brzz

Ap

W

R

.

.

i..

.

1

$PC := Ap if $REG==0

breq

Ap

W

R

.

.

i..

.

1

$PC := Ap if $SR.equal is true

brc0

Ap

W

R

.

.

i..

.

1

$PC := Ap if control 0 is true

brc1

Ap

W

R

.

.

i..

.

1

$PC := Ap if control 1 is true

addd

V

.

.

RW

.

i.F

.

1

\$REG := $REG + V

subx

V

.

.

RW

.

i.F

.

1

\$REG := $REG - V

spsh

V

.

.

.

RW

ii.

W

1

($IDX++) := V push V to stack

rpsh

.

.

.

R

RW

ii.

W

1

(\$IDX++) := $REG push $REG to stack

spop

.

.

.

W

RW

id.

R

2

$RED := (--$IDX) pop value to $REG

lspt

V

.

.

.

W

i..

.

1

\$IDX := V load stack pointer

sidx

V

.

.

.

W

i..

.

1

\$IDX := V set index

iidx

.

.

.

.

RW

ii.

.

1

\$IDX := $IDX+1

lidx

.

.

.

W

R

i..

R

2

\$REG := ($IDX)

swap

.

.

.

RW

RW

i..

.

1

swap(\$REG,$IDX)

trap

.

W

W

W

W

…​

.

1

Reset system

noop

.

.

.

.

.

i..

.

1

Do nothing

R(ead), W(rite), .(nothing), V(alue), Ar(Address/RAM), Ap(Address/Program), ALU (PC-IDX-REG) i(ncrement ALU), d(ecrement ALU), F(ull ALU)

22 instructions in total for the final version of the Mark I that’s I’ve got code for considering lspt and sidx are identical. No opcode encoding work was done, that was left to the VHDL generation tools, but opcodes could easily be 8 bits to fit with the overall theme of the project

One challenge of working with this instruction set was that relative jumps are not in the instruction set which means that a list of destination addresses needed to be maintained. Most code modifications were painful if it shifted code by even one address, so the Mark I CPU even has an assembler, but I’ll get to that a bit later.

Peripherals

You might notice that the CPU only interacts with registers, the 256 bytes of memory, and a few control lines with those branch instructions. So how does it work with the rest of the IO world? Memory mapped peripherals. Similar to embedded microcontrollers if the CPU writes to a given 'magic' address it is going to be writing or reading values in a peripheral. Heck, even memory is a peripheral in our case. For most of the projects this CPU was used in we were required to use the SRAM chip on the DE1 board.

Since I’ve lost some of the code used with the Mark I based CPU projects I don’t have an exhaustive list, but I can find evidence of memory mapped peripherals for:

  • SRAM : General purpose memory

  • Debug interface : manually Stepping the CPU and visualizing the address/data lines

  • A timer : for accurately and regularly tending to tasks. This peripheral had to be polled since no interrupts exist in this CPU

  • A UART : for communicating to computers over a serial link

  • Beeper : for making sounds when a player has done an action in games

  • Vector graphics video driver with selectable VROM banks : For rendering graphics on X/Y mode oscilloscope outputs

  • PS2 keyboard driver : for typing in commands

  • A character LCD driver : for displaying what uses have typed

  • A seven segment display driver : typically for visualizing debug information

  • User input buttons : for binary user inputs or for stepping through the code at low speeds (It’s pretty hard to visualize things by eye at 50 MHz)

If I attempt to build another CPU in the future I expect a huge portion of the time will focus on the debug interface. I personally find them delightful. For a particularly good set of examples take a look at the Magic processor’s front panel or the currently available PDP-11 replica front panels by Obsolescence Guaranteed. In fact the user interface component is a delightful space to explore for complex systems whether that’s processors, synths, control systems, or some other complex system that needs to precisely communicate information to a skilled user.

Assembler & Examples

The assembler itself is pretty trivial with most of the point being tracking the addresses of assembled instructions. In fact almost all of the meaningful bits of it can be seen in these yacc/lex snippets:

asm.y The primary grammar of the assembler
program:
       program statement '\n'
       |
       ;
statement:
         express
         | label express
         | label
         | directive
         |
         ;
directive:
         EQU SYMBOL NUMBER {$2->val=$3;}
         | START {pass++;pc=0;}
         | SRC SYMBOL {if(pass>1) printf("--%s\n",$2->name);}
         ;

express:
       OPCODE          {line($1, 0x00);}
       | OPCODE SYMBOL {line($1, $2->val);}
       | OPCODE NUMBER {line($1, $2);}
       ;
label:
     SYMBOL ':'        {$1->val=pc;}
     ;
asm.lex the tokenization of the assembler
;.*         /*Ignore comments*/
[ ]+            /*Ignore whitespace*/
iidx|read|test|swap|spop yylval.string=strdup(yytext); return OPCODE;
load|send|nopp|goto|subx yylval.string=strdup(yytext); return OPCODE;
rpsh|rpop|spsh|trap          yylval.string=strdup(yytext); return OPCODE;
addd|brc[0-2]|jsrr|breq|sidx yylval.string=strdup(yytext); return OPCODE;
brnz|brzz|lidx yylval.string=strdup(yytext); return OPCODE;
#[0-9a-fA-F]+   sscanf(yytext+1,"%X",&yylval); return NUMBER;
%[0-9a-zA-Z]    yylval.number = (char) yytext[1];    return NUMBER;
[_a-zA-Z]+      yylval.sym=intern(yytext);    return SYMBOL;
^\.start        return START;
^\.equ          return EQU;
^\.src          return SRC;
:               return *yytext;
\n              return *yytext;

A program consists of a sequence of statements. Those statements are either labels for code to jump to, opcodes with optional arguments, definitions of constants, or definitions of functions which are printed as comments in the generated code. Easy enough for something as low level as an assembler, right?

So, what does a real program look like? Well, let’s look at a slightly modified assembly project. Before looking at the code this is from the project where a collection of analog values are read, then transmitted over a serial connection to be displayed on a PC.

To start off, let’s look at some constants:

Assembly section 1
;Define constants
.equ        UART_TX     #02
.equ        LEDS        #01
.equ        ADC         #06
.equ        STACKP      #21
.equ        STACK_H     #F0
.equ        BINTOASCII  #08
.equ        ASCII_H     #09
.equ        ASCII_L     #08
.equ        TMP_SEND    #A2
;brc0 is uart ready send

In this program the CPU has a few system peripherals: 1. A set of on board LEDs to display running values of our input memory mapped at 0x01 (write only) 2. The serial link to the computer (UART) memory mapped to address 0x02 (write only) 3. The analog to digital chip mapped at 0x06 (read only) 4. A binary to ascii-hex conversion ROM mapped at 0x08 (input) and 0x08..0x09 (output)

In addition the stack that is used to store data which is sent to the PC is 0x21..0xF0, which should correspond to 103 8 bit values (in hex) and a null terminator.

In addition, there is a set of comments that indicate that the UART is connected to the CPU’s control line 0 to signal when data can be sent.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        INIT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
init:
            sidx STACKP     ;config stack
            spsh #4D        ;'M'

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        MAIN_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
main:
            goto inputs
in_ret:     goto outputs
out_ret:    goto delay
del_ret:    goto main

The beginning of the program initializes the array/stack which is used to store data which will be transmitted and then it establishes the main program flow. inputs are collected, the input is output to the computer, the system waits, and then it repeats the process.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        INPUT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
inputs:
            read ADC        ;Get analog value
            nopp

            send BINTOASCII ;Convert to ascii
            send LEDS
            read ASCII_H
            nopp
            rpsh            ;Push values onto stack (char*)
            nopp
            read ASCII_L
            nopp
            rpsh

            swap
            test STACK_H    ;Check for end of loop
            swap
            breq send_data
send_ret:   goto in_ret

Ignore the no-operation instructions here, but as the comments indicate data is read from the ADC peripheral. The data is converted into two bytes of hex-ascii (e.g. 0xfa), then stored on the stack. At the end we check to see if the stack pointer is at its maximal value with the test instruction and if it is at that value we go to the next stage, otherwise we keep gathering more input.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        SEND_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
send_data:
            spsh #0A        ;Add new line
            spsh #00        ;Add null terminator
            sidx STACKP     ;Set start of char*
send_loop:
            lidx            ;Read in next value
            nopp
            brzz send_exit  ;Check for null terminator
            send TMP_SEND
wait:       brc0 do_send
            ;do something useful while waiting
            read ADC
            nopp
            send LEDS
            goto wait

do_send:    read TMP_SEND
            nopp
            send UART_TX    ;Transmit data

            iidx
            goto send_loop

send_exit:
            sidx STACKP      ;reset stack
            spsh #4D         ;'M'
            goto in_ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        OUTPUT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
outputs:    goto out_ret

Now with output we’re getting to point we have something more complex. In the first 3 instructions we establish that we have a null terminated string starting at the constant address STACKP. We now want to send this string byte by byte to the UART. This is done by the send_loop. When a character is sent we have to wait for the UART to be ready for the next byte at which point we stay in the wait loop until the control line 0 indicates we can send the next character. When we do send the data it is moved from the TMP_SEND address to the UART_TX memory mapped device and we repeat the process until the full string has been sent.

Rewritten in C this looks like:

uint_t *stack_pos;
volatile uint_t *led;
volatile uint_t *adc;
volatile uint_t *uart;

void send_data(void)
{
    uint8_t chr;
    (*stack_pos++) = '\n';
    (*stack_pos++) = '\0';
    stack_pos = STACKP;

    while(1) {
        chr = *stack_pos++;
        if(chr == 0)
            break;
        while(uart_busy())
            *led = *adc;
        *uart = chr;
    }
    stack_pos = STACKP;
    (*stack_pos++) = 'M';
}
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        DELAY_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
delay:      load #00
delay_loop: addd #FF
            nopp
            nopp
            brnz delay_loop
            goto del_ret

The delay routine is the last one it counts from 0 to 256 (more or less) and we can calculate how long this should take to execute. The processor runs at 50MHz with one instruction per cycle, one loop is 4 instructions (add+2xno-op+branch). So, 256*4+1+1 (for the initial load and final goto), so roughly 20 micro-seconds. Not much time at all.

Quirks

The processor had its fair share of quirks and general limitations. While this is by no means a comprehensive list a few that were pain points at the time:

  • It was a 50MHz, all actions on risingedge of clock, nothing on falling edge. The speed was higher than was needed and the lack of falling edge operations resulted in several quirks around reads and writes bleeding into a 2 cycle instruction

  • No secondary register, so manually allocating the single register to various tasks was

  • No function call, so returns are verbose operations where the user had to save their variables before placing a return address on the stack and then making sure the called code ends with popping a value from the stack and unconditionally jumping to the current register value

  • Read is a multi-tick operation and multi-tick instructions do not exist, so no op instructions were manually inserted

  • Occasional bugs where on some revisions jumps would occur before the program counter was incremented.

  • 256 instructions really isn’t a lot. For basic problems sure, that’s loads and when you can write arbitrary peripherals it’s workable, but I did run out of program space more than once in the development of the final project

Looking back

It’s pretty amazing looking back at the specs for the DE1 board. Those boards are still sold, but they’re a heck of a lot more powerful than they used to be. Reading the spec sheet of the individual FPGA on my board I’ve got 18,752 logic elements and the new FPGA simply specifies 77k logic elements which gives me the sense that students aren’t running into those situations where they’ve exhausted ever logic unit on one of these boards while doing classwork. The newer board doesn’t even need the effort of building a custom CPU since they’ve got a built in ARM core. Heck, the ARM core has access to a full GB of RAM, which is remarkable compared to the 8MB of SDRAM on my board and the 256 bytes of address space of the Mark I CPU.

The Mark I CPU worked, it did its job and while I haven’t made a CPU from raw transistors it got me a decent part of the way there. If I do go all the way to transistors I’m guessing I’ll go down to 4 bits or have the pcb fab assemble the ocean of transistors. Overall it’s a fun space and simple instruction sets are really interesting. I don’t play around with them as much as I used to, but it is a delight to read through ISRs like the z80 or AVR. There’s a beauty to them that is lost in the pragmatic full instruction sets you see in x86/arm/etc.

So, I’ll leave this article here for now. I may well get back to it and edit it some more or extend it, but this has been sitting in my drafts folder long enough that I should put it up on my website before it collects another layer of dust.

April 20, 2024 04:00 AM

April 18, 2024

Linux Archives - CDM Create Digital Music

Ubuntu Studio in new LTS beta; still the easiest creative Linux distro

Ubuntu Studio remains the quickest one-shot way to get at Linux and free software for music, sound, video, media, and 3D. And they deserve some extra love now, especially since Apple Silicon has slightly deflated desktop Linux attention. Here's a look at the long-term support version that just hit beta, due later this month.

The post Ubuntu Studio in new LTS beta; still the easiest creative Linux distro appeared first on CDM Create Digital Music.

by Peter Kirn at April 18, 2024 06:08 PM

April 13, 2024

Ardour 8.6 released

Ardour 8.6 has been released. This is a hotfix release for 8.5, primarily to fix a drawing bug that was not noticed/fixed before 8.5 was released. It also comes with a fix for a crashing bug that can occur when JACK2 is being used.

In all other ways, 8.6 is equivalent to 8.5, but 8.5 should be considered “blacklisted” - we don’t want anyone to have to deal with the drawing issue.

Full release notes (for 8.5 and 8.6) over here as usual.

ADDENDUM: turns out we introduced a bug that ONLY affects macOS Catalina on Intel hardware. The downloads for macOS intel have been updated to include the fix for Catalina. No other changes were made.

21 posts - 10 participants

Read full topic

by Paul Davis at April 13, 2024 03:40 PM

April 12, 2024

News – Ubuntu Studio

Ubuntu Studio 24.04 LTS Beta Released

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu Studio 24.04 LTS, codenamed “Noble Numbat”.

While this beta is reasonably free of any showstopper installer bugs, you will find some bugs within. This image is, however, mostly representative of what you will find when Ubuntu Studio 24.04 is released on April 25, 2024.

Special Notes

The Ubuntu Studio 24.04 LTS disk image (ISO) exceeds 4 GB and cannot be downloaded to some file systems such as FAT32 and may not be readable when burned to a DVD. For this reason, we recommend downloading to a compatible file system. When creating a boot medium, we recommend creating a bootable USB stick with the ISO image or burning to a Dual-Layer DVD.

Images can be obtained from this link: https://cdimage.ubuntu.com/ubuntustudio/releases/24.04/beta/

Full updated information, including Upgrade Instructions, are available in the Release Notes.

Please note that upgrading before the release of 24.04.1, due August 2024, is unsupported.

New Features This Release

  • PipeWire continues to improve with every release and is so robust it can be used for professional and prosumer use. Version 1.0.4
  • Ubuntu Studio Installer‘s included Ubuntu Studio Audio Configuration utility for fine-tuning the PipeWire setup or changing the configuration altogether now includes the ability to create or remove a dummy audio device. Version 1.9

Major Package Upgrades

  • Ardour version 8.4.0
  • Qtractor version 0.9.39
  • OBS Studio version 30.0.2
  • Audacity version 3.4.2
  • digiKam version 8.2.0
  • Kdenlive version 23.08.5
  • Krita version 5.2.2

There are many other improvements, too numerous to list here. We encourage you to look around the freely-downloadable ISO image.

Known Issues

  • Ubuntu Studio’s classic PulseAudio-JACK configuration cannot be used on Ubuntu Desktop (GNOME) due to a known issue with the ubuntu-desktop metapackage. (LP: #2033440)
  • We now discourage the use of the aforementioned classic PulseAudio-JACK configuration as PulseAudio is becoming deprecated with time in favor of PipeWire. PipeWire’s JACK configuration can be disabled to use JACK2 via QJackCTL for advanced users.
  • Due to the Ubuntu repositories being in-flux following the time_t transition and xz-utils security issue resolution, some items in the repository are uninstallable or causing other packaging conflicts. The Ubuntu Release Team is working around the clock to help resolve these issues, so patience is required.

Official Ubuntu Studio release notes can be found at https://ubuntustudio.org/ubuntu-studio-24-04-LTS-release-notes/

Further known issues, mostly pertaining to the desktop environment, can be found at https://wiki.ubuntu.com/NobleNumbat/ReleaseNotes/Kubuntu

Additionally, the main Ubuntu release notes contain more generic issues: https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890

How You Can Help

Please test using the test cases on https://iso.qa.ubuntu.com. All you need is a Launchpad account to get started.

Additionally, we need financial contributions. Our project lead, Erich Eickmeyer, is working long hours on this project and trying to generate a part-time income. See this post as to the reasons why and go here to see how you can contribute financially (options are also in the sidebar).

Frequently Asked Questions

Q: Does Ubuntu Studio contain snaps?
A: Yes. Mozilla’s distribution agreement with Canonical changed, and Ubuntu was forced to no longer distribute Firefox in a native .deb package. We have found that, after numerous improvements, Firefox now performs just as well as the native .deb package did.

Thunderbird has become a snap this cycle in order for the maintainers to get security patches delivered faster.

Additionally, Freeshow is an Electron-based application. Electron-based applications cannot be packaged in the Ubuntu repositories in that they cannot be packaged in a traditional Debian source package. While such apps do have a build system to create a .deb binary package, it circumvents the source package build system in Launchpad, which is required when packaging for Ubuntu. However, Electron apps also have a facility for creating snaps, which can be uploaded and included. Therefore, for Freeshow to be included in Ubuntu Studio, it had to be packaged as a snap.

Q: If I install this Beta release, will I have to reinstall when the final release comes out?
A: No. If you keep it updated, your installation will automatically become the final release. However, if Audacity returns to the Ubuntu repositories before final release, then you might end-up with a double-installation of Audacity. Removal instructions of one or the other will be made available in a future post.

Q: Will you make an ISO with {my favorite desktop environment}?
A: To do so would require creating an entirely new flavor of Ubuntu, which would require going through the Official Ubuntu Flavor application process. Since we’re completely volunteer-run, we don’t have the time or resources to do this. Instead, we recommend you download the official flavor for the desktop environment of your choice and use Ubuntu Studio Installer to get Ubuntu Studio – which does *not* convert that flavor to Ubuntu Studio but adds its benefits.

Q: What if I don’t want all these packages installed on my machine?
A: Simply use the Ubuntu Studio Installer to remove the features of Ubuntu Studio you don’t want or need!

by eeickmeyer at April 12, 2024 12:40 AM

April 11, 2024

Ardour 8.5 released

Ardour 8.5 is available now for Linux, Windows, and macOS. This is another “small” release without major new features, largely because our two lead developers continue to be busy with things linked to future releases.

However, 8.5 does see a fix for a problem in 8.4 that affected many Linux users (a crash whenever a file selection dialog was opened, triggered by the presence of certain icon files on their version of Linux).

Full release notes over here as usual.

9 posts - 5 participants

Read full topic

by Paul Davis at April 11, 2024 05:23 PM

KXStudio News

Cardinal 24.04 released

Hi everyone, a new release for Cardinal is here, 24.04 which focuses on updating the base VCV Rack 2.4 and adds quite a few new modules, bringing the module count to 1193.

Cardinal is a free and open-source virtual modular synthesizer plugin.
It is based on the popular VCV Rack but with a focus on being a fully self-contained plugin version.

cardinal

Changelog

  • HostMIDI: Add option to force gaps between MIDI input notes
  • Fix build with latest liblo
  • Fix Linux VST2 exported symbols
  • Fix MindMeldModular in wasm/web builds
  • Force-redraw of all child widgets on dark mode change
  • Improve Ildaeil/Carla VST3 plugin handling
  • Improve Ildaeil plugin bridge handling for macOS
  • Improve Ildaeil plugin scanning
  • Several fixes for UI size with high-dpi screens
  • Stop using cardinal-specific settings::darkMode
  • Tweak default build flags to better match VCV Rack
  • Update base VCV Rack to v2.4
  • Use DPF for AU support instead of JUCE
  • Use GLES2 render target for linux ARM release builds

Module updates

  • Add Computerscare
  • Add CVfunk
  • Add DHE modules
  • Add Starling Via
  • Update Befaco
  • Update GrandeModular
  • Update HetrickCV
  • Update Sapphire
  • Update Surge XT
  • Update unless_modules
  • Update ValleyAudio

Downloads

The source code plus Linux, macOS and Windows binaries can be downloaded at https://github.com/DISTRHO/Cardinal/releases/tag/24.04.
Cardinal is released as CLAP, LV2, VST2 and VST3 plugin, plus AudioUnit and JACK/Standalone for certain systems.

by falkTX at April 11, 2024 01:14 PM

Internet Archive - Collection: osmpodcast

An error occurred

The RSS feed is currently experiencing technical difficulties. The error is: invalid or no response from Elasticsearch

April 11, 2024 05:52 AM

April 09, 2024

GStreamer News

GStreamer 1.24.2 stable bug fix release

The GStreamer team is pleased to announce another bug fix release in the new stable 1.24 release series of your favourite cross-platform multimedia framework!

This release only contains bugfixes and security fixes and it should be safe to update from 1.24.x.

Highlighted bugfixes:

  • H.264 parsing regression fixes
  • WavPack typefinding improvements
  • Video4linux fixes and improvements
  • Android build and runtime fixes
  • macOS OpenGL memory leak and robustness fixes
  • Qt/QML video sink fixes
  • Windows MSVC binary packages: fix libvpx avx/avx2/avx512 instruction set detection
  • Package new analytics and mse libraries in binary packages
  • various bug fixes, build fixes, memory leak fixes, and other stability and reliability improvements

See the GStreamer 1.24.2 release notes for more details.

Binaries for Android, iOS, Mac OS X and Windows will be available shortly.

Release tarballs can be downloaded directly here:

April 09, 2024 08:00 PM

March 21, 2024

GStreamer News

GStreamer 1.24.1 stable bug fix release

The GStreamer team is pleased to announce another bug fix release in the new stable 1.24 release series of your favourite cross-platform multimedia framework!

This release only contains bugfixes and security fixes and it should be safe to update from 1.24.0.

Highlighted bugfixes:

  • Fix instant-EOS regression in audio sinks in some cases when volume is 0
  • rtspsrc: server compatibility improvements and ONVIF trick mode fixes
  • rtsp-server: fix issues if RTSP media was set to be both shared and reusable
  • (uri)decodebin3 and playbin3 fixes
  • adaptivdemux2/hlsdemux2: Fix issues with failure updating playlists
  • mpeg123 audio decoder fixes
  • v4l2codecs: DMA_DRM caps support for decoders
  • va: various AV1 / H.264 / H.265 video encoder fixes
  • vtdec: fix potential deadlock regression with ProRes playback
  • gst-libav: fixes for video decoder frame handling, interlaced mode detection
  • avenc_aac: support for 7.1 and 16 channel modes
  • glimagesink: Fix the sink not always respecting preferred size on macOS
  • gtk4paintablesink: Fix scaling of texture position
  • webrtc: Allow resolution and framerate changes, and many other improvements
  • webrtc: Add new LiveKit source element
  • Fix usability of binary packages on arm64 iOS
  • various bug fixes, build fixes, memory leak fixes, and other stability and reliability improvements

See the GStreamer 1.24.1 release notes for more details.

Binaries for Android, iOS, Mac OS X and Windows will be available shortly.

Release tarballs can be downloaded directly here:

March 21, 2024 10:00 PM

March 05, 2024

digital audio hacks – Hackaday

Reverse Engineering the Behringer Ultranet Protocol

Ultranet is a protocol created by audio manufacturer Behringer to transmit up to 16 channels of 24-bit sound over a Cat-5 cable. It’s not an open standard, though: Behringer doesn’t offer an API or protocol description to build your own Ultranet devices. But that didn’t stop [Christian Nödig], thanks to a defective mixer, he poked into the signals and built his own Ultranet receiver.

Ultranet runs over Cat-5 ethernet cables but isn’t an ethernet-based protocol. The electrical protocols of Ultranet are identical to Ethernet, but the signaling is different, making it a Level 1 protocol. So, you can use any Cat-5 cable for Ultranet, but you can’t just plug an Ultranet device into an Ethernet one. Or rather, you can (and neither device should explode), but you won’t get anything out of it.

Instead, [Christian]’s exploration revealed that Ultranet is based on another standard: AES/EBU, the bigger professional brother of the SPD/IF socket on HiFi systems. This was designed to carry digital audio over an XLR cable, and Behringer has taken AES/EBU and tweaked it to run over a single twisted pair. With two twisted pairs in the cable carrying a 192 kbps signal, you get sixteen channels of 24-bit audio in total over two twisted pairs inside the Cat-5 cable.

That’s a bit fast for a microcontroller to decode reliably, so [Christian] uses the FPGA in an Arduino Vidor 4000 MKR in his receiver with an open-source AES decoder core to receive and decode the Ultranet signal into individual channels, which are passed to an ADC and analog output.

In effect, [Christian] has built a 16-channel mixer, although the mixing aspect is too primitive for actual use. It would be great for monitoring, though, and it’s a beautiful description of how to dig into protocols like Ultranet that look locked up but are based on other, more open standards.

by Richard Baguley at March 05, 2024 09:00 AM

March 03, 2024

linux_audio – autostatic.com

rtcqs v0.6.1 released

A new version of rtcqs, a Linux audio performance analyzer, is now available. Most notable changes include:

  • Fixed inconsistent use of single and double quotes
  • Replaced audio group check with a group agnostic check (fixes #4)
  • Governor check can now deal with systems that have SMT disabled
  • Tickless check now deals with all CONFIG_NO_HZ* variants and with nohz being set on the kernel command line (fixes #8)
  • File systems check has been expanded
  • IRQ check now loops through /sys/kernel/irq instead of parsing /proc/interrupts
  • rtprio check now checks if a SCHED_FIFO priority can be set instead of a SCHED_RR priority
  • Improved preempt RT check, check if “preempt=full” is part of the kernel command line (fixes #7)
  • Refactoring, created separate classes for main app, resources and GUI
  • Moved all packaging directives into pyprojects.toml

While working on this release I found out PySimpleGUI is not open source anymore so rtcqs’ GUI has become a bit of a moving target. I’m looking at alternatives like pygubu or even popsicle but that will be something for in the long run. In the short run there are more improvements in the pipeline. The swappiness check needs some attention and same goes for the IRQ check. I’ve been working on a different project to automate prioritizing IRQs and I’m planning to to reuse some parts of that project for the IRQ check in rtcqs. The idea is to have rtcqs not only list the status of all audio related IRQs but also any audio devices attached to those IRQs.

rtcqs is available on Codeberg, PyPI and is also included in the AUR.

by jeremy at March 03, 2024 10:34 AM

February 21, 2024

Ardour 8.4 released

Ardour 8.4 is available now for Linux, Windows, and macOS. Nothing particularly significant in this release, because our two lead developers have been busy with things linked to future releases. (note: there was no 8.3 release due to a critical bug discovered after tagging 8.3).

From a project-level perspective, perhaps the most important change is that we have moved the source code of our GUI toolkit (GTK v2) into the Ardour source tree. This has no impact whatsoever on people using the builds provided at ardour.org.

However, this version of GTK is about to be deprecated by a number of Linux distributions, and without this change it will become more difficult for both individual users and Linux package maintainers to continue building Ardour. This also leaves us free to (slowly) strip down aspects of the toolkit that we do not use, and potentially modify it as needed in the future. It also means that even the distribution builds of Ardour for Linux will contain our patches to GTK, which has historically not been the case.

Meanwhile, we now have beta-level AAF import, some new MIDI device maps, a new color theme, a stack of UX/UI tweaks and several fixes for crashing and workflow bugs.

Full release notes over here as usual.

27 posts - 14 participants

Read full topic

by Paul Davis at February 21, 2024 04:53 PM

February 16, 2024

digital audio hacks – Hackaday

Sonolithography With The Raspberry Pi Pico

You can do some wild things with sound waves, such as annoy your neighbours or convince other road users to move out of your way. Or, if you get into sonolithography like [Oliver Child] has, you can make some wild patterns with ultrasound.

Sonolithography is a method of patterning materials on to a surface using finely-controlled sound waves. To achieve this, [Oliver] created a circular array of sixteen ultrasonic transducers controlled via shift registers and gate driver ICs, under the command of a Raspberry Pi Pico. He then created an app for controlling the transducer array via an attached computer with a GUI interface. It allows the phase and amplitude of each element of the array to be controlled to create different patterns.

Creating a pattern is then a simple matter of placing the array on a surface, firing it up in a given drive mode, and then atomising some kind of dye or other material to visualize the pattern of the acoustic waves.

It could be a useful tool for studying the interactions of ultrasonic waves, or it could just be a way to make neat patterns in ink and dye if that’s what you’re into. [Oliver] notes the techniques of sonolithography could also have implications in biology or fabrication in future, as well. If you found this interesting, you might like to study up on ultrasonic levitation, too!

by Lewin Day at February 16, 2024 09:00 PM