dearworld-ronnie-studio-thuis

What digital audio format does your USB DA-converter support and use?

Have you ever wondered which digital audio format your Linux based music computer (for example one that runs Music Player Daemon in bit perfect / audiophile mode) is actually sending to your USB DA-converter when playing a high resolution digital audio file, especially when your DAC doesn’t indicate the sample rate or resolution of the incoming stream with LEDs or a display? Or maybe you are curious about the digital audio formats your USB DAC or handles natively?

This article and the accompanying script try to assist you with that daunting task.

The script –which should be executed on the Linux based audio computer– will show the available alsa interfaces for digital audio playback and the digital audio formats the USB DAC, or in the case of a sound card with non-USB digital interfaces, the digital interfaces of the sound card supports. If you have more than digital interface, the script will ask you which one you want to examine.

Instructions

NOTE: For this task you need to start a terminal screen on your desktop computer. Linux users may press and hold CTRL+ALT while typing T from within their desktop environment. Both users of Linux and Mac desktops may search for the text "Terminal" in their applications menu, while Windows users can use putty.

  1. Open a terminal screen on your desktop computer and connect through SSH to the linux based audio computer. Copy-and-paste or type the line below in the terminal screen, while replacing "${username}" with the proper one (as configured or instructed by your manufacturer) and "${networkaddress-music-computer}" with the actual IP adress (ie 192.168.1.10) or hostname (ie vortexbox) of the music computer, followed by pressing ENTER:
  2. Once your terminal is connected to that of the music computer, copy-and-paste (or type) the following lines in the terminal screen, followed by pressing ENTER:
  3. You may now run the script by copy-and-paste (or type) the following line in the terminal screen, followed by pressing ENTER:

    This will display a list of each alsa audio output interface with its details. When an interface is in use by another program, it will display its processname and pid, so may you stop or kill it.

  4. The list of interfaces may be filtered by using the limit option '-l' with an argument, either 'a' or 'analog', 'd' or 'digital' or 'u', 'usb' or 'uac' to only show interfaces fitting that limit. In addition, a custom regular expression filter may be specified as an argument for the 'c' option.

    To list only interfaces that support USB Audio Class you should execute:

  5. Next, you may use the watch command together with the value of the 'monitor file' of the interface you wish to inspect, to see how it reacts when you play different digital audio formats (replace ${monitor_file} with the one displayed):

Now try throwing audio files of different formats at your player and see what your digital interface makes of it.

Automated usage in scripts etc.

The script can be started from the commandline as explained above to give visual information, but may also be sourced. That way one may automate and store certain properties for use in other scripts or config files.

To see all properties that can be accessed this way see the scripts source or grep for the following:

The working of the script explained

To detect which digital interfaces your computer has, the script filters the output of the command 'aplay -l' to list interfaces which have one of the words "usb", "digital", "hdmi", "i2s", "spdif", "toslink" or "adat" in them. However, before it does that, it temporary disables and shuts down pulseaudio, which otherwise would block accessing the interface exclusively. It then reformats the output of the "aplay" command to show a clear listing of each alsa interface, consisting of a "hw:X,Y" hardware addresses, its human readable name, the character device it uses, the digital formats it supports natively, and –in case of a USB Audio Class device, the class (1 or 2) and its stream file.

After an interface is selected, either by the script (in case of single interface) or you (in the case of multiple interfaces), the script will play random noise to the interface, in order to force alsa to display the native digital formats the interface accepts. To keep this test silent, the sound output of the interface is redirected to /dev/null.

NOTE: for this to work one should temporary stop or pause any program using that interface, like mpd. However, the script will detect and show you which processes/programs are accessing which device while performing this test, so you may abort the script and stop the listed program, using pkill ${process_name} or kill -9 ${process_id}, before re-running the script.

The output below is that of my own system, with a sound card embedded on an Intel motherboard and two USB DACs connected:

After this, the watch command may be used with the monitor file, which resides in the pseudo file system /proc, which allows for inspecting the snd_usb_audio kernel module’s parameters and their values, see the source of /tree/sound/usb. The script does this by translating the selected interface address hw:X,Y to the associated filename /proc/asound/cardX/streamY, where X is the number of the sound card and Y that of the output interface. Because this steam file is created by the kernel module, it only exists when you have interfaces that support a USB Audio Class, see the source of sound/usb/proc.c). In such cases, the file contains the actual values of the snd_usb_audio kernel module associated with the specific interface.

The script displays the changing contents of this file with a 100ms refresh rate (0.1s) using the watch command.

The script

The script is written in bash and part of my mpd-configure project hosted at github:

Contents of the stream files for USB Audio Class 1 & 2 DAC’s

Stream file in adaptive UAC1 mode

I used to have a Pink Faun 3.24 USB DAC, fitted with a USB Audio Class (UAC) 1 transceiver chip from Tenor. With these UAC1 devices, the communication with the host computer runs in isochronous adaptive mode, meaning the data transfer type is isochronous and the audio synchronization type adaptive. See the official USB Audio Class 2 specification “A Device Class for Audio” from the USB consortium.

The contents of the stream file /proc/asound/card0/stream0 look like this when playing a 16bit/44.1kHz CD-ripped file:

When playing a 24bit/96kHz file, the output of the file changes to the following.

Note that the Altset value has changed from 1 to 2 and Momentary freq from 44100 to 96000, indicating that the second interface (Altset = 2) is activated with a 24bit format (Format = S24_3LE) and 96kHz sample rate (Momentary freq = 96000).

The story above is summed up in the following diff:

Stream file in asynchronous UAC2 mode

With UAC1 device in isochronous adaptive mode, the DAC and computer negotiate a shared sample rate, mostly using a PLL mechanism. The Momentary freq value shows the result of that negotation which should be equal to that of the file being played.

With USB Audio Class 2 in isochronous asynchronous mode, like new Pink Faun DAC2 with an Amanero(?) supports, every 125us the DAC tells the computer how many SPDIF-packets it should sent in one USB Request Block (URB).

In the output you can actually see that happening when playing high resolution files; the Momentary freq flips from 192.000Hz to something like 191.999Hz and back again.

Other differences with the UAC1 device output are:

Field UAC1 UAC2
URBs 8 64
Packet Size 582 1024
Feedback Format (non-existent) 16.16
Endpoint 3 OUT (ADAPTIVE) 5 OUT (ASYNC)
Data packet interval 1ms (1000us) 125us

The output looks like this when playing a 16bit/44.1kHz file:

It changes to the following when playing a 24bit/96kHz file:

And, finally, this is what it looks like when playing a 24bit/192kHz file:

As you can see below, this device pads each sample (with zeroes) until it fills up 32bits, regardless of the resolution of the source file. Therefore, it needs only a single AltSet and doesn’t change anything when changing from 16bit/44.1kHz to 24bit/192kHz, apart from the sampling frequency (MomentaryFreq):

Changelog

Apr 18, 2014: Major rewrite of the script:
  • moved tests/detect-alsa-output-capabilities.sh to alsa-capabilities
  • modified alsa-capabilities to make it suitable to be sourced or run by itself from the command line
  • added simple and regexp filtering to alsa-capabilities
Apr 8, 2014: Script updated:
  • added functionality to monitor non-UAC devices using its hw_params file and a few improvements in UI.
Apr 3, 2014: Small script changes and moved PCM information:
  • introduced some more bashims to make the script faster and simpler.
  • Moved the background information on the PCM format to The PCM format explained.
Apr 2, 2014: full rewrite of the script
  • to minimize user interaction and making it a bit more robust.
Mar 21, 2014: Small changes to the article:
  • Reformatted the introduction and added some technical background about the script
Mar 20, 2014: Completely rewritten the article
  • the previous version of the article assumed you already had your (default) music player set up for using a alsa hardware playback interface, which most readers are trying to figure out.
  • created a script (detect-alsa-output-capabilities.sh) to quickly list the available interfaces and supported audio formats
ella-meets-kuzma

How to turn Music Player Daemon (mpd) into an audiophile music player

Music Player Daemon (MPD) is a great open source tool to turn any computer into a small and lightweight audio player. The control of the player may be performed from any network connected device.

Together with Linux, mpd can turn any PC into a bit perfect transport device for FLAC, AIFF or DSD audio files. For best results, the PC will have to be connected through USB or HDMI/I2S to an external DA-converter. The audio files may be stored locally on the PC, or preferably on a network connected storage device like a NAS.

Modern Linux distributions ship with a standard audio library (pulseaudio) which will resample and convert digital audio on the fly for the best plug-and-play user experience. Default mpd installations will also use those features, which makes it unsuitable for audiophile purposes.

The average audiophile user is less concerned with plug-and-play and more concerned with discretion; he/she wants the computer to act as a high end –black-box like– transport device for delivering the original –non altered– digital audio to the DAC.

This is perfectly feasible with stock Linux and MPD, using a few modifications to the mpd configuration file. However, finding the right values can be daunting for non-computer-savvy audio enthusiasts. This script is aimed at helping those users. It will automagically find the right values and put them in a mpd configuration file.

To determine which formats are natively accepted by your USB DAC, and how it actually behaves when feeding it a certain format, have a look at the article “Which digital audio formats does your USB DA-converter support and use?” Then, convert your audio files accordingly as explained in the article “Script to convert FLAC files using Shibatch SRC while preserving metadata”.

 

Preparation

  1. Install Linux on a computer. This article is geared towards users of Debian and deratives, like Ubuntu. Users of other distributions, like Arch, Fedora, RHEL, Centos may consult the installation Wiki page for mpd
  2. Install mpd on that computer:
  3. Connect the computer to an external (USB-)DAC

Basic usage

  1. Open a terminal by pressing and holding CTRL+ALT while typing T or starting it from the application menu
  2. Make a directory for the script
  3. Change to that directory
  4. Download and unzip the mpd-configure script in some directory
  5. Fill in your preferences in the configuration template, of course you may replace gedit with your favorite text editor
  6. Run the script to generate ~/mpd.conf
  7. Stop mpd. In recent Debian and Ubuntu versions the init scripts for mpd are broken,
    so one should kill mpd by hand. The following commands will make sure mpd
    is stopped, although it will display some errors; these can be ignored 
  8. Move ~/.mpd/mpd.conf to the system wide configuration file /etc/mpd.conf. This way it will be used by the mpd daemon, when the computer is started or when the init/upstart scripts are used manually.
  9. Start the mpd daemon with the new configuration file:

When mpd won’t start or when you want to experiment with different settings, one may repeat the steps above.

Advanced usage

The code for this script is maintained using the software version control system git. With it is even easier to get and update the script

In the future you can update the script to the latest version by changing to the directory created above and entering

For more advanced usage, please consult the README file, the mpd man page, the online mpd user manual and the article “How to setup a bit-perfect digital audio streaming client with free software (with LTSP and MPD)”.

One may browse, share, clone and fork the source code of the script at https://github.com/ronalde/mpd-configure.

Changelog

Apr 21, 2014: Changed configuration snippets
  • from included in code to seperate files in ./confs-available which may be symlinked to ./confs-enabled to activate, ie:
Apr 18, 2014: Major rewrite of the script:
  • moved tests/detect-alsa-output-capabilities.sh to alsa-capabilities
  • modified alsa-capabilities to make it suitable to be sourced or run by itself from the command line
  • added simple and regexp filtering to alsa-capabilities
  • removed alsa interface detection logic out of mpd-configure. This
    is now done sourcing alsa-capabilities.
  • modified mpd-configure to not write to a file by default (see updated README)
Mar 20, 2014:
Jan 6, 2014
  • fixed several typos and explained the usage a bit more
Sep 18, 2013
  • enhanced the mpd-configure script and fixed several (severe) bugs, see changelog

Shibatch SSRC Packages available for Debian and Ubuntu

IconI’ve created installation packages for Shibatch SSRC, the best-in-bread open source sample rate converter for digital audio for easy installation in Ubuntu and Debian.

Follow the installation instructions below to get going.

Installing SSRC on Ubuntu

Ubuntu users can use the corresponding PPA for easy package installation by opening a terminal window (by pressing CTRL+ALT+T on the keyboard) and copying/pasting the following text, followed by pressing [ENTER]:

 

Packages are available for Ubuntu 12.04 LTS (Precise Pangolin), 12.10 (Quantal Quetzal), 13.04 (Raring Ringtail) and 13.10 (Saucy Salamander). Work for supporting the coming 14.04 (Trusty Tahr) is in progress.

Installing SSRC on Debian

Users of Debian can install SSRC using the following actions from the command line:

SSRC packages are avaliable for Debian old-stable (squeeze), stable (wheezy), testing (jessie) and unstable (sid).

Quimup updated to 1.3.1: Packages available for Ubuntu and Debian

IconCoon released version 1.3.1 of his great and fast graphical MPD-client Quimup (formerly known as Guimup) for which I created the corresponding installation packages for Ubuntu and Debian.

Follow the installation instructions below to get going.

Looking for other distibutions? Upstream developer Coonsden has a list, currently with links to repositories for the great Arch distribution and Opensuse.

Installing Quimup on Ubuntu

Ubuntu users can use the corresponding PPA for easy package installation by opening a terminal window (by pressing CTRL+ALT+T on the keyboard) and copying/pasting the following text, followed by pressing ENTER:

 

Packages are available for Ubuntu 12.04 LTS (Precise Pangolin), 12.10 (Quantal Quetzal), 13.04 (Raring Ringtail) and 13.10 (Saucy Salamander). Work for supporting the coming 14.04 (Trusty Tahr) is in progress.

Installing Quimup on Debian

Users of Debian can install Quimup using the following actions from the command line:

Quimup packages are avaliable for Debian old-stable (squeeze), stable (wheezy), testing (jessie) and unstable (sid).

Technicalities

After creating a basic working structure for packaging, I built the packages using the excellent workflow described in PackagingWithGit on the Debian Wiki. This way, when the original tarball from Sourceforge is updated by Coon, updating the master branch in my quimup-repository in git is as easy as:

 

This updates the (pristine) sources from the latest Sourceforge tarball in the upstream branch, while leaving my packiging work (in the master branch) intact and seperated. Super!

To keep track of upstream changes I use the upstream branch, while changes to my packaging sources are tracked in master.

Next, I’ve set up a bzr branch in launchpad to automatically track changes to the github respository on daily basis. From that bzr branch I’ve created a packaging recipe, which builds packages for recent Ubuntu releases as soon as change is detected in the bzr branch. Pheww…

Obligatory screenshots

Screenshot
Quimup 1.3.1 – Media browser (by Year)

Screenshot

Using the Jriver HDtracks downloader on Linux (Ubuntu/Debian)

This workaround currently doesn’t work!

Although the setup works and the program starts, logging again throws an error “Please try again later”.

So, if you want to buy music on hdtracks, first sell your soul, stop down a store and buy the latest Mac or a Windows license. Ah … since you already sold your principles, why don’t you just go ahead and try alternative ways to aquire your music.

Please back my request to jriver to give us access to the native(?) hdtracks downloader they’ve got lying around.

Background

As a result of HDTracks changing its downloader software from a platform independent Java program, to native Windows and Mac programs (developed by JRiver) I can’t use their services anymore. I tried using the Windows emulator wine (actually Crossover). That seemed to work, because installation succeeded and I could even run the software. However, logging in to my account from within the software always failed.

After having used in workaround in the past (thanks to Linux gamer ‘booman’ for providing the trick), now that doesn’t seem to do the trick anymore.

Currently the script at https://github.com/ronalde/hdtracks-downloader has no good use, other than to check the hdtracks help page and the jriver download site for the latest available version of the installer.

Checking for the latest version

  1. Start by opening a terminal window by pressing CTRL+ALT+T and execute the following commands, by copy and pasting them in the terminal window and pressing the [ENTER] key on your keyboard (the lines are explained below):

  2. Run the script to check for the latest version:

Trying if the software works

  1. After having downloaded the script (see step 1 above) run the following command:

Creating a starter

If it works, you might as well create a starter for the software to start it using the normal launcher:

After this, users of Ubuntu Unity and Gnome shell should search for hdtracks, while users of desktop environments with menus should browse to Applications > Multimedia > HDtracks Downloader (using Wine).

Script to convert FLAC files using Shibatch Sample Rate Converter (SSRC) while preserving meta data

When using your PC as a high end audiophile transport device for delevering digital audio to an external DA-converter as explained in How to turn Music Player Daemon (mpd) into an audiophile music player, one has to make sure that the audio files are in a suitable audio format for the DAC. Consult the Background section below to determine which formats are suitable.

The flac-src-shibatch script will take a directory containing digital audio files, and convert it to a chosen bitdepth and sample rate using the not-too-bad Shibatch sample rate converter in “twopass non-fast mode” while preserving the flac metadata stored in the original files. It will put the original files in a tar ball for future usage.

Preparation

  1. Install SSRC: See Shibatch SSRC Packages available for Debian and Ubuntu
  2. Install flac and sox:
  3. Download and unpack the source for the script:

     
  • sox is just needed for obtaining the convenient soxi file analyzer. It is not intended to be used as a replacement for the alsa backend.

Usage

The script resamples and replaces the original files in the directory and makes a tar ball containing the original files:

Where $sourcedir is a directory containing high resolution tagged flac files.

Background

The designer of my excellent Pink Faun 3.24 USB DAC, fitted its DAC with a Tenor USB chip and limited the maximum rate to that of USB Audio Class 1 (24bit / 96KHz) to make sure alle available operating systems can use the DAC as an audio device without having to install additional drivers.

However, when buying audio at HD Tracks  or Channel Classics, I want to get the best format available; currently that would be 24bit/176KHz or 24bit/192KHz. After buying and downloading the files I use Musicbrainz Picard to tag and rename the original files. If necessary I create the Musicbrainz entries myself. I then convert (downsample and convert) the files using my script to 24bit/96KHz when they have a sample rate which is higher than 96KHz. Files with lower sample rates are to be left alone.

To determine which formats are natively accepted by your USB DAC, and how it actually behaves when feeding it a certain format, have a look at What digital audio format (bit depth and sample rate) does your alsa sound card support and what does it actually use?

The resulting quality

The quality of the resulting file depends on a number of factors. The most important factor is the ratio between the original and the desired samplerate.

For instance, when the source file is in a multitude of fs = 48KHz, eg. (fs*4 =) 192KHz or (fs*8 =) 384KHz, the conversion in my case is a matter of simple calculation; leave out each nnd sample, where n is the multiplier devided by two (fs*2 = 96KHz). This effectively makes the audio signal more course because the time between samples will grow with n. Furthermore, the avaliable frequency band will be narrowed (divied by n), following the Nyquist-Shannon theorem (fs/2 – width needed for the lowpass filter). For example a 192KHz sample signal leaves room for a (theoretical) frequency band of <96KHz while the downsampled 96Khz sample will be limited to <48KHz. However, there will be no further interpretation of the audio like in the cases below.

For formats based on fs=44.1KHz,  like (fs * 2 = ) 88.2KHz and (fs * 4 = ) 176.4KHz, I need to let shibatch interpret the source and calculate a new file based on its internal algorithms, a Finit impluse response filter (FIR) applied through Fast Fourier Transforms (FFT). Furthermore, shibatch can be told to apply dithering when desired. This of course means that your milage may vary, depending on the source material. It can be rewarding to try different parameters while listening to the resulting file(s).

The scripts is available for downloading, sharing and modification at https://github.com/ronalde/flac-src-shibatch.

How to setup a bit-perfect digital audio streaming client with free software (with LTSP and MPD)

Introduction

This article describes how to create a software environment on your desktop computer which will make it possible to boot a second computer from the network and use that as the interface between the desktop computer –from which the audio files and the boot environment are served– and the external audio equipment.

The goal is to achieve maximum audio quality using low-cost off-the-shelve equipment and free software and at the same time offering ease of configuration and use. Of course this comes with a price; reading and understanding this article.

When you simply want your PC (with a locally installed mpd) act as an audiophile transport device, please have a look at the article “How to turn Music Player Daemon (mpd) into an audiophile music player”.

Background and goals

I love both music and free software.

After having used the Slimdevices Squeezebox as a streaming client connected to a MSB Link DACII (review) for seven years, I got tired with the fact that I couldn’t use any other client devices or software or formats –the squeezebox client device only outputs 16bit/44.1KHz and can only communicate with the squeezebox server software. Furthermore, my audio equipment didn’t fit my life any more (too big and THX/surround targeted).

In September 2010 I therefore bought a new audio system consisting of small and relative cheap Opera Mezza stereo speakers, the 24 bit Pink Faun USB DAC 3.24 and a Pink Faun D-Power 140 power amplifier in which the excellent engineers of Pink Faun fitted their newly developed remote controlled volume control. The speakers are connected to the amp using Pink Faun SC-4 cable, while Pink Faun IL-2SE cable is used between the amplifier and the DAC. The power and USB-cables I use are all standard cheap ones and leave room for improvement.

After buying this set I started using xbmc on a laptop which was connected to the DAC with a cheap USB cord and really loved the sound. I couldn’t wait to play native 24bit / 96KHz music. All my digital music files where flacced EAC rips of my own CD’s. I bought some 24/96 albums from HDtracks.com but the results were disappointing. After waiting for a while (to let my rather new equipment settle) I tried again with the same results. On the ergonomic side I really liked the fact that I could use my laptop both as a media controller and as sort of a black box by using whatever software client (like banshee and rhythmbox) on my desktop PC and the DLNA/upnp features of pulseaudio.

On the Internet I learned that although the input consisted of 24bit/96KHz files, the actual audio stream received by the USB-DAC was in fact down sampled to 16bit/44.1KHz by some piece of software!

My DAC doesn’t indicate which bit depth or sample rate it uses, but watch out. Even if your DAC does indicate 24bit/96KHz when playing a high resolution file, it could also do so with other formats. That is because the software is also able to upsample, using an arbitrary and bad format conversion algorithm like libsamplerate. To complicate things further, a lot of DACs try to do the same on the hardware side.

The worst case scenario is that when you play a 24bit/96KHz file, it first gets downsampled to 16bit/44.1Khz by the software –again using a fast and sloppy algorithm– and secondly gets upsampled to 24bit/96KHz by the DAC. Instead of crispy tube like sound and depth, you get a MP3 experience.

It seems the price for convenience buys you a ticket to 1990′s ideas of sound perception.

Default pulseaudio with alsa configurations perform on the fly bit depth and sample rate conversion for ensuring a pop and crackle free “plug-n-play” experience (see pulseaudio ticket #930: Media players report 96khz, proc reports 44khz and the article “Which digital audio formats does your USB DA-converter support and use?”). Most audio enthusiasts won’t be thrilled by these “qualities” and would like to leave decoding of the audio stream to (more suitable) external audio equipment like a DA-converter. Sample-rate conversion should be avoided altogether when possible. Currently, one has to bypass the default pulseaudio layer altogether and alter the default alsa configuration to get multi-format bit-perfect output to the external DAC.

In short, my wanted setup had the following requirements:

  • having bit-perfect audio for all digital formats accepted by my DAC
  • having the freedom of only using free software
  • having the freedom of only using open –non patent encumbered– file formats
  • having the freedom to use any client device as a streaming digital audio device
  • having the freedom to use any device for controlling the streaming digital audio device (acting like a “media controller”)

To achieve these goals I’ve made the following choices:

  • create a LTSP environment using my desktop PC as the LTSP server
  • installing a MPD client on the desktop PC or Android client acting as a media controller
  • using an old HP t5725 thin client as the LTSP client
  • this thin client will also act as a (headless) MPD server

The result is whopping! I can plug in any PXE-capable PC, thin client, plug computer or laptop to my LAN and connect it to my DAC with USB. After 15 seconds of booting (serving the LTSP image from a old-school SATA disk) it is a bit perfect audio streaming client. I can use any PC, laptop, tablet, smartphone or tablet to control the music player and browse through my playlists and music library.

Preparation

Step 1: Create a working LTSP-server environment

Follow the instructions to set up a LTSP server and LTSP client image using https://help.ubuntu.com/community/UbuntuLTSP/FatClients.

This process also involves installing and/or configuring DHCP and TFTP to serve the generated LTSP image to LTSP clients.

The result should be:

  • a working DHCP server which has dhcp-boot options filled in for PXE enabled clients
  • a working TFTP server with LTSP client boot scripts in /var/lib/tftpboot/ltsp.i386
  • a working LTSP fat client chroot environment in /opt/ltsp/i386

Step 2: Install mpd in the LTSP client chroot

Install mpd in the LTSP client chroot and disable the default startup scripts to prevent loading mpd at system start as a system daemon.

Open a terminal on the server using CTRL+ALT+T, become root and leave this terminal open throughout this exercise.

Determine where you want to place files.

  • The location of the music library, which in my case consists of a directory per album containing tracks in FLAC format, is presumed to be /srv/media/music in this example, change it to your preference.
  • The home directory of the user that will run mpd, will store the settings and database for mpd. In this example we’ll use /var/lib/mpd for that purpose. Again, change this to your preference.

Next create a system user account on the server for mpd with the proper group id and assign a random generated password to it.

Finally we enter the ltsp chroot created earlier, install mpd and prevent it from being started from its init scripts when the ltsp client boots, because we’ll configure that later on.

Step 3: disable pulseaudio for the LTSP client and make the music library accessible

Dynamic configuration of LTSP clients can be achieved by the configuration file /var/lib/tftboot/ltsp/i386/lts.conf on the LTSP server. Perform the following on the server to add the proper line which disables the auto configuration mechanism for redirecting pulseaudio and at the same time leave alsa intact.

Furthermore, we’ll add the proper lines to lts.conf to make the music directory accessible through sshfs.

 

References:

Step 4: Prepare the user environment

One has to configure a user account on the server which will automagically logon in the LTSP client after it is booted, determine and configure the preferred sound card as exposed by the external DAC and start serving mpd on the local network.

Next, test the LTSP client environment by booting the LTSP client and logging in as the mpd user created above. If you can login and get a proper desktop, continue with the following steps.

Step 5: Download and unpack the mpd-configure script to configure alsa and mpd

Again on the server, download and unpack the mpd-configure script in  /srv/media/mpd. The basic example below will work if you have a single USB DAC. See the README file in the ./mpd-configure directory for additional and more advanced settings.

Test the script by logging on to the LTSP client as user mpd, starting a terminal and executing the following commands. Next, examine the output and modify the settings in mpd-configure.conf until the following conditions are met:

  1. it shouldn’t ask questions about which audio interface you want to use
  2. The paths should match those specified earlier

If the test above succeeds, try starting the mpd application by executing the following command (still logged on the LTSP client as the mpd user).

Step 6: Install a mpd client on the LTSP server

On the server you should now be able to connect to the mpd application running on the LTSP client with a mpd client like the Gnome Music Playing Client (gmpc). Execute the following on the server to install and run this application.

 

You may now start GMPC by looking for it in the starter menu on your normal desktop. In the configuration dialog which appears when you first start gmpc enter the IP address of the LTSP client in the Host section and check the option Automatically connect.

Step 7: Automate the logon process

If these tests succeed, modify ${mpd_dir}/.profile to make sure the script above will start automagically after the mpd user logs on on the LTSP client.

As a final test, reboot the LTSP client and logon as the mpd user ; now mpd should be automatically configured and running.

Finally, modify the LTSP client configuration /var/lib/tftboot/ltsp/i386/lts.conf on the LTSP server. The following command adds the proper lines to make sure the user running mpd logs on automatically after starting the LTSP client.

Restart the LTSP client; it now should automatically logon and start the properly configured mpd. Test it by using the gmpc on the server.

References and thoughts

Drawbacks of the setup

In this setup, one has to make sure that each audio file is properly formatted according to the DAC’s native formats.

The designer of my DAC, Matthijs de Vries, has some good reasons to limit the USB interface of the DAC to 24bit/96KHz as he explains in Dutch in his White Paper “Pink Faun DAC 2 (Oktober 2010)”.

A higher data rate theoretically provides a better output. This appears still not completely true at this time. The disadvantages of 24/192 [USB DAC's] are:

  1. [Support for 24/192 USB-DAC's] is only possible in the newest operating software versions, and is asynchronous. As a result, one needs to fall back on self-developed drivers, which adds another layer in the software stack. 24/96 usually works with the native drivers which are already present [in current operating systems]. The user doesn’t have to install any additional software.
  2. The electronics are much more complex with 24/192; both DSP’s and numerous operations are necessary. The cure quickly becomes worse than the problem.
  3. The sampling frequency determines the resolution bandwidth, which is around 40KHz at 96kHz sampling rate. 192 kHz only gains so much in the audible range.
  4. [Galvanic] isolation does not currently work with 24/192, at the moment, 24/96 is the maximum achievable.

The engineer is –like me– a child of the spirit of early 90′s Dutch universities. He therefore was introduced to a Microsoft dominated computer world, rather than the pre-90′s environments in which open source and Unix dominated universities. You can’t blame him that his perspective on software is Microsoft oriented. Although Microsoft tried to frustrate the further development of the USB Audio Class standard by bailing out and not developing a driver for USB Audio Class 2, fact of the matter is that asynchronous 192kHz USB Audio Class 2 is natively supported on both Linux and Mac since 2010. So his first statement is wrong.

Unfortunately my DAC doesn’t support sample rates which are a multitude of 44.1KHz, like CD (1x=44.1KHZ), DVD-audio (2x=88.2) KHz or PCM converted from DSD (64x=2822.4kHz DSD converted to 4x=176.4Khz PCM). This means that I have to resample those files using a good-as-it-gets software converter.  In my case, I choose to upsample 88.2 to 96KHz and downsample 176.4 to 96Khz using the following script using the Shibatch SRC in twopass non-fast mode algorithm.

To see how your USB DAC behaves, have a look at the article “Which digital audio formats does your USB DA-converter support and use?”.

Good luck

Control a Philips 9000 television (2011) with the remote of a Humax 5050c

The proper code to control your Philips 9000-series (2011 version) like the Philips 32PFL9606H with the remote control that comes with your Humax IHDR 5050C is 0605.

Proceed as follows (see:  English Humax ihdr 5050c User Manual in PDF-format):

  1. Press the TV button once
  2. Press and hold the button again for 3 seconds until it lights up in red
  3. Enter the code 0605; the button will flash 3 times
  4. Press the OK button once

How disable pulseaudio in LTSP

For the purpose of creating a audiophile bit-perfect streaming audio client using LTSP on Ubuntu, I need to disable pulseaudio completely in the client image. In a normal installation one can disable pulseaudio by adding the following line to either the system wide pulseaudio daemon options in /etc/pulse/client.conf or in the users home directory in $HOME/.pulse/client.conf:

In a LTSP client however, this doesn’t work because the LTSP client scripts try very hard to redirect audio from the server (where audio applications normally run) to the client through a virtual pulseaudio interface.

Simply adding the following line to /var/lib/tftboot/ltsp/i386/lts.conf on the server disables this autoconfiguring mechanisme of pulseaudio and leaves alsa intact:

(thanks “alkisg” at #ltsp@freenode)