This time it's SoX - "The Swiss Army Knife for Soundprocessing" We use it on e.g. Logitechmediaserver for samplerate conversions (SRC). I use it for highest quality SRC to 352k8/384k for one of the DACs I'm running. Perhaps there's something to gain in that area!?!?
We're still on the way to collect this or that crumb that's been left on the table. This exercise is for those who followed my advise to use an external network dongle. And for those who still enjoy playing around with our little gadget. Today we're looking at how to control our USB devices. As you probably already know the RPI Ethernet port is part of the PI USB infrastructure - The PI comes with a combined Ethernet-USB chip. IMO the weakest and most annoying part of the PI!
A fellow programmer - Yutaka from Japan - has written a nice little tool to control USB-Hubs. It has been written in 2006 and - guess what - it still works.
Now I'll explain how to install an external ethernet dongle to our Audio Engine. First you should read the general article I wrote some time ago. There I'm outlining why this exercise could be of interest for you. On PI Zeros that'd be a must-do exercise anyhow.
A realtime kernel. The cream of the cake for a Linux based Audio Engine. Did you know? Even the Squeezebox Touch was running a realtime-kernel almost 10 years ago! A realtime kernel allows a much faster task switching thus much lower latency compared to normal kernels. It's usually used in time-sensitive industrial applications. From my experience this extremely low latency can make a difference for our purpose as well. Most of my mods you've seen so far follow the logic of reducing distractions to the audio stream. An rt-kernel very well adds to that logic.
Part 6 of the series is dedicated to show how DSD-native playback can be achieved on a RPI running piCorePlayer. DSD is quite a fashioned feature since a couple of years. It's a niche format though. However. There's a small community considering it a must-have-feature for audiophile audio playback systems.
This exercise will show you how to get DSD working in your LMS/squeezelite environment.
Nice to have you back @ Part 4 of the series. By now you already should have a nicely running audio system based on the Raspberry PI3, a nice little HAT DAC and piCorePlayer as audio engine.
This part of the "RPI Audio Engine series" will cover some more modifications.
As with all tuning measures the ultimate goal is to make the system more efficient and to get rid of distractions.
Everything until now, including some basic tweaks (HDMI off/WLAN off etc.), could be accomplished by using the WEB GUI. Now it's time to switch to commandline. Some might don't like it. Some might be afraid of it. You might reconsider. Keep in mind. You can't do much wrong. If so. Just restore your backed-up SD-card, if anything has gone south. I'll try to walk you through the journey. Tweak by Tweak. Still. Remember. Everything you do you do at your own risk! Just to be clear about that.
This article is still Work-in-Progress! Latest update: Jan-24-2018
In Part 2 of this series I'd like to cover general settings for piCorePlayer that I'd recommend to look at. Just to remind you. All settings assume a RPI3 as a base. The main assumption still is that the PI runs as playback engine only. Meaning. there's a seperate LMS server out there.
Since 2013 I'm using and working with the Raspberry Pi as audio streamer. I'm also contributing this or that to certain community projects. Why Raspberry PI? The Raspberry PI family is by far the most successful single-board-computer (SBC) out there. Even though its architecture and hardware can't be considered top notch (others do better at similar price levels), it can very well serve the purpose - as serious audio transport. Not as an off-the-shelve installation, no, it requires some tweaking to get serious quality audio from that device. What makes a device like the RPI a success story is its wide market presence, great and innovative SW (manufacturer+community) support and OEMs flooding the market with all kind of (quality) gadgets. Many other SBC companies failed to succeed (beyond becoming a niche product), because they were not able comply to these factors - even providing a much better HW wouldn't help. Without proper and long-term SW support these devices are pretty much worth nothing. Providing, evolving and maintaining quality SW is a continuous process over a long period in time. That's what many manufactures underestimate! And that's why they usually fail. The challenge Taking a rather mediocre device (HW) like the RPI and make it a high quality audio transport. With this series of articles I'd like to give a little guidance to get you going. I'll try to show how to get serious audio quality from that device.
Years back I mentioned that the network and associated components do have quite an impact on your audio performance. Meanwhile this became common knowledge in - let's call it - audiophile minded circles. As usual, I prefer reasonably (priced) highest performance solutions. Usually a healthy mix of DIY efforts and commercial stuff gets me there.
Today I'd like to introduce my "currently" preferred "audio" streaming network solution.
Today I'd like to share how to introduce 352k8/384k upsampling via LogitechMediaServer as server and squeezelite as a client. This post, from a hardware perspective, pretty much relates to my RPI I2S HAT DAC projects I've been running over at DIY-Audio. Some DACs (TI PCM51xx family) have shown a slightly better performance when running upsampled material. That's the main reason for writing all this up.
With all the very interesting Raspberry Pis and other ARM devices around, Linux becomes more and more interesting for many people. Great audio transports can be build at 100$.
Not to forget. Tablet and Phones are mainly Androids and that is just another Linux, using the same soundlayer (Alsa) then all other Linuxes.
Manufacturers usually still do not commit to support Linux or Android properly.
Which is insane. The vast majority of mobile device out there are Androids.
However. Many devices work or partially work under Linux, because manufacturers comply to general USB Audio Standards (UAC1/UAC2). Meanwhile even Pro Audio companies like RME offer a "Class Compliant" mode for their newest generation of USB devices. (In the RME case they do officially focus on OSX though.)
Anyhow. Even though things are getting better, there are still plenty of cases where you'll experience NO SOUND.
That doesn't necessarily mean that your device won't work under Linux.
This article outlines a little guideline for troubleshooting your USB audio interface under Linux.
It should give you certain hints what to look for.
However. Just to make it clear from the very beginning.
I won't support anybody, who got issues with his interface!!! Checkout Google or the community.
If you have comments for improving the article please let me know.
I'd like to introduce you to a my favorite audio application - a squeezebox streaming client - called squeezelite.
squeezelite is a versatile, highly efficient squeezebox emulator that runs on all PC platforms, micro computers, like a Raspberry Pi, even on routers or NAS and also on the Squeezebox Touch . Even commercial streamers make use of it.
It's opensource and it's free. And it's IMO been and still is a major enabler for streaming quality audio at home.
I accidently stepped over EBU R128 (EBU=European Broadcasting Union, R128=Recommendation 128) while looking for a better ReplayGain solution.
R128 finally defines a standard how loudness should be measured and applied in an acceptable way.
The standard was based on ITU BS.1770 ( International Telecommunications Union) released in 2006.
ITU BS.1770 has been widely applied in the broadcasting scene.
EBU R128 significantly enhanced that standard by a function called gating (You'll learn more about it later on.) The original ITU BS.1770 has been updated to ITU BS.1770-3 by now and includes the gating function as proposed by EBU R128.
Not only us - audio geeks - have a huge problem with low quality music and messup of audio
data due to "Loudness War" - NO - broadcasters face the same challenge on a daily basis. They can not sit down and change the volume on every piece they are broadcasting.
They have to normalize audio of much more media sources, such as speach, film, commercials,
podcasts, audio asf. And by doing so, they're compressing and messing with the audio data even further.
(Sometimes they are also called PowerDACs or Direct Digital Amps or All Digital Amps btw.)
...the end of seperate DAC + AMP decade might be near!!! ;)
For those of you who got tired to run after every new DAC and amp (I did), and
those who've read the 1000th review of another miracle DAC (I did), or those
of you who got more confused then enlightened with the endless number
of DACs of choice out there (I did again), or those who look for a very small,
cost efficient and still great sounding system ... (Oh -- I'm talking about myself..)
With this article I'd like to tackle an issue, which always makes me feel odd
when thinking about it.
... do I really have it 100% under control ...
... after hundreds of rips and years of active involvement in Computer based audio !?!?!
I just read two articles in the latest issue of the german audio magazine "Stereo". Stereo is one of the biggest, if not the biggest of its kind over here in Germany.
I do think they got quite a good reputation in the market.
This month (05/11) Stereo stuck their heads into Computer CD-drives and extraction software to compare the results generated by the tools and drives.
The real interesting thing about it was the result of it.
The soundquality ranking of extraction results on different drives and different software in particular - got my full attention.
As a matter of fact according to Stereo, drives make a difference and tools make a difference on soundquality too - and they are not talking about subtle differences if you look at the SQ-ranking. There are drives going as low as 88% (SonyOptiArc DRX-S 77 U) and extractions tools as low as 94% (EAC!!!!) on the SQ ranking.
Guess what. EAC - was the worst of all.
Do I have a reason to question that Stereo article, assuming somewhat professional test-cases and setups (using Accurate Rip etc.) !?!?!
I've been looking at the subject of audio data resampling now and than. Somehow you can't avoid looking into it - for several reasons. In my case some of my HW setups suggest to use resampled data to achieve a potentially better performance.
While scanning the net I stepped over a lot of very fragmented and also incomplete information. Quite some stuff out there has a marketing flavor attached to it. And obviously you'll find numerous different opinions about the best way doing things.
With this post I'm trying to cover certain aspects, such as * What is resampling or upsampling/downsampling or oversampling? * Why resampling?
* Quality factors and quality targets
* What tools and applications
* Implementation on LogitechMediaServer * Offline resampling * Sox installation/update and compilation (script)
Let's get started. Annex 1: Script to compile latest Sox for Debian/Ubuntu systems Annex 2: Sox LMS upgrade on Debian/Ubuntu systems
There are lots of discussions ongoing if one should go or not go for digital volume control.
This is the way I see it:
It'll depend how well it performs.
First of all it doesn't cost you anything, it is easy to handle, makes certain quite expensive audio HW obsolete, resolves quite some analog volume control associated problems and it can sound damn good.