HiFiBerryOS | Hacker News Reader

HiFiBerryOS

github.com

137 pointshanklazard64 comments

I don't like how it is distributed.

Background: I'm using a Beocreate 4 Channel amp since a few months, and it's great (even if a little bit expensive, but it perfectly fits my usecase). As mentioned elsewhere, I use it for phase correct cross overs via FIR (at 250 Hz, which means it requires lots of taps), and also for DRC and cabinet correction (same FIR filters). I "simply" adjusted their DSP program (using SigmaStudio) to my needs.

The OS looks nice, and it allows to relatively easy manage DSP programs/adjustments and, what's also kind of important, playback music. BUT I have one HUGE problem with it: The whole software is only really available as an OS image. That plain sucks. This seems all the rage these days, but if I would run every piece of software on an RPi of it's own, I'd end up with a small RPi cluster in a year or two, while one RPi would be enough for all of that.

I tried to build AUR packages, but this was utter frustrating to figure out which software depends on what else (the buildroot dependencies they have are good-enough, but not exact; and some software seems to be randomly split across packages) and how they're properly configured and so on. So I gave up after a few weekends and am now only running the sigmatcp server.

I think the os image distribution is a way to reduce support and improve quality. It is much easier to check that the result is working in the lab rather than test packages and setup instructions.

One thing you could eventually do if you wanted to go the low effort route but still share it on a raspberry pi would be to build the rootfs using buildroot in a tar archive and then import that as a container. I don't really know if it would work, perhaps you would need one container per service or something, but it could be an approach.

I understand the reasons why, and they're perfectly fine. But I still think it's a bad decision to rely solely on that approach, because I ultimately hate wasting hardware.

My low effort route was to run their image in a podman systemd container, but the setup magic wasn't happy with that and some services failed and I eventually gave up debugging that. Maybe I could have setup a qemu to run it in a VM, but that requires to somehow pass through i2c and spi.

Devs might consider something like FPM (https://github.com/jordansissel/fpm) to make DEB/RPM/whatever packages that are a lot easier to install and manage.

I find it interesting that the squeezeserver (or more correctly LMS) gets so little attention. It's fascinating that several projects try to build a new framework to achieve multi-room streaming capable systems, while ignoring the existing, well working open source solution and building on that (I'm aware that several of these projects do allow to install LMS, but it's often a somewhat of an afterthought and not well integrated).

If the effort for integrating the different components (MPD etc.), which still is not close to the capabilities of LMS would go instead into improving the front-ends for LMS (which do need an overhaul IMO), we would be so much further.

I'm a diehard Squeezebox/LMS user still using three Squeezebox devices on a daily basis.

With that said, the synchronized playback has never been really what I would call great. It is roughly in synch so you can go form room to room and hear the same stuff, but when you get to an area where you can hear two devices at once there is definitely a disconcerting delay on one of them. Maybe that's because I've got one hard wired and one on wifi, but I thought it was supposed to correct for these differences.

I currently have about 8 squeezeboxes around the house in three buildings (mostly wifi connected, few receivers, few radios, few touches and one boom).

Sync is one of the features which just work perfectly, beat-perfectly.

Of course when turning on one player it will pause the music for 3 to 5 seconds to catch up but then it just works.

Yes, for the original hardware, with known latency it worked wonders. But software implementations on different hardware stacks, often with i2s dacs that don’t report their latency back to the OS makes for a headache inducing sync.

> improving the front-ends for LMS

Completely agree. I'm a big fan of the material plugin [1], in particular when viewed from a tablet-sized viewport. Easy to setup for family members as no apps need to be installed.

[1] https://github.com/CDrummond/lms-material

Yes the material plugin is great! I've started using that as well, however for controlling from e.g. a raspberry pi with touch-screen it's suboptimal (the popupkeyboard does not work for me for example) and it would be nice if volumeio, hifiberry etc. would let you control LMS through their interface.

Linking directly to the repository is very confusing. I was seriously wondering what the point of this was until I saw the actual website.

"We are putting a new lease of life into vintage B&O speakers, upgrading them with wireless capabilities, utilising the latest in open source technology."

Basically they are trying to turn old dumb speakers into smart ones. It has to be opensource because a conventional IoT vendor would not only try to sell you a new speaker, you would also be tied to their online servers. The hardware they offer is expensive but it is far more likely to keep its value after 10 years.

I think they have done this as a means to get in the door and sell you a new DAC. It's not clear if they even included the drivers required for boards from other suppliers to function. Which is, of course, fine - they are a company trying to make money.

The Linux way of things: instead of changing code in upstream projects making things work out of the box, make a distribution that glues stuff together with patches, scripts, ...

To be fair there's always going to be hacks and glue to put together an opinionated project like this. But adding proper mpris support upstream rather than using their own hacky wrappers would have been useful to contribute. I'm on the bug lists of most of the upstream projects and I don't recall any contributions from these guys (yet) which is a bit sad.

Interesting. I came across some other interesting audio projects with RPi. For my daugther I set up a "Phoniebox" (RFID based audio player with buttons, https://github.com/MiczFlor/RPi-Jukebox-RFID). Then there is volumio (https://volumio.org/), which i found to be pretty slow on older RPis. And "SSRPAR" (Bluetooth-Receiver, https://github.com/BaReinhard/Super-Simple-Raspberry-Pi-Audi...) which can be used to build a pretty good car audio host, but no longer actively maintained.

Looks like a newer version of https://www.pimusicbox.com

Been a happy user of Pi MusicBox for many years. Perfect for making any amp "smart".

I'm really happy to hear anyone still gets milage out of PiMuiscbox. I don't have any usage metrics and as you can imagine I mostly hear from unhappy users, so I do appreciate seeing this. But as you might know the project has not been maintained much for a long time and it's in a poor state. This is arguably unfair on users, especially those "new" users who might struggle with things and end up walking-away from their first foray into the world of Raspberry Pi. So I am thinking of finally making its slow death official and winding the project up. When Wouter first started the project there wasn't much out there but now there are lots of similar projects, as all the recommendations here show. I think this is great.

I've not used Hifiberry OS but I read through the main parts of their code base a while back so I have some idea of it. I like how they are very clear about what software they are building upon but I'd like to see that information on their website, not just github. I also like that they've refrained from using the word "audiophile". That in itself probably saves a load of pointless support issues.

I think their upfront statement regarding support is a good idea:

> Do you need any help? Post your questions in our community area! Note that there is no individual support for HiFiBerryOS. We hope you will understand that we can’t also provide individual support for this free software. Please DO NOT send questions to our support email or our support form. Use the community area for questions.

> Why should you do this? It takes a lot of time to support HiFiBerryOS users. Using the forum ensures that we don’t have to answer the same questions again. Sometimes, also other users can share their own experiences and tips. This helps us to have more time to implement cool new features or fix bugs.

For a time I was foolishly trying to support people across Facebook, Twitter, email, Raspberry Pi forums, and our own community forum. This sucked all the time (and most of the enjoyment) from working on PiMusicbox and has contributed to its demise. I now only (sometimes) support on our community forum but most of our users are not (yet) in a position to help others so I'm not sure it's ever worked very well.

Since hifiberry are a for-profit company pushing this software with their products I hope they are supporting it themselves to some degree on their forum. Otherwise this could result in dumping unnecessary work onto the upstream developers and that wouldn't be helpful.

Edit: on a similar note, I'd also like to see them contribute upstream but it's probably not fair to single hifiberry out over that.

Just wanted to say thanks for all your work on this project. I used PiMusicBox a few years ago and found it to be a very usable. If I remember correctly, the only reason I switched to volumio was because of the snapcast plugin, but I could have easily just not understood a similar option in PiMusicBox.

> I also like that they've refrained from using the word "audiophile".

YES! That word seems to be thrown around a lot as a justification for upcharge and I'm sure you're right about the support issues.

Thank you!

> but I could have easily just not understood a similar option in PiMusicBox

No, you are right, we never had that feature. It would have been the next step if the project was healthy. Or Spotify Connect, of course (although less interesting personally as we'd have to stop using Mopidy).

I had thoughts of a reboot which was much more focused around multi-room (using snapcast or the equally impressive looking SoundSync) but I looked around at Volumio, HiFiberryOS etc and didn't think I'd be bringing anything new to the table so why fragment the space. Perhaps something built around SoundSync would be interesting as that would provide Chromecast support but I am not sure that on it's own is enough. Plus the idea of my USP being something as locked-down as Google's Chromecast is unpleasant.

Also, this might sound bad, but I would like to head away from a project that is too focused on inexperienced users. The support gets too much and you very rarely get any contributions back.

I followed the Hifiberry/Beocreate guide to install a Beocreate amplifier inside an old Beovox CX50 speaker.

https://www.hifiberry.com/beocreate/

Inside it runs HifiberryOS on a RPi 4, which I use to connect to Spotify and serve Bluetooth.

It runs pretty well, but the Spotify connection sometimes needs a kick (reboot) after a long idle period.

The main advantage of HifiberryOS for my setup is that it can control the DAC on the amp directly, including installing profiles for my specific speaker and managing the EQ.

It’s a shame the Beocreate amp is so expensive (£150), otherwise I’d set up a few more of these.

Sure Audio makes an ADAU1701 set of boards that looks similar. Parts Express seems to carry Dayton Audio branded versions.

Can't say how well they work but a stack of IF board, DSP only, and Bluetooth programmer cost me around £50. Looks like the DAC resolution is better on the Beocreate though. No idea how good the amp is either - there are plenty of bad TPA3116 boards so sidestepping that problem might be worth the premium too.

The DSP is also much better on the beoamp (adau145x, the smaller variant). I run phase correct 250Hz crossovers as FIR on it. The 1701 has way too few taps for that. And the 1701's integrated DAC is considered quite poor.

The TPA implementation is pretty good as well. No audible noise or other obvious issues.

>phase correct 250Hz crossovers as FIR

These are things that make me excited about audio. I just wonder why it’s so expensive and less mainstream. I could honestly roll my own in a matter of hours for a 10th of the price. Why don’t market forces drive the price of proper high-end audio gear down?

I'm under the impression: Because it's all in the marketing. There is no incentive to build a "proper high-end" fully active system for 500 Euro when you're outcompeted on price and marketing by a manufacturer offering a "pretty good but not quite high-end" 400 Euro system that sounds good enough for all but a few (and then you're all of a sudden competing with much more expensive systems as well).

Also, your estimate seems off to me. I don't know your personal background, but prototyping a good-sounding speaker cabinet takes time beyond a few hours. Even more if you're aiming for mass production. Add to that the DSP + n-channel Amp board, this will be expensive, even when building 10000, AND it is not trivial circuitry to design.

Also, "proper high-end" is a relative term. When researching which speakers to build and where to source chassis, I found a nearby "proper high-end" manufacturer integrating realtime measurements of cone movement into their DSP corrections...

The physical speakers are not trivial to properly design and manufacture. The DSP and amplifier is not a headscratcher for any serious EE. The DSP chips themselves are only $10.

I haven’t looked into this space in a few years and I am of the “budget hi-fi” variety. At a glance, it does look like open source choices exist [0]. My last (finished) DIY audio project was an ODAC+O2 and that has been rock solid for 5 years.

Realtime corrections sound nice at first glance, but I’d be wary of the actual effect. It’s best handled with servo in the analog driver. DSP really shines with room and loudspeaker compensation, especially to linearize phase response (at the cost of delay). Room acoustic issues led me down a rabbit hole that ended with me working on a triple BA IEM with a teensy powered FIR crossover. I gave up on soldering wires to a tiny SM connector. It’s on my revisit list. I’ve been knocking some things out this year, so maybe it’ll be up in another year or two.

If only I could just play with toys instead of working :p

0. https://ohdsp.weebly.com/dsp-adau1452.html

HiFiBerry is a great DAC for the RPi. I am at this moment listening to Oneohtrix Point Never, streaming from my iPhone to my RPi via shariport, through their DAC, into an old JVC silver face receiver to some EPIs set to 16Ω.

This is the setup they are targeting with this distro. But Raspbian does just fine for the use case. Not sure what stripping it down further accomplishes unless they’re targeting an even smaller platform.

I haven’t looked at the actual content of the repo, so this is pure speculation.

One of the possible reasons for stripping it down is for tighter control over real time performance.

To achieve smooth audio playback, you either need to ensure real time task scheduling with a tiny asynchronous buffer or not-so-real-time scheduling with a larger asynchronous buffer. Otherwise the audio will stutter.

The first approach ensures responsiveness: you click stop and it immediately stops; you press volume up and the volume immediately goes up. The second approach is “easier” but results in a bit of lag between your control input and the output.

With HiFiBerryOS, they may go with the first approach. The fewer things you have in a system, the fewer task scheduling surprises you have, and so you can make the buffer smaller and have better responsiveness.

Now, modern hardware, even something as cheap as the Rpi, has plenty enough processing power to ensure smooth playback like 99.9% of the time (I just pulled that number out of thin air), and most non-audiophile people won’t really notice any lag in the usual media players such as VLC in day-to-day listening, but some audiophiles will swear they can notice it.

I have the same kind of setup than the parent comment (rpi2 and hifiberry dac, hooked to a marantz amp that also does phono).

It runs on raspbian and is USB powered and Ethernet networked by the close Apple timecapsule NAS / wifi AP. It then provides pulseaudio remote, shairport and mpd services.

I have not witnessed stutter but with buffering comes some kind of lag indeed. I strimmed down the basic install, by removing packages, disabling services and devices, in order to reduce power consumption and have the rpi to work out of the timecapsule USB.

My main takeaways:

1. The system has been stable for years and sounds great. I use it on the weekends mostly.

2. The DAC is great, because the built in audio is really terrible.

3. Spotify over Airport quality is not on par with pulseaudio, nor with playing flac through mpd. I have not found great mobile mpd client. Convenience wins.

4. It is strangely difficult to have pulseaudio running headless.

I'm currently building a Spotify Connect box based on Raspberry Pi 0W.

Do you have any information on what you could strip down from the basic Raspbian to get the best performance / power consumption?

Here is the snippet from my notes. I am not sure it applies to the rpi0w:

Raspbian seems OK.

Regarding the post-install config, mostly about deactivating stuff to lower the power consumption:

# /boot/config.txt [all] # should disable wifi, bluetooth and hdmi at boot time, lowering power consumption dtoverlay=disable-wifi dtoverlay=disable-bt hdmi_blanking=2 #dtoverlay=vc4-fkms-v3d dtoverlay=hifiberry-dacplus

# builtin audio must be deactivated #dtparam=audio=on Also, HDMI deactivation could live in another place, so add the following to /etc/rc.local :

# Disable HDMI /usr/bin/tvservice -o Then, some packages should be installed:

sudo apt-get update sudo apt-get upgrade

sudo apt-get pulseaudio pulsemixer pamix shairport pulseaudio-module-raop pulseaudio-module-zeroconf cmus mpd mpc

Thanks for the follow up. I'll try those and see if I can get some performance improvement.

From there, I have not needed to apply more hacks on top. It works just fine.

Yeah, I had a DIY car bluetooth system set up via some simple pulseaudio configs and a read-only boot setup but the one outstanding issue it had was the lag. I wonder if I'd have more luck using this.

> you press volume up and the volume immediately goes up

Current software only supports laggy playback, but immediate volume control via hardware volume controls.

So I am not certain that the real-time scheduling is as important here.

I don't like this

> Note that there is no direct support for local music archives (e.g. MP3 files on a NAS) yet.

For me it's major flaw. If I'm going to install such software on my Raspberry I would like to connect 2.5" USB drive and finish the installation and start to use it. But because of unknown to me decisions developers took it is impossible. Secondly putting another RPI unit just to serve content is non effective and increases pollution (one needs to setup another unit, it needs to be bought and powered). Same happens with Volumnio and MoodeAudio (the latter supports USB drives but with strange behaviour mounting it as a root, it's impossible to mount it manually in fstab, which makes it hard to fill its content via smb/cifs)

HifiBerryOS is really nice. I used it for a couple of years (mainly for Spotify and Airplay) and I never had any problem with it. I need to create a PR to integrate my project Soundsync[1], it would add multi-room audio synchronization to this project. The last missing integration imo is a Chromecast receiver but this is blocked by the missing encryption keys. It would really be awesome if Google releases them.

[1] https://github.com/geekuillaume/soundsync

This must have been something different, the first HiFiBerry OS version was released this year.

They already get multi-room audio sync from snapcast.

If you want a full system (that can play music from a NAS (SMB or NFS) check out [moOde](http://moodeaudio.org/)

HiFiBerry OS runs mpd and supports adding networked sources such as a NAS.

Been using https://www.picoreplayer.org/ for a few years after my real Squeezebox hardware died. May take a look at this one for Spotify support.

What I really want is something that can do LMS/Squeezebox and be a Google cast receiver but as far as I'm aware there's no way to DIY a cast receiver as it needs a Google cert.

With HiFi it is like with Internet. Nothing beats a good, solid cable.

And 189 USD? Really? You would need two, except if you put the boxes very close together. I also doubt that the HiFi quality would be very good.

I use a very old but very good German made Tube amplifier from my grandfather together with some soviet Speakers (30kg each) that I was lucky to get. https://www.rehifi.se/arkivet/2016/radiotehnika-bs-90

> With HiFi it is like with Internet. Nothing beats a good, solid cable.

Nothing stopping you from connecting the raspberry with a cable though.

But what is the advantage then? Serious question?

If you have already have network cabling installed, you can put that cable from the network socket to your RPi or possibly to a switch that is already connected—not all the way directly to the other one, because that cabling is already there.

And, yes, if you would like to move the unit outside (e.g. during a party) then wireless is quite convenient. You can mix and match :).

Shush you will trigger the apple fans :-)

No DLNA? How is one supposed to play music from a NAS?

There is support for it according to the changelog:

https://github.com/hifiberry/hifiberry-os/blob/master/Change...

Although it does seem to be broken currently

https://github.com/hifiberry/hifiberry-os/issues/156

HiFiBerry makes some inexpensive little amps, DACs, etc that mount on top of a raspi and allow you to drive a pair of speakers (1). I have 4 or 5 of these and I’m a fan.

I’m looking at this hifiberryOS as a possible replacement for volumio with a snapcast server for whole house sync’d audio (2). Looks pretty full-featured but I haven’t tried it out yet. Maybe others know of good music software for the pi or have experience with this?

1. https://www.hifiberry.com/shop/ 2. https://volumio.org/

The general consensus seems to be the http://moodeaudio.org is quite a bit better than volumio.

This comment section was my first introduction to it ... I'm definitely going to give it a spin, thanks!

You can do it via snapcast. I have basically that setup. A Raspberry Pi that just has a snapcast client. Then there is a snapcast server with MPD, DLNA server etc, that streams via snapcast.

But given that they have other direct-playing applications it is a strange omission.

This seems to be the goal: https://www.hifiberry.com/beocreate

Which means - you're expected to plug it directly into (or build into) a speaker.

Regardless of what you plug it into, there has to be a way to play music from your home server.

DLNA is pretty much the only open standard in existence to play music stored on one device on a second device, controlled by a third device.

Mount your music using NFS from first device to second device then use third device to control second device? What am I missing here?

Note: they actually included DLNA in their build, so this is moot.

DLNA is few notches below NFS in complexity. It has autodiscovery in the local network and optimized for library organization, control and streaming.

Using NFS instead of DLNA is much like what Russians call "sunset by hand".

Autodiscovery and NFS work fine together. My Kodi box found my NFS exports. I added them. I control Kodi using my phone.

Yes that's how dlna works.

Dlna can be used in different places here. You could also drive it as a Bluetooth sink from another Dlna server. Or use it as a spotify mode. It's not obvious.

Logitech Media Server or Roon are their recommendations. I’d go with LMS and iPeng as a remote and you have Sonos-like multi room audio controllable from your phone.

"HiFiBerryOS is based on Buildroot":

https://github.com/hifiberry/hifiberry-os/blob/master/doc/bu...