Volumio2 Development Introduction

I’m kicking off this thread to update everyone on the status of Volumio2 development, and to let everyone help guide our development efforts. As mentioned before, we have a Github repo for this project, which everyone is free to explore and contribute to!

There are two halves of this project on the server side: Volumio OS and the Volumio Core. The Volumio OS is a customized Debian Jessie distribution and ecosystem of software packages which serves as the framework for the system. The Volumio Core is a serverside application (written in Javascript) which runs the music player, music library, and other functions. Michelangelo is the primary developer for the Volumio OS, among many other parts. I work on the Volumio Core side, and so I’ll start off by introducing that! :slight_smile:

The Volumio2 Core features:

  • Node.js as the serverside application framework
  • Socket.io for websocket communication
  • Express as the HTTP webserver for the Volumio WebUI
  • Angular as the WebUI framework
  • LevelDB as the persistent database system
  • Kew to run the promise-based asynchronous execution of code (click here to learn what a promise is)

Volumio Core has an MVC-like architecture which breaks the player functionality into modules. The modules are organized by function: clients, interfaces, core, controllers, services, and output. Be aware that diagram is slightly out of date!

The clients represent anything that can open a connection with the Volumio server and send commands. This is code that runs on the client machine, whether it be a PC, tablet, phone, or watch. The Volumio WebUI is one of the possible clients you can use to connect to the Volumio server. It communicates to the server using a standard websocket protocol. And since this is a standard protocol, users may code any other web interface they want, and have it drive Volumio. We also have many users who use MPD clients to drive Volumio. Volumio2 will have a dedicated MPD emulation interface which will be able to interact with your favorite MPD controller.

Which brings us to our next group of modules, the interfaces. Interfaces serve as the intermediaries between the clients and the Volumio core. They translate what are typically text commands into function calls that the core executes. These interface modules are designed to be interchangeable - they offer a set of standard methods that the core can call, and return data in a standard format. We are developing this standard as we go, but the general idea is that users can drop in their own interface modules, which will allow for more interface options than just websocket and MPD emulation. For example, one could write an interface module for hard controls (real knobs and buttons, imagine that!), for local kiosk-style control, etc.

The core modules run the logic behind the Volumio player. The state machine module contains logic for switching between player states like play, pause, and stop. The play-queue module maintains the list of tracks which are queued up to play. The play queue may contain tracks from any music service. The music library module (more about this later) maintains a database of all the tracks across all services that the user has active. and allows for browsing and searching. The device selector would allow a user to switch between different output sinks - this is yet to be coded, I’m still trying to figure out what this means! The volume module allows for hardware or software level control of the output volume. Finally, the command router module contains no logic, it merely routes function calls to the various other modules.

The music controllers are modules which can communicate with individual music services or daemons. Each music service will have its own controller module. The controller can retrieve music information from the service or daemon, and can also send commands to control playback. It is important to note here that each music daemon likely has its own built in play queue and playback status. The Volumio state machine keeps in sync with each of these separate play queues and statuses. This allows the user to interact with Volumio as if it were a single music player, and the Volumio Core controls each of the music services separately in the background. We are currently planning controllers for MPD, Spop, and possibly GMusic. We are also going to add a controller for Libgroove, a nice local audio renderer that can serve as an alternative to MPD. Libgroove uses libav for audio decoding (the same as what VLC uses). Each music controller module will be interchangeable like the user interface modules. Users can write controllers for new music services they would like to add. :sunglasses:

The music services are music player daemons or interfaces to online music sources. Some of these will come bundled as part of the Volumio OS, but users can install their own as well.

The audio output stack is comprised of system-level controllers and other handlers. Under the most basic setup, this only requires ALSA, the system-level interface to your DAC. There is also the option to add SOX into the stack, which would allow for manipulation of audio data. One of the requests we often hear is for multi-room streaming and other output device selection options. Those features would probably go in this output stack somewhere. Currently, I’m still hazy on how this might work, so anyone feel free to jump in with advice! :wink:

Thank you Ning-yu for this clear explanation !
With it, we can see how Volumio2 will be build !

Here’s some info about the Volumio 2 music library, as promised! :slight_smile:

The music library functionality for Volumio 2 is being designed as a successor to the popular music library feature in Volumio 1.5. The new music library is able to browse tracks indexed by genre, artist, and album. Now, however, there is also the option to define your own indexes, so you may sort and categorize your music by any metadata field, including composer, decade, etc. I’m also planning to add a feature to allow users to make and store playlists.

The Volumio 2 music library is also designed to deal with tracks across many different music services. A typical user will have the same track across a number of different services. These separate “versions” may have different audio formats, and some may be more high quality than others. In the Volumio 2 music library, each track entry shows all the versions available. In the WebUI, I imagine that icons will appear next to each track name to show these different versions (FLAC, Ogg, WAV, Spotify, etc). Queueing up a track will add to the playback queue the version which is highest on a user-defined priority list. For instance, if the user selects local WAV files as the highest priority, the WAV version of each track will be added the the play queue (if available). If not available, the version with next priority will be selected, and so on.

Album art has been a longstanding feature request from many in the community, and this will definitely be available in Volumio 2. Album art which is included in an audio file will be stored in Volumio’s database, so it can be shown in the WebUI. In addition, I am currently writing code to support retrieval of album art and other metadata from external sources. If album art is not available from a local file, for example, Volumio 2 will search Last.fm and other services for album images. This new module is general enough to support retrieval of other metadata as well. For instance, it will be easy to add functions to fetch and store artist biographies and related artist lists, which can then be viewed in the Volumio WebUI.

Thank you to all the developers who are involved with this project.
This sounds all very exciting and I am looking forward to test the new features.

Is there an ETA to when a first Beta will be released?

I have a question about the newly featured album art.

You mention that in Volumio 2 there will be the possibility to retrieve album art from files, but I think that a lot of people will have their album art as a separate file in the album folder. Can this also be used to fill the album art database?

Not sure exactly when, but if everything goes according to plan, we should be near complete in a few months. :wink:

Yes, I don’t see why not! To be honest, I’m writing right now a routine to pull album art from the Cover Art Archive. We can add a feature later to scan tracks and local directories for art, if it’s faster.

It’s awesome to see the efforts being made to make this software even cooler. The one thing I miss with 1.55 is a search/filter option in the library page. I can browse most music easily through the genre, artist and so, but sometimes a keyword/string is much easier. For example when you are not sure who the artist was of a certain song, or looking for different versions of it. Not sure how this feature should look exactly, but maybe others are also looking for something similar.

Fantastic project,a huge job.
In Volumio 2 will there be the possibility giving of the Rating to favorite tracks,I miss.

Yep, you’ll have that :wink:

well, all those last posts related to tagging make this whole thing sound even better again - ty all who put so much effort into making the raspi such a wonderful item.

As I have a collection of 30+k songs of which all are tagged and some rated I really would like to be able to combine these filters into a result list (and /or would be nice there too…).

As an expample let’s say I’ve got friends over and want to listen to R&B only bc it fits the occasion/people but it should be 4-5 stars rated songs only. Or you want to put up a fast playlist of your favourite chill. And so on…

In any case I’m really looking forward to the new V2 :slight_smile:

Any updates on Volumio2? Seems to be taking a very long time. :unamused:

You can still have a look here to see work in progress !! https://github.com/volumio/Volumio2

well, it’s all new from scratch, not an update!

quote from the blog, about 1 month ago:

Either way I’m now sure that it’s time to replace my raspberry.
I’m pissed with sd cards, ethernet speed, powered hubs for htpc/hifi use.

Since volumio 2 will be available for x86… x86 single board coming! raspberry delegated to dirtier electronic experiments.

x86 Braswell + arch linux + volumio 2 + kodi + acestreams + gigabit lan + sata + usb diy dac = heaven

Almost sure this doesn’t belong here but I feel I have to comment your post.

Why pissed with SD cards? I am assuming your are using your PI as DAC to play music on a stereo hifi system, why do you care about ethernet speed? 100MBit is fast to enough to stream anything in your local network, and your internet connection is probably slower than that.

Powered hubs? Why don’t you use a quality DAC that uses the I2S interface on your PI (such as Durio Sound or Durio Sound pro or if you want a little bit less use the HifiBerry). That way, you get a really good sound and still have 4 USB ports free (connect USB flash drives or even USB-HDD).

The point of the previous message was that volumio is changing and opening to x86 too officially, which should open some new scenarios on different hardware.

That post wasn’t a rant against raspberry per se. I just wanted to say why I’m thinking I should upgrade to an x86 board and why I’m finding it’s just not enough for my needs anymore.

To answer your points about the raspberry:
[spoiler]I own a few and I’ve done many funny and useful things on them.
But on this one I do much more than just playing music. I also share its drive, move frequently some gb of data around the network (from and to it), kodi and much more. Can’t tolerate it not being gigabit anymore.

I’m in a limbo situation. Not enough to justify a dedicated server for various reasons: not first home so I’m not always there and my provider upload speed is too low. If I had a better upload (to use it remotely), I’d just buy a server and just keep the raspberry as client renderer.

BTW I own a pidac+ (pcm5122 i2s) and know that you can get superb sound from a pi+i2s dac, way cheaper than some commercial dacs. I also use a 2.5 hdd powered by raspberry (no hub) containing an huge lossless collection. Have no major complaints about it.

  • you can easily max the 1.2A usb power of the raspberry with some laptop hdds and a wireless dongle, even with max_usb_current=1.
    There are some laptop hdds (not broken) that take up to 1.1A on power up (especially sata3, 7200 RPM). When you use one of those coupled with a wi-fi dongle it’s a gamble at every boot. Sometime it spins, sometime it clicks, you are pretty much on the border of current limiter. In that case you have to provide power externally to the hdd, either by hub or by another adapter by Y power cable.

  • Pissed by sd cards: because it happens frequently that two very similar models of cards of the same brands, one boots and one not. Also documented on elinux wiki. Note that some of the cards that don’t boot on the pi boot on other single boards.
    Also because I have too many around the house and because of their slowness ON THE PI, even if you spend lots for a premium sd card. Even with a super card, you’re limited by the raspberry architecture, it won’t get any faster than about 22-25 MB/s in practice. Plenty of documentation on this.

Jumping to x86 is not for everyone and it costs way more, costly also to extend compared to a raspberry. But justifiable if user needs it.
Clearly the requirements must be high: e.g. transcoding media on the fly or media server or needing x86 software.
Next skylake cpus could be very interesting.

Raspberry will be #1 choice for electronic things, like a WIP I’m doing: controlling my lawn irrigation, well pump etc (solid state relay fun) getting data from weather stations and display everything on a lcd display inside home (and web interface obviously)[/spoiler]

And what about embedded cuesheet specially for Flac files? (cuesheet and cover inside with sort possibility by tags)

Hello there

I just wanted to know if the volumio development team is actually looking for developers. I’m a web developer, i really like volumio and i wish to help, if help needed. Just PM me if interested.

just to mention this, since this is as well very possible, and in some heavy use cases, as well recommended:

you can run any rpi as well from an usb-key, once you have installed your system, dd everything ( on some different machine, mind you ) on an usb-key, and change the config.txt to boot not from /dev/mmblk0p2 to /dev/sda2 ( your names might vary there ), and resize the root partition on your usb-key ( or drive, or whatever usb you use, and voila, your sd-card is used only for a very short time for boot, everything else runs off usb ( key, disk, ssd, whatever )

Volumio2 is designed to do less harm possible on SD Cards…

System will load on RAM and write just the bare minimum, with user options…