piCorePlayer 4.1 released

Yesterday pCP was stepped up to release 4.1.

It's a basic maintenance release.

I'd strongly recommend to run the update asap. 

Find more info and a little update HowTo below.

SoX on steroids - Part 3

Recently (around mid of October 2018) the Logitechmediaserver (LMS) binaries for sox and flac have been upgraded.

Nice. People are listening. (I know they are. ;) )

Remember. These binaries are basically the LMS engines when it comes to audio streaming. As soon as the audiostream leaves these programs it'll hit the network.
That's why these are all but irrelevant for a high performance system!
It is time now to see what the LMS folks have done. I mean, the situation around the old LMS binaries was absolutely unacceptable.

There has been a factor 8 between my own compiled binary and the one supplied with LMS
on my NUC platform. On the RPI 3B the exercise took that LMS sox binary almost 27 minutes! And not to forget the testfile is around 388s long! That's simply not been working. 

RPI 3B+ - On Air

With my head still buried in the recent piCorePlayer setup and related potential tuning options, another idea popped up.

It actually happened while getting annoyed about my rather short 20inch ethernet test-cable, which - while pulling at it accidentally - caused a hefty drop of my router followed by a network outage in the house. 

The actual idea was:

What if the onboard Wifi of my shiny brandnew RPi 3B+ would actually be worth to take a closer look at!?!? 

All lights off - RPI3B+

I just thought it would be nice to share how to get your flashy 3B+ to pretend being
dead - at least on the surface. 

Unfortunately even the recently released piCorePlayer 4.0 doesn't offer such a trivial and nice tweak. (It's not that I havn't been talking to the pCP folks about it. ;) )
That leaves us with one option: Manual commandline intervention! 

piCorePlayer 4.0 - released

The piCorePlayer team released version 4.0 around 1st of September. Yep. Already 6 weeks ago.
What you'll find first of all are numerous updates under the hood. 
Great to see that the pCP team still puts many hours on the project to supply a state-of-the-art RPI audio distribution to the community. Thx a lot to the entire team.

Let's have a little closer look at it (that includes a complete pCP 4.0 settings guide targeting  best-in-class performance for a PI based streaming device):

flac vs. sox - the showdown

Today I had the idea to benchmark my steroid pumped up flac and sox binaries for decoding  a flac.

Why is that?

Both apps offer the very same functionality. And are widely used for that job.

flac on steroids - Part 2

Basically as a fallout of my earlier flac benchmarking exercise I looked into the performance of the flac binary related to certain compression levels. 


If highest efficiency is the goal, for sure we need to look at that topic as well.

It's been discussed out there that the compression levels do have an impact on the performance. 

Usually you'll find the "opinions" out there "it's fast enough - forget about it" or "differences can be neglected".  Even the designers try to play it down - you'll find the link to the discussion further down!

Let's find out what we're talking about here. 

flac on steroids - Part 1

Today I'd like to share my little "flac on steriods" project. 
...obviously inspired by "sox on steriods" ;)

I was triggered by the recent benchmark announcements on Phoronix. 

The promise: flac now delivers a 5% faster encoding and decoding 
by introducing a faster CRC algorithm. 

That sounds nice! 

Let's have a closer look at it.

SoX on steroids - Part 2

As some people were asking me about sox performance on the RPI, I now did some testing.

I ran pretty much the same benchmarking tests on my PI3 as I did on the NUC.

CD - RIP

Anybody out there still ripping CDs?  Or is it just me. ;)

Recently I figured that a track was missing. No idea when and why this happened. 

OK. Quick decision taken. ReRip that CD. 
Yep - I still keep my CDs in the attic. 

Gee Wiz... ReRipping a track "quickly" turned out into a major exercise. 

That's the story about this exercise.

SoX on steroids - Part 1

The quest for better performance will never end.

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!?!?

Raspberry PI - The Audio Engine - Part 9 - USB HUB Control

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.

RaspBerry Pi - The Audio Engine - Part 8 - Network Dongle

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.

RaspBerry PI - The Audio Engine - Part 7 - Realtime Kernel

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. 

RaspBerry PI - The Audio Engine - Part 6 - DSD Native

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.  

NOTE: This guide requires piCorePlayer 3.5

RaspBerry Pi - The Audio Engine - Part 5 - customized squeezelite

This is NOT the first post of the Audio Engine  series. I'd recommend to start the journey
@ Part1 .

Most of the project is done by now. If you're still looking for more, there is more. ;)

The result of this exercise might not be that earth shattering as you'd expect it to be.

It's IMO still worth it.

Before you start this exercise, I'd recommend to get used to the performance of the pCP setup you ended up with after Part4 for a couple of days. Just let it sink in.
And then you should go ahead with this measure. 

What are we gonna do now !?!?

Let's have a look at the actual pCP audio engine - squeezelite. To be exact the squeezelite binary. (Windows folks are rather used to the term executable).

What we can do quite easily is making the squeezelite binary running a bit more efficient. 

RaspBerry Pi - The Audio Engine - Part 4 - Advanced OS Tuning

Nice to have you back @ Part 4 of the series.

By now you already should have a nicely running audio streaming system based on the Raspberry PI 3B(+), a nice little HAT DAC and piCorePlayer as audio engine.


This part of the "RPI Audio Engine series" will cover some more rather "advanced tweaks".

This article is Work-in-Progress!  Latest update: Nov-18-2018

Raspberry Pi - The Audio Engine - Part 2 - piCorePlayer settings

In "Part 2" of this series I'd like to cover the pCP settings. The setup of choice follows
my overall philosophy "less shall be more". I'm targeting a no frills, high efficiency and smooth running setup.

Just to remind you. All settings assume a RPI 3B(+) as base and also assume you're running pCP40. With slight adaptations this or that setting can also be applied to the other RPI models.

I further assume that the PI runs as headless playback engine only.
Meaning. There's a separate LMS server out there in the network and there's no screen attached.

Raspberry Pi - The Audio Engine - Part 1 - Introduction

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 the RPI architecture and hardware can NOT be considered top notch - other SBCs do (much) better at similar price levels - what makes the RPI a success story is the full package. You simply can't look at such a device only from a HW perspective. 
SW is key. HW and SW makes the package. Without quality SW HW specs mean nothing. 
The whole RPi  family comes with excellent SW support. And that SW support achieves highest quality standards. Beside that you look at long term SW support. The first generation PIs are still supported. 

And that reliability and quality factor hooks up OEMs and people. A huge community is backing and supporting the RPI family because they know efforts are not wasted.   

Many other SBC companies failed to succeed (beyond becoming a niche product), because they were not able to comply to these factors - even providing a much better HW wouldn't help. Without being able to address the key area - solid 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.

And that's the main reason why people and OEMs stick to a PI.

Once you have achieved a market position like the RPI, you'll see more and more OEMs flooding the market with all kind of gadgets for the RPI. That'll make live for the competition even harder.

For us audio folks the HW capabilities of a computer play quite a big role. And that's the weak spot of RPI - on the first glance.

However. A RPI can IMO very well serve the purpose - to act as a rather serious audio transport. 
Not as an off-the-shelve installation though, no, it requires some specific setup considerations and a bit of tweaking to get serious quality audio from that device. 

Raspberry Pi - The Audio Engine - Part 3 - squeezelite and DAC settings

In Part 3 of this series I'd like to share some lines about the parameter settings of squeezelite.

squeezelite comes with numerous options that can change it's performance
as well as its functionality.

For this exercise I'll obviously be using  piCorePlayer once more. 

The LogitechMediaServer (LMS) setup I basically covered in the LMS configuration article.

LogitechMediaServer - Settings Guide

Let's start with a bold opening statement: 

I consider the LogitechMediaServer (LMS) the best music server software out there.
I'll explain the "Why" in a minute.

The LMS is the server part - as its name suggests - of a very powerful client-server audio streaming environment. 

LMS requires a compatible streaming client, such as the widely known and spread squeezelite application (opensource GNU PL)  which runs pretty much on all platforms. 

With this article I'd like to share some hopefully useful background information and setup advise that might get you going.  

networking - RPI dongle your net

I'd like to share an - IMO - nice alternative network setup solution for the RPI3 (It'll also work on the Pi Zero).

The solution will nicely add to, or you might also call it  - enhance -, earlier described networking solution.  

networking - my audio data highway

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.

Raspberry PI - I2S-HATs @ 384k

Today I'd like to share how to introduce 352k8/384k upsampling 
by running 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 improved performance 
while running upsampled material. That's the main reason for writing all this up. 

Shoot the Trouble -- USB Audio Interfaces

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.

Hirez - Treasure Island - Part II

Today we cover HiRes (that covers DSD as well) vs. Redbook.

In the first blog about Hirez I covered the base HiRez material.

My conclusion was.:

Hirez material quite often seems to get resampled and remastered from unknown raw masters (formats).
There is usually nothing like a real "master" for sale out there.

Bake me some Pi - perhaps a Raspberry Pi !?!?

Update: 9/9/2013

I had some discussions on the RaspiFy thread at DIY-Audio questioning the quality of the RPi as a rather serious audioserver/streaming client earlier this year.
My rather negative position related to the chosen (cheap) HW platform first of all.

Obviously the RaspiFy designers were not that happy about pointing out my opinion about it.
They quickly promised to provide images for different ARM HW platforms sooner or later.

The RaspiFy folks use the term "audiophile". The term "Audiophile" has a certain meaning to me. Obviously most parties who put together some apps and a bit of system tuning use it as hook for selling/marketing purposes nowadays.

When looking at the chosen HW, it couldn't be anything more then marketing from my perspective.
At least that's how I positioned myself towards them, without ever having a RPi in my hands...  ...at that point in time.

Of course I had to face comments like "you're promoting ARM devices (Squeezebox Touch) since years and an RPi wouldn't be any different". Hmmh. Wait a minute.

These Logitech devices were build for audio purposes only. These were not built as general
purpose toys targeted for mainly educational purposes.
Not to forget. I didn't promote Logitech products as such, not intentionally at least.
I rather promoted ""modified"" Logitech products --  my "Touch Toolbox " instead.
A Squeezebox Touch IMO needed heavy HW and SW modifications to sound excellent,
respectively "Audiophile".
There are still people out there who still think (or sell) just SW tweaks  get you into "Audiophile" spheres. People tend to forget that it is always a mix of HW and SW making the solution.
And at least from experience I can tell, that the worse the HW, the more SW tweaks will have an impact and the better the HW the less impact you'll see from software optimisations.  Of course there are systems and ears that do not exeperience anything from anything. There's a reason for everything.

And that we have that disucssion at all, is mainly related to the fact that almost any DAC, at any price, out there can not cope with "a little jitter and noise" caused by the transport.  The manufacturers of audio interfaces need to be blamed to fail in getting the mess under control
after a half a decade ignoring and another half a decade of fiddling around with it. They are asking thousands of $ for audiodevices and do not even have the input section under control.


Anyhow. Back to this project.


For the time being I left "audiophile" RaspyFi alone.

Mainly because they use MPD.

I do have plenty of experience with MPD (see 2007 -- Linux Audio The Way to Go thread.)
MPD is a local headless player, or better, server first of all. It can't really be compared with a streaming network/client like squeezelite.

The remote control apps (Android/OSX) are not comparable to iPeng
or Orange Squeeze on Android.

And then I'd need to run a local webserver on the RPi to be able to fetch my cover-arts from local file folders.

The only argument PRO MPD would have been its DSD playback capability.

(I btw tested the whole thing. Just to make sure.  I tested functionality, performance and soundquality and even spent money for those rather simplistic control apps on iOS and Android.
Conclusion: At this point in time not anybody could convince me to stay with MPD)




This led me to PiCorePlayer.


I installed PiCoreplayer first. That one uses famous Squeezelite and MicroCore Linux.
I know TinyCore Linux (same family as MicroCore) from the past. It comes with a very small footprint and resides 100% in RAM (25MB). Changed data can be made persistent at shutdown.
In case you have a HW failure or unexpected Powerdown, all actual changes will be gone.

On the TinyCore OS side I found managing apps was driving me nuts. Keeping it up2date becomes a nightmare. Something like PiCorePlayer is IMO  a "take-it-as-it-is" or "leave it" choice.
Otherwise you'll burn endless hours of waiting for the designer to do some corrections, updates or hacking.

The first thing that happened with PiCorePlayer after 3 times power up/power-down was a corrupted SD-card. I don't want to blame PiCorePlayer for this mess at this point.


I googled "RPi corrupted SD cards". I found endless threads about SD-card corruption  issues. Some blamed poor PS, some blamed poor drivers or kernels, others blamed SD-card accesses or the SD-cards itself, or if nothing of that would apply people called it bad luck. Hmmh!?!?

More thorough research would have taken me a day or two. Initial research led me to kernel/driver/setup issues. I also stepped over quite some conversations that do criticize the power situation on the RPi.
There are tons of rather poor 5V power supplies sold for the RPi. It's getting worse if we talk power and USB devices. I stepped over stuff like "never pull a USB device, if the OS is up'n running, that'll knock your system down".  "Avoid buspowered devices", because of 120mA current limitation of RPi  USB and and an overall 700mA RPi current limitation. asf. asf.
People figured that simple stuff like the buffer capacitance for the USB power rails would not comply to USB 2 standards (47uf vs 120uf). The 220uf buffering of the main 3.3V supply would be much too low. Asf. Asf.

This unstable power situation can obviously cause some serious breakdowns. That this can leave a SD-card broken/corrupted is not that far fetched.


The next thing I figured, was that the RPi uses a SoC USB hub controller (LAN9512) which also provides an internal  networking controller, which is hooked up the USB bus controller.
Yep. The network controller seems to be tight to the USB bus. Hmmh.

What does that mean? It means that if you use any kind of networking (fileshare or streaming, network remote control...) somehow the Ethernet  has to share the USB bus with your USB audio interface. That's probably not the best idea for serious USB Audio applications, especially if an external audio interface is a must. And that's the case here.

For audio purposes you should leave the bus exclusively to the audio device. At least that's kind of common sense developed over the last couple of years. However. It needs to be verified.

An alternative solution might be to use HDMI as audio interface of choice. Though there are not
too many devices supporting it. Many HDMI breakoutboxes that you'll find, tend to limit your samplerates to e.g. 48khz max and might not comply to audiophile standards..



However. I do have the RPi on the table now. I'll give it a chance.


I obviously got rid of PiCorePlayer. Though you might try it. You'll have a nice sounding squeezebox client up'n running in 5 minutes.

I also skipped Rasbian. I don't like pure Debian systems. These Debians usually never run up2date SW.
However. Raspberry firmware and drivers seem to be up2date though.
If we talk kernel and audio drivers as well as filesystem drivers etc. you might end up at a dead-end pretty quickly with a Debian system.



That led me to ArchLinux -- Arm.

From RaspiFy over PiCorePlayer and Rasbian I got to Archlinux and installed Squeezlite (took me roughly 30 minutes to get it all running) and that includes a pretty up2date 3.10 kernel and a lot of RPi tweaks already included on the Arch image. Nice.

On a first glance there's not much to tune. the implemented quite some optimizations already.  A pretty good base.

ArchArm actually comes with a similar small RAM footprint as TinyCore (25MB!).
The software used though is usually lightyears ahead of the stripped down TinyCore stuff and even Debian (Rasbian) systems.

Arch got the RAM share  already configured for terminal/command line usage, which basically gives the audio daemon more air to breathe.

The RPi comes with a major disadvantage, if you run a GUI. Much more RAM and CPU power gets allocated for graphics! If RPi, then go headless.


Meanwhile I got a rather  solid headless system running. I do have the feeling that I'm on the rather safe side when it comes to software now.
Still, I have the feeling that the system runs on the edge all the time. I'm still not 100% sure if all pops and clicks are gone, especially on HiRez material.




I tested the RPi with a Teac UD-501 (async), a M2TECH Hiface 2 (async) and  an
Audio-GD DI V1 (adaptive). The SPDIF devices were feeding my HifiMeDIY Full
Digital Amp and the Teac fed my Adam A5s speakers.

I'm using btw. 5V  linear/battery  supplies for RPi and audio interfaces. There's no way to get the Hiface working via buspower. You'd need an external supply and a special USB cable with external power option.




For 7 days now with RPi+Arch my SD-card is still not corrupted. That's promising.
I got more accustomed to Arch Linux every day (been running Ubuntu for years).

Obviously I now follow strict handling rules to avoid breakdowns:

* I always properly shutdown the OS
* I do make sure that I never unplug the power cable
* and never pull or plug a USB cord if the device is UP.
* I always have a backup SD-card at hand
(* I'm in the process to build a shutdown button)
 

Now to summarize it.


 The main RPi issues:

1. shared USB hub/bus for audio and ethernet (No.1 NOGO  -- impact needs to be verified)
2. pretty poor (onboard) powersupply, rails and buffering/filtering ( as bad as 1.)
3. shielding (EMI/RFI) issues (don't put your RPi close to your router or mobile phone.)
4. requires a good external supply
5. external devices only via USB hub
6. requires latest patches to increase stability and to lower danger of SD corruption (WorkinProgress)
7. requires proper RAM share setup (only headless - no GUI - operation recommended)
8. 1+7 potentially cause instabilities and
9. chance to corrupt your SD card
10. no (save) powerup/shutdown button
11. no Toslink and
12. poor internal audio chip ( you will have to use an external audio device)


My audio system goal is to get rid of as many devices and peripherals incl. cables as possible.

That won't happen with the RPi. You'd at least need an external audio interface with external power supply. These bus powered audio interfaces won't work!! -- unless you modify the powerrails ( what I did in the meanwhile - I can run the Hiface 2 now from the RPi USB port ).Compared to the SB Touch, you'd need two devices.

Then. What's on the positive side? It's difficult.

* There's a huge community out there. That'll keep such a project going.
* There are tutorials to improve the power situation, if you're a skilled DIY person.
* There's a lot of hacking potential -- a nice playground
*  It's got some potential to make a nice little streaming client, if you get it stabilized.
*  It's a fun toy that'll allow for endless nice little projects you wouldn't have done otherwise.

For my main purpose - a no frill streaming client as replacement for a SB Touch or SB Duet -  considering the experiences I made, even 60$ (RPi, box, chip cooling, power) are too much.
Don't forget to add a good PS and an audio-interface to the bill.

I wouldn't consider this gadget a bargain at this price/performance ratio.
The stock device is IMO pretty much unusable. I wouldn't recommend it.
I'd rather say. Stay away.

So. Better watch out when reading about the next "audiophile" mini OS on RPi.


The situation might change if the RPi designers do something about the rather flawed Power Supply/Rail situation and at least add a Toslink interface.
I'm sure some minor changes would be sufficient  to get things stabilized and wouldn't even increase the production cost.

Luckily there are much higher quality products out there. ;)


########

Stay tuned.

Squeeze Me Lite

Latest update: 16-Aug-2017 

 

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.  

Serviio Setup

http://wiki.serviio.org/doku.php?id=howto:linux:install:ubuntu
http://type.appstairs.net/2012/04/installation-von-serviio/


Lookup ports:
netstat -a | grep -i "listening"

Check interfaces if no IP gets assigned
ifconfig
more /etc/network/interfaces

Multicast address
/etc/network/interfaces
up route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1

boundAddr
edit /usr/share/serviio/bin/serviio.sh

JAVA_OPTS="-Dserviio.boundAddr=xxx.xxx.xxx.xxx"   ## your server address

The silent death...

Do you know that uneasy feeling, of not being in control of something? 
Did you experience that this feeling grows on you the bigger the thing is, that gets more and more out of control!?!?  

Or... 

Do you belong to the group of people who prefer the attitude  "What I don't know, I don't care to know..." ? 


Either way. You might want to read this article. 

A music data collection can be considered quite a treasure. Protecting such a value should be of highest priority. 

To do that properly - protecting that treasure - requires that you get on top of things. 
And this requires quite some enthusiasm, knowledge and actions (work!).

Why am I bringing all this up? One day I realized I lost valuable audio files and files got corrupted. 
And I also realized that I didn't realize I've been backing up these earlier undetected issues.

It's time to get my act together.

Loundess war - finally over ???

Hi folks.

Anybody heard about EBU R128??

To be honest. I didn't until recencly.

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.

Ever heard about Full Digital Amps ??

(Sometimes they are also called PowerDACs or Direct Digital Amps or All Digital Amps btw.)


No !?!?


...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..)


Appendix 1: Market overview
Appendix 2: Patent
Appendix 3: DDX320 Modifications

Touch Toolbox 3.0

********************************************************************

Squeezebox Touch Toolbox

Discontinued!

********************************************************************

I don't support the Touch Toolbox project any longer.

Why? I don't have a working Squeezebox Touch anymore.

You'll be 100% on your own if you continue to run the/a Toolbox.
If you keep running the Toolbox, you keep running it at your own risk.
As always have a look at the Disclaimer on the right hand side of my Blog.

Just to mention it: The Toolbox can easily be removed by a hardware reset
(pushing the black button on the back of the SB Touch).

And remember: The Toolbox and EDO  shall not be installed at the same time!!


Thx to all of you, who tried and appreciated the Toolbox for quite a long period of time.

For those who liked the results achieved with the Touch and the Toolbox,

I'd recommend to have a closer look at my RaspBerry PI based projects.

There's a lot that can still be done for those enjoying to run a "squeeze" streaming environment.
With today's options at hand, new projects IMO can lead to results even better to that
what's been possible with a SB Touch.

Enjoy.

********************************************************************

Touch Toolbox 3.0 - HW and Network

This blog is Part II of the Touch Toolbox blog.


Over here  I'll touch upon HW modifications, the network and server environment from a HW perspective.

I consider all this an integral part of your streaming solution. All this will also make a difference.

1. Power supply
2. Lan optimization
3. SPDIF data link
4. Onboard modifications
5. Server considerations

You really should have a look at it.  You'll also  find some easy to implement tweaks.

Hires Audio - Treasure Island

Introduction
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Lets dig up some treasures. It's time to run another little study.

A post over at Audio Asylum was referring to quite an interesting article about "fake" HiRes-Audio. files.

Within this article it's been stated that several HiRes audio downloads are potentially fakes.

What is HiRes? What is a HiRes fake?

The problem. The term HiRes is neither being protected, nor it clearly defines what can be expected.

The only thing that's defined is "HiRes Audio = audio data with greater than 44.1kHz samplerate"

Then. Why did HD-Tracks accept to replace potential fakes???  (for those complaining!)

CD Extraction

With this article I'd like to tackle an issue, which always makes me feel odd
when thinking about it.

"CD Extraction"...

... 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.) !?!?!

Hmmh.

Resampling - If you can't avoid it...

(Last update: Mar-28-2018)

Intro 

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 

* Conclusion

* 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

soundcheck's Squeezebox Touch Toolbox 2.0

The Touch Toolbox project has been terminated. (I do not own a SB Touch anymore)

I'd recommend to have a closer look at my RaspBerry PI based projects.

soundcheck on Hifi-Music-World 2010 presenting a Touch based solution

Last weekend I had been invited to present a streaming solution based around
my fully tweaked Touch to the public on the biggest german DIY fair (Hifi-Music-World 2010) in Stuttgart.


Silvercore (a manufacturer of  real great sounding tube-amps, transformers, pre-amps and now  also a DAC  and Bastanis  , who produces my all-time f
avorite speakers, were teaming up for a gig.

Surprisingly I was invited to present my streaming solution based on a Squeezebox Touch, feeding their system.

Me on the "other" side!?!? Feeding such equipment on a show.  Brave guys!

Hmmh. I thought - why not I know what I'm doing. Lets give it a try.

(Digital) Volume Control

Introduction

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.

Computerized Audio

Introduction

The "audiophile" audio world is heading towards computerized audio.

Though there'll be high hurdles to cross to evolve into the computerized audio world for the

wider "audiophile" community. 

To accomplish and maintain an audiophile setup using a PC, a network and an audio interface must be considered a pretty complex undertaking.

You need to have a pretty good understanding of computers and networks and associated audio devices and of course the software driving all that.

You need to continuously follow up on these. The entire setup  needs to be thoroughly planed,  selected and integrated to meet the high demands of the typically very demanding audiophile person.

Transferring your music data to the PC and maintaining your database
must be considered a major challenge too.

It is getting better nowadays, with automatic grabbing boxes and professional grabbing
services. Still getting a consistent database in place means a lot of extra manual extra work.

All this, just to replace a single CD player? Does all this effort makes sense?  

Honestly, I am really not sure.