Brimstone Core & Control – Beta 1A self-hosted music system for Meridian/Sooloos – and rather a lot moreDebian 13 Core • macOS • iPhone • iPad • CarPlay • Apple TV / tvOS
Project:
https://core-audio.uk[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/00-Brimstone-Core-icon.jpg)
[/center]
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/01-Brimstone-Control-icon.jpg)
[/center]
A little while ago I posted about what started as an attempt to make Meridian Control useful again on a modern Mac.
It has got slightly out of hand.
What began as a replacement control application is now a complete self-hosted music platform with its own server, native Apple clients, optical ripping, Meridian/Sooloos support, multichannel playback, portable/offline use, CarPlay and Apple TV.
This post is the proper Beta 1 overview: where it started, what the architecture has become, what it does now, how it differs from Roon, how the Apple clients fit together, and what I would particularly like technically-minded Meridian owners to break.
Where this actually startedThis project did not begin with a plan to build another music server.
It started with Meridian.
I have Meridian/Sooloos hardware that I still like, that still sounds good, and that has no obvious reason to become electronic waste simply because the software ecosystem around it has aged.
The first idea was therefore fairly modest:
make Meridian Control useful again on a modern Mac.A proper modern native controller. Browse the existing library, select a zone, play an album, change source, adjust volume, and generally make the equipment pleasant to use again.
That was supposed to be the project.
The difficulty is that once you start writing a serious controller for an existing music system, you very quickly encounter the distinction between controlling a library and understanding one.
If the application is going to show the right album, it needs to understand metadata.
If it is going to show the right artwork, artwork needs a persistent identity.
If two copies of an album exist, it needs to know whether they are duplicates, two storage copies of the same release, or genuinely different masterings.
If the same title exists as CD, 24/96 stereo and a 5.1 Blu-ray Audio release, “same artist + same album title” plainly is not a sufficient model.
If a track is being played through Sooloos, the software should understand that route rather than pretending the Mac is somehow producing the audio.
And if I have to build all of that logic anyway, the obvious question becomes:
why should the Meridian library be the only library the controller understands?The point where Control became CoreThat is where the project changed.
Control stopped being merely a replacement Meridian remote and Core appeared behind it.
Brimstone Core is now the persistent server-side part of the system.
It owns:
- library identity
- album / artist / edition / copy relationships
- metadata
- artwork
- storage
- playback sessions
- queues
- endpoints
- signal information
- radio
- podcasts
- audiobooks
- optical ingest
- provider integrations
- portable derivatives and cache state
Brimstone Control became what its name suggests: a view onto that Core.
The Mac, iPad, iPhone, CarPlay and Apple TV are therefore not independent music applications maintaining slightly different databases.
They are different Control surfaces for the same library and the same playback/session model.
That distinction matters.
Correct the metadata once and every Control sees the correction.
Choose different artwork once and that artwork belongs to the album rather than to whichever client happened to download it.
Start an audiobook in one place and its position belongs to the book/user state, not to a particular screen.
Build a queue on the iPad and another Control can see and manipulate that same session.
The architecture that started as:
Mac Control -> Meridian/Sooloos
has effectively become:
+-> Meridian / Sooloos
+-> local DAC / audio device
+-> network endpoint
+-> portable playback
|
Mac Control -----+ |
iPad Control ----+----> Brimstone Core ----> library / sessions / storage
iPhone Control --+ |
CarPlay ---------+ |
Apple TV --------+ |
+-> radio / podcasts / audiobooks
+-> optical ingest
+-> provider integrations
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/02-Core-Web-Your-Music.png)
[/center]
[center]
The same Core library viewed through the web/admin surface.[/center]
Why build this when Roon already exists?The obvious comparison is Roon, and avoiding it would be silly.
Roon is mature, technically sophisticated and very good at what it does.
Its architecture is also sensible: a central Roon Server owns the library, playback state and queues; Control applications talk to that Server; Outputs are the devices that actually play the audio. Roon Ready devices use RAAT, and Roon also supports USB/local outputs, AirPlay, Chromecast, Sonos, Squeezebox, Meridian and other routes.
At a very high level that sounds similar to Core / Control / endpoint.
The important difference is how the two systems arrived there and what each one optimises for.
Roon began as a commercial music-management, metadata, discovery and playback platform and has grown an enormous supported hardware ecosystem around that.
Brimstone began with:
“I own this Meridian hardware. It still works. I want it to keep working.”That difference in origin has influenced almost every design decision.
Roon's great strengths are well known:
- mature metadata and discovery
- artist biographies, credits, reviews, compositions and relationships
- a large commercial hardware/certification ecosystem
- Roon Ready / RAAT
- excellent multi-room support
- powerful DSP
- excellent signal-path reporting
- Roon ARC for remote and offline use
- years of real-world compatibility testing
Roon currently advertises bit-perfect playback up to 32-bit/768 kHz PCM, a substantial DSP engine, support across 1,000+ devices from 200+ brands, and ARC for taking the library away from home.
Beta 1 does not magically erase any of that.
If Roon already does everything you want, keep using it.
Core is a different set of priorities.
Where my priorities differI wanted Meridian and Sooloos hardware to remain useful.
I wanted my owned music collection to remain the centre of the system.
I wanted CD ripping to be built in.
I wanted DVD-Audio and Blu-ray Audio to be treated as music sources rather than awkward things that need three other programs before they can enter the library.
I wanted multichannel material to stay multichannel.
I wanted different masterings and releases represented properly instead of turning every duplicate file into another album tile.
I wanted radio, podcasts and audiobooks alongside the music library.
I wanted the server to run on an old PC I already owned.
I wanted the same library on the Mac, the sofa iPad, the iPhone, the television and the car.
And I did not want another recurring charge simply to keep using my own music.
At release the intended Brimstone price is £10, once.No Brimstone monthly subscription and no Brimstone annual subscription.
At the time of writing Roon is $14.99/month, $149.88/year, or $829.99 lifetime.
That price comparison is real, but I do not think “cheap Roon” is a useful description of Brimstone.
Roon's price pays for an established commercial platform, metadata infrastructure, support, certification, an enormous compatibility matrix and years of engineering.
Brimstone's model is different.
The server is yours.
The storage is yours.
The music is yours.
The hardware can be an old office PC.
External services such as Spotify obviously retain their own accounts and commercial terms, but Brimstone itself is intended to be a single one-off software purchase.
A very concrete example: rippingThis is a useful example because it shows the difference in assumptions.
Roon OS has a deliberately hands-off CD ripping feature.
It uses cdparanoia, rips audio CDs to FLAC and aborts the disc if extraction cannot be completed accurately.
That is a perfectly sensible approach for “put a CD in and get it into Roon”.
But Roon OS ripping is CD-only.
Its own documentation states that data CDs, DVDs and Blu-rays are not supported by the built-in ripper. Output is FLAC, and Roon OS does not directly rip to a NAS.
Brimstone starts from a broader physical-media model.
A CD is one ingest source.
A DVD-Audio or Blu-ray Audio disc may contain stereo PCM, high-resolution PCM, 5.1, 7.1 or several meaningful mixes.
Core's job is not merely to turn a disc into files.
Its job is to work out what the useful audio programmes are and preserve the distinctions that matter to the library.
That is a very different design problem.
Running Core – old hardware is fineCore's production server platform is
Debian 13 “Trixie” amd64.
That means a normal old office PC, Intel NUC, HP EliteDesk, Dell OptiPlex, Lenovo Tiny or similar machine is perfectly sensible.
An SSD for Debian/Core is recommended. Music can live on local storage, a NAS or Core-managed storage.
Ethernet is recommended for the Core machine.
There is no requirement for expensive “audiophile computer” hardware.
Installing CoreStart with a clean Debian 13 64-bit installation.
A minimal/headless Debian install is absolutely fine.
Then:
sudo apt update
sudo apt install -y git
Clone Core, including its pinned submodules:
git clone --recurse-submodules https://github.com/lurcheous73/core.git
cd core
sudo ./install.sh
During the public Beta the Git repository/release route will be linked from
https://core-audio.uk.
The installer prepares the Core services and supporting components.
Once the machine is up, another machine on the same LAN can normally reach it as:
Do not expose the Core administration UI directly to the public Internet.
Updating the BetaOne of the nice things about the Beta is that updating does not require reinstalling Debian.
From the Core checkout:
cd core
git pull --ff-only
git submodule update --init --recursive
sudo ./install.sh
That keeps Beta testing simple and makes it obvious exactly which build is installed.
The production update model is designed around versioned updates/health checking rather than expecting an ordinary customer to live in Git forever.
The Apple side – one Core, several genuinely native Control surfacesOne of the things I did not want was a single web interface stretched over every screen size.
The Apple clients share the same Core-owned library, authentication/session model and much of the Control logic, but each platform gets an interface suited to the device.
The current Apple architecture is:
Brimstone Core
|
+--------------+--------------+
| | |
macOS iPhone/iPad tvOS
| | |
full Control portable/sofa living-room
|
CarPlay
(iPhone scene)
The clients are native Apple applications rather than browser wrappers.
The shared part is the model:
- Core discovery / connection
- authentication
- library identity
- album / artist relationships
- Now Playing state
- queue state
- playback destinations
- radio / podcasts / audiobooks
- artwork and metadata
The presentation is deliberately platform-specific.
The Mac can expose administration and ingest tools that would be ridiculous on a dashboard.
The iPad can spend more screen area on artwork, queue, lyrics and signal information.
The iPhone is for fast one-handed use and portable playback.
CarPlay is a safe in-car playback surface.
Apple TV is a ten-foot, focus-driven living-room client.
That is the unifying rule:
same Core, same library, same playback state – different interface where the hardware demands it.CarPlay is native CarPlay, not a mirrored phone screenThis is worth spelling out because “has CarPlay” can mean several different things.
Brimstone's CarPlay support is part of the iPhone Control application and uses Apple's native CarPlay application/scene model.
The car is not displaying an arbitrary copy of the iPhone UI.
Apple's CarPlay framework owns the safety-critical presentation rules – touch-target sizing, layout constraints and template behaviour – while Control supplies the content and actions.
For an audio application that means using CarPlay's own list/grid/tab/Now Playing model rather than trying to draw the desktop interface in the dashboard.
In practical terms, the current Control CarPlay surface exposes the things that make sense while driving:
- music/library access
- Radio
- Podcasts
- Audiobooks
- Now Playing
- queue/navigation through playable content
What it does not expose is metadata editing, storage configuration, optical ripping or a button marked “rebuild database while doing 70 mph”.
The car is a playback surface.
tvOS is a native Control client as wellThe Apple TV application is also a real client, not simply AirPlay from another device.
It talks to the same Core, browses the same library and controls the same playback model, but the UI is built for a television and Siri Remote.
That means focus navigation, large artwork, sensible grid geometry and a ten-foot layout.
The Beta includes Your Music with Albums/Artists browsing, album detail, Now Playing, Audiobooks, Podcasts, Radio and search/settings appropriate to the television.
This matters in a Meridian/home-cinema system because Apple TV is already connected to the television/processor/HDMI chain.
Making it a proper Control surface turns that existing box into a useful part of the audio system rather than creating yet another isolated media library.
A useful comparison with Roon on Apple platformsRoon's current documentation lists Control applications on Windows, macOS, iPhone/iPad and Android.
For remote/mobile use, Roon ARC is a separate phone-focused application and ARC supports CarPlay.
Apple TV is supported in Roon as an output and can be used for display via AirPlay/web-display techniques, but Roon's current Control documentation does not describe a native tvOS Control application.
Brimstone's Apple approach is therefore slightly different:
- macOS Control is a full native client.
- iPad Control is a native sofa controller using the same Core.
- iPhone Control is the compact portable client.
- CarPlay is built into that same iPhone Control application as a native CarPlay scene.
- Apple TV is a native tvOS Control client, not merely an AirPlay target.
I am not claiming this makes Brimstone “better than Roon”.
It does mean the Apple-device architecture is intentionally broader because the Mac, sofa, phone, car and television are all devices I actually wanted to use as first-class views onto the same self-hosted library.
macOS Control – the full-fat clientThe Mac application is the fullest Control client and is where most of the heavyweight management tools currently live.
It is a native Mac application rather than a browser wrapped in a desktop window.
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/03-macOS-Control-Your-Music.png)
[/center]
[center]
macOS Control – Your Music.[/center]
The Mac is where it makes sense to expose the deeper parts of the system:
- Your Music
- artists and albums
- editions and copies
- metadata and artwork
- Now Playing
- queue management
- lyrics
- VU meters
- Internet Radio
- podcasts
- audiobooks
- Spotify integration
- Bandcamp import
- Import / Export
- optical ripping
- recording tools
- Meridian/Sooloos control
The current UI work is deliberately converging with the iPad/iPhone/tvOS hierarchy so the same mental model exists everywhere: Music, Artists, Books/Audiobooks, Podcasts, Radio and Now Playing.
The difference is that the Mac keeps the deeper administrative and ingest functions which are deliberately hidden from the smaller clients.
Connecting Control to CoreOn the same network, Control searches for Core automatically.
In the normal case you select the discovered Core and sign in.
The Apple clients share the same Core-owned connection model. The iPhone can also use the configured secure remote route when away from home.
The intention is that normal users should not have to become part-time network engineers merely to play an album.
Meridian and SooloosThis remains one of the reasons the project exists.
Core and Control can work with Meridian/Sooloos systems instead of treating them as obsolete hardware that must be replaced.
Where the selected music already exists in Sooloos and the selected destination is a Sooloos zone, Core should use the native Sooloos playback path rather than pointlessly hauling the media out and sending it straight back again.
Control can also handle the familiar transport operations – play, pause, stop, previous, next, volume, mute, source and zone functions where the device exposes them.
The rule throughout Core is that the signal path should be honest.
If something is played natively it should say so.
If something has been converted it should say so.
“Bit perfect” is not treated as a decorative marketing LED.
The library – album, edition, copy and format are not the same thingThis sounds boring until you own a large library.
A NAS copy and a local copy of the same mastering should not automatically become two completely separate albums.
A CD release, later remaster and multichannel edition, on the other hand, may genuinely be different releases worth keeping distinct.
Core therefore separates the logical album/release family from its editions, technical variants and physical/storage copies.
That makes the library considerably saner once box sets, reissues, high-resolution copies and surround editions enter the picture.
Ripping CDsAttach a suitable optical drive to the Core machine.
Insert an audio CD and Core can identify the disc, present the tracks and metadata, allow corrections, rip the tracks into the selected format/storage and register the resulting album into Your Music.
The normal workflow is track extraction and verification rather than treating every CD like a forensic disk image.
A lower-level recovery path exists for damaged or awkward discs, but that is deliberately the exception.
DVD-Audio and Blu-ray AudioCore also has an ingest model for music discs containing more than one useful audio programme.
Depending on the disc that may mean stereo PCM, high-resolution PCM, 5.1, 7.1 or multiple mixes.
The aim is to preserve meaningful audio variants rather than silently throwing away the surround release because a normal music library only understands “album = stereo”.
Where MakeMKV or another legitimate helper is required, Core can integrate with that workflow.
Obviously users remain responsible for the law that applies to copying their own media in their own jurisdiction.
High-resolution, DSD and multichannelCore does not assume every source wants to become 16/44.1 stereo.
The playback path is capability driven.
The goal is to retain native/high-resolution material where the endpoint supports it and adapt only where the selected destination actually requires it.
Multichannel is a first-class design consideration.
If I own the 5.1 or 7.1 mix, I want the system to understand that it is the 5.1 or 7.1 mix.
iPad – the sofa controllerThe iPad application is intended to be a proper dedicated music controller rather than simply an enlarged phone interface.
This is probably the client closest in spirit to the old dedicated high-end music controllers: pick it up on the sofa, see enough of the collection at once to browse properly, and have the playback context available without diving through layers of administration.
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/04-iPad-Your-Music.jpg)
[/center]
[center]
iPad Control – compact artwork-led library browsing.[/center]
Your Music is laid out as a compact artwork grid so a useful amount of the collection is visible at once.
Albums and Artists are first-class browse modes rather than Artist being hidden inside a search box.
The iPad layout is adaptive rather than fixed to one model, so the same application can make sensible use of an iPad mini, 11-inch iPad Pro or larger display without turning the smallest device into a postage stamp or the largest into empty space.
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/05-iPad-Now-Playing-Lyrics.jpg)
[/center]
[center]
Now Playing – artwork, signal information, lyrics and queue brought together on the larger display.[/center]
On the larger clients the Now Playing view is intended to bring the important information together:
- what is playing
- artwork
- track / artist / album
- source
- actual signal information
- transport
- lyrics
- queue
The iPad also has proper first-class views for Radio, Podcasts and Audiobooks:
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/06-iPad-Radio.jpg)
[/center]
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/07-iPad-Podcasts.jpg)
[/center]
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/08-iPad-Audiobooks.jpg)
[/center]
The library is persisted locally.
Opening Control should not mean downloading the whole catalogue again from scratch every time.
The persisted view can then be brought up quickly while Core supplies deltas/updated state rather than treating every launch as a completely blank client.
iPhone – the portable remote and playerThe iPhone application is deliberately more compact.
The phone is for fast one-handed use, portable listening, remote access and CarPlay – not for squeezing every Mac administration panel onto a small screen.
The current final-Beta navigation is deliberately content-first:
Music | Books | Podcasts | Radio | Playing
Connection is configuration, not a permanent top-level destination.
The library itself exposes Albums and Artists directly.
The phone can therefore behave like a normal music application while still being a Control surface for a much larger self-hosted system.
It includes:
- Your Music
- Albums / Artists
- Now Playing
- queue
- Radio
- Podcasts
- Audiobooks
- portable/offline playback
- remote Core access
The phone retains a bounded local cache so useful material can remain available when the home Core or mobile connection cannot be reached.
A cached copy remains the same logical album rather than turning into a duplicate library entry.
For very large or unsuitable source formats, Core can create an appropriate portable derivative while leaving the original untouched.
That distinction is important.
A 5.1 high-resolution master does not become “a different album” merely because the phone needs a stereo portable derivative.
Core keeps the identity and provenance while allowing the client to use a representation appropriate to the device.
Away from homeThe normal remote model is based on a private Tailscale route back to the household Core.
The idea is to avoid asking customers to expose Core services through random router port forwards.
The network route does not replace Core authentication – an authorised Control device is still an authorised Control device.
When the phone leaves home Wi-Fi it can continue through its remote route, and when that is not available it can fall back to suitable cached media.
CarPlay – native in-car ControlCarPlay is part of the iPhone Control application.
It is deliberately a driving interface, not the desktop UI shrunk into a dashboard.
The CarPlay side uses Apple's native CarPlay scene/template model.
That means Apple still controls the safety-critical presentation rules while Control supplies the Brimstone library and playback actions.
The current Beta supports music/library access, Radio, Podcasts, Audiobooks, Now Playing and queue functions within those CarPlay-safe surfaces.
[center]
![[Linked Image from core-audio.uk]](https://core-audio.uk/assets/forum-beta1/09-CarPlay-Playing-Menu.jpg)
[/center]
[center]
CarPlay main playback/library surface.[/center]
The normal Apple split-screen view still works, so music can continue alongside navigation.
[center][img]
https://core-audio.uk/assets/forum-beta1/10-CarPlay-Split-Map.jpg[/img][/center]
[center]
CarPlay split view – Brimstone playback alongside navigation.[/center]
The queue and music navigation remain deliberately simple enough for the dashboard:
[center][img]
https://core-audio.uk/assets/forum-beta1/11-CarPlay-Music-Queue.jpg[/img][/center]
Radio is a proper first-class source rather than a link back to the phone:
[center][img]
https://core-audio.uk/assets/forum-beta1/12-CarPlay-Radio.jpg[/img][/center]
Audiobooks and Podcasts are also exposed through the same in-car model:
[center][img]
https://core-audio.uk/assets/forum-beta1/13-CarPlay-Books.jpg[/img][/center]
[center][img]
https://core-audio.uk/assets/forum-beta1/15-CarPlay-Podcasts.jpg[/img][/center]
And the Now Playing surface remains deliberately simple:
[center][img]
https://core-audio.uk/assets/forum-beta1/14-CarPlay-Now-Playing.jpg[/img][/center]
[center]
CarPlay Now Playing.[/center]
What you will not find on the dashboard is metadata administration, storage configuration, ripping or system maintenance.
The car is a playback surface.
One detail I particularly wanted here was architectural consistency.
CarPlay is not maintaining another library.
It is another view onto the same Core, reached through the iPhone application's native CarPlay scene.
Apple TV / tvOS – a real living-room clientThere is now a proper Apple TV client as well.
This is a native tvOS Control application talking to Core.
It is not simply an AirPlay target and it is not the iPhone UI projected onto the television.
These are photographs of the current Beta running on the real Apple TV/television rather than simulator mock-ups.
[center][img]
https://core-audio.uk/assets/forum-beta1/17-tvOS-Your-Music.jpg[/img][/center]
[center]
tvOS Your Music – designed for the ten-foot view and Siri Remote focus navigation.[/center]
The content hierarchy follows the same system as the other Controls, but the interaction model is television-specific.
That means:
- focus-driven navigation
- large artwork
- grid geometry that makes sense from across the room
- Albums and Artists as first-class browsing
- album detail
- Now Playing
- Audiobooks
- Podcasts
- Radio
- search
It provides a large-screen living-room view of the same Core library.
[center][img]
https://core-audio.uk/assets/forum-beta1/16-tvOS-Album.jpg[/img][/center]
[center]
tvOS album detail.[/center]
[center][img]
https://core-audio.uk/assets/forum-beta1/18-tvOS-Now-Playing.jpg[/img][/center]
[center]
tvOS Now Playing.[/center]
It also exposes the other major listening areas:
[center][img]
https://core-audio.uk/assets/forum-beta1/19-tvOS-Audiobooks.jpg[/img][/center]
[center][img]
https://core-audio.uk/assets/forum-beta1/20-tvOS-Podcasts.jpg[/img][/center]
[center][img]
https://core-audio.uk/assets/forum-beta1/21-tvOS-Radio.jpg[/img][/center]
For people whose television is already connected to a Meridian/home-cinema system, this turns Apple TV into another useful Control surface rather than another separate music library.
This is one of the places where Brimstone's Apple architecture differs noticeably from Roon's current one.
Roon can use Apple TV as an output and as a display route, but its current Control platform list does not describe a native tvOS Control application.
Brimstone's Apple TV client is intended to be a full browse/control surface for the Core library.
RadioInternet Radio is integrated into the same system.
Real Internet radio is annoyingly varied – MP3, AAC, AAC+, HLS and various odd streams all exist in the wild – so the philosophy is pragmatic:
if it is a legitimate playable audio stream, make a sensible attempt to play it.PodcastsPodcasts have their own subscriptions and presentation instead of being disguised as music albums.
Progress/resume state is important: if you are 43 minutes into a two-hour programme, changing device should not mean starting again.
AudiobooksAudiobooks similarly live in their own section.
Resume position belongs to the user/book rather than whichever screen happened to be open when playback stopped.
This has been tested against a fairly ridiculous collection of spoken-word material because tiny clean demo libraries are excellent at hiding real-world bugs.
Spotify and purchased downloadsSpotify integration is designed to make provider material convenient inside Control without pretending a streamed provider track is suddenly a locally owned file.
Purchased downloadable material – for example Bandcamp purchases – can become part of the owned Core library because those are actual files belonging in the collection.
Now Playing and signal informationNow Playing is intentionally about more than a giant album cover.
Depending on the source/platform it can show artwork, title/artist/album, source, actual signal information, playback destination, lyrics, queue, time and transport controls.
On the larger clients I particularly like being able to see what is playing, the lyrics and the queue together.
VU meters – because obviouslyDo you need analogue-style VU meters to listen to an album?
No.
Was that going to stop me?
Also no.
The meters are driven from playback data where available rather than being random decorative animation, with analogue-style ballistics and clipping indication.
Hi-fi would be considerably less entertaining if everything were built solely on the basis of strict necessity.
Recording StudioCore/Control also contains an audio recording workspace.
It supports multiple channels, input selection, metering, recording, playback, opening existing material and non-destructive editing/export.
The untouched master is retained; edits are applied to the rendered/exported result rather than secretly rewriting the original.
Output devicesMeridian/Sooloos is important but Core is not intended to become another single-vendor island.
The architecture includes local audio and modular network transports, with work across Meridian/Sooloos, Sonos, UPnP/OpenHome, AirPlay/RAOP, Chromecast, Bluetooth, Snapcast, Lyrion/Squeezebox, HEOS, MusicCast, BluOS and other compatible routes.
I am deliberately not claiming every model from every manufacturer has been physically tested.
That is one of the reasons for doing a public Beta.
Where I think Core is differentFor my use case the important differences are:
- Meridian/Sooloos is part of the design, not an afterthought.
- The server can be an old Debian PC you already own.
- Physical media and ripping remain first-class features.
- DVD-Audio/Blu-ray Audio and multichannel material are part of the model.
- Copies, editions and masterings are represented separately.
- The library is self-hosted.
- Remote access does not require directly exposing Core to the Internet.
- Mac, iPad, iPhone, native CarPlay and native Apple TV are all surfaces for the same Core.
- The signal path is intended to be truthful about conversion and capabilities.
- At release the intended Brimstone price is £10 once.
Roon and Brimstone – similar topology, different emphasisA technical shorthand for the two systems looks something like this:
ROON
Roon Server
-> library / metadata / DSP / zones / queues
-> RAAT / supported output transports
-> Control apps
-> ARC for remote/mobile/offline/CarPlay
BRIMSTONE
Brimstone Core
-> library / metadata / editions / copies / ingest / sessions
-> Meridian/Sooloos native control where appropriate
-> modular local/network output routes
-> Control on macOS / iPad / iPhone
-> native CarPlay scene through iPhone Control
-> native tvOS Control
The overall server/control/endpoint pattern is not revolutionary.
The interesting bit is what happens inside the boxes.
Roon puts enormous emphasis on discovery, editorial metadata, DSP, multi-room playback and a certified playback ecosystem.Brimstone puts more emphasis on preserving owned media, Meridian/Sooloos integration, physical-media ingest, edition/copy identity, multichannel releases, self-hosting and using the Apple devices I already have as native Control surfaces.Where Roon is aheadTo keep the comparison honest, Roon has a very mature discovery/editorial metadata system, polished onboarding, powerful DSP, a huge certified hardware ecosystem and years of commercial development.
Its current public material advertises:
- 1,000+ supported devices from 200+ audio brands
- Roon Ready / RAAT
- bit-perfect playback up to 32-bit/768 kHz PCM
- advanced DSP
- mature multi-room grouping
- ARC for remote and offline listening
- CarPlay through ARC
That maturity matters.
Years of users finding strange DAC firmware, broken tags, awkward routers, odd multi-room combinations and terrible old FLAC files is a real engineering asset.
Beta 1 does not magically erase that.
Core is a different set of priorities, not an attempt to claim every other music product became rubbish overnight.
If Roon already does everything you want, keep using it.
Where Brimstone deliberately goes another wayMeridian/SooloosRoon supports Meridian endpoints.
Brimstone differs because Sooloos preservation is one of the reasons the system exists in the first place.
Where selected music already exists in Sooloos and the selected destination is a Sooloos zone, I want Core to be capable of using that native path rather than pointlessly hauling media out and sending it straight back again.
Physical mediaRoon OS CD ripping is deliberately simple and CD-only.
Brimstone's ingest model treats CD, DVD-Audio and Blu-ray Audio as possible music sources, because those are things that exist in my collection.
Library identityBrimstone deliberately distinguishes the logical album/release family from editions, masterings, technical variants and storage copies.
A NAS mirror is not automatically a new edition.
A remaster may be.
A 5.1 mix definitely may be.
MultichannelMultichannel is a first-class design consideration rather than an awkward special case at the edge of a stereo-only library model.
Self-hostingThe production Core target is ordinary Debian 13 amd64.
I want an old EliteDesk or OptiPlex to be a perfectly respectable Core.
Apple TVBrimstone has a native tvOS Control client.
Roon currently documents Apple TV as an output/display route rather than a native Roon Control platform.
Remote accessRoon ARC is a polished commercial remote solution.
Brimstone currently takes the private-network-first route: Tailscale provides the network path back home and Core authentication remains the application identity layer.
PriceRoon's current pricing is $14.99/month, $149.88/year or $829.99 lifetime.
Brimstone's intended release price is £10 once.
Again, that is not a claim that the two products contain the same amount of commercial infrastructure.
It is simply a different product model.
If you have good Meridian/Sooloos hardware, a large owned collection, optical discs, multichannel releases, an old PC you would like to reuse and an irrational desire to have all of it available on the television and in the car, then you may be exactly the sort of lunatic this project has accidentally been built for.
What is still BetaThe focus now is stability rather than adding another hundred features.
There are still edge cases around unusual metadata, multi-disc releases, unusual optical media, some network renderers, remote/mobile transitions, CarPlay edge cases and some legacy Meridian behaviour.
Please assume Beta means Beta.
What I would particularly like testedIf you have Meridian equipment, I am particularly interested in which Sooloos Core/endpoints you have, whether discovery and transport work correctly, whether artwork survives properly and whether your existing library groups sensibly.
I am also very interested in large libraries, box sets, multiple masterings, multichannel FLAC, DSD, DVD-Audio, Blu-ray Audio, unusual USB DACs, mixed Sonos/Meridian systems, NAS storage, large audiobook collections, CarPlay and Apple TV.
Basically, if your audio system makes a normal software developer look slightly nervous, I probably want you testing it.
Bug reportsPlease include the Core build, Control platform, playback endpoint, what you tried, what happened instead and whether it is repeatable.
Exact examples are enormously useful.
“Doesn't work” is considerably less useful than:
iPhone -> Core -> Sooloos Office
Album starts normally.
Next Track changes the phone UI but the Sooloos zone stays on the original track.
Repeatable every time.
Core belongs on a trusted home network.
Do not expose internal administration services through random Internet port forwards.
Remote use should go through the supported private path and Core's own authentication.
Where we are nowThe immediate job is not another explosion of features.
The current priorities are stability, UI consistency, library reliability, installation, updates, mobile reliability, CarPlay, tvOS and real-hardware testing.
I would much rather make the existing system boringly reliable than announce another seventeen protocols because their logos looked good on a webpage.
FinallyThis was originally supposed to be a small Mac application to make Meridian Control useful again.
It now has a Debian server, database, ripping engine, multichannel playback architecture, recording tools, native Mac app, iPad app, iPhone app, remote/offline playback, CarPlay and an Apple TV application.
I accept this may represent a minor failure of project scope control.
But the original objective has survived:
keep excellent audio hardware useful instead of throwing it away merely because the old software around it stopped moving forward.If you have a spare old PC, install Debian 13 and give Core a go when the public Beta link goes live.
If you have Meridian/Sooloos kit, even better.
Break it.
Find the assumptions.
Find the album it groups wrongly.
Find the disc it dislikes.
Try it on the sofa.
Try it on the television.
Try it in the car.
And tell me what happened.
https://core-audio.ukChris
Brimstone Core / Control is an independent project and is not affiliated with or endorsed by Meridian Audio, Roon Labs or Apple. Product and service names belong to their respective owners.
Google Search
|
Meridian Systems
|
Meridian Streaming
|
Restaurant
|
WiKi
|
Duncan's Meridian Info
|
Board Rules
|
Restaurant Rules
is a big lengthy but I also notice the instructions say to clone 
