PREFACE
I started using Linux based streamers in 2009. I started my journey following in the footsteps of the writer of this blog, as did many others. I can't believe it's still up!
https://cheap-silent-usb-linux-music-server.blogspot.com/2009/03/where-it-all-started.html
My PC Engines Alix based streamers still work and function flawlessly even with 192/24 formats, but Voyage Linux is no longer maintained as Debian no longer supports the processor architecture of the Alix. I can't get security updates or newer features of mpd. Because of that, I've recently moved over to thin clients like the Wyse 5070. I once tried using the Raspberry Pi but at the time, it was limited in bandwidth and struggled with heavier formats. I suspect that has changed but the newer Pis aren't as cheap as their old counterparts.
I've added this introduction to show I've been doing this for a while. I've written this post because in my search for a new DAC, I'm seeing a lot of complaints about how the DAC handles cold starting, stopping or changing sample rates. By "cold starting" I mean the DAC is powered up but not already playing or paused. Some of the issues that I've seen reported are:
If manufacturers test for these issues under Linux, they do not perform the testing in a way that will demonstrate issues in a wide variety of setups or sometimes even at all. For example, most modern Linux OS use pulseaudio. Sometimes pulseaudio is configured to resample all output to a default format with a single sample rate. In that case the DAC will never experience a sample rate change.
The "fix" of playing a silent stream in the background to prevent track handling issues is often recommended. The reason this "fix" works is that the pulseaudio mixer resamples any new streams to match the format of the already playing silent stream, even if pulseaudio is not configured to resample by default. It must as the downstream device cannot play two differing formats at once. The "fix" can also conceal cold start or stop issues because there is never a cold start or stop once the silent stream is playing.
In my opinion, the DAC manufacturers could implement better Linux testing by ensuring they function properly in ALSA direct hardware mode - which is the mode that most Linux based, dedicated streamers use. If the DAC behaves well in ALSA direct hardware mode but does not behave well in the other modes, then the manufacturer can point to the software as the source of the issues. If the DAC does not behave well in ALSA hardware direct mode, the best the software can do is cover up the issues by keeping the DAC "always on" by some methods like the silent stream.
I want to design tests that anyone can use to test their DAC under conditions likely to reveal these issues. If the issues are reported, others can get reliable information on how well DACs perform the task of track handling under Linux.
In order to perform these tests you will need to use the Linux terminal command line from a computer such as a PC or Raspberry Pi. The method uses standard Linux utilities that, if not already installed, will be available from the official package manager. I'm hoping to encourage people to run these tests, so I'll carefully describe the commands so you can understand what they do.
ISSUE 1 - Slow "wake up" from cold start
This issue may be caused by a number of things:
For testing purposes, it doesn't matter which of the aforementioned is the cause of the issue. All we need is a test methodology that ensures the DAC under test must "wake up" from a cold start to play a test track and that the test track contains audio content that will reveal issues.
To ensure the DAC under test "wakes up" from a cold start, we will play the track using ALSA direct hardware mode. This will bypass pulseaudio, allowing any issues to be revealed. I will outline that in part 2, but first we will focus on creating the test track.
Part 1: Generate test track file
There are many different approaches to the content of a suitable test track. I settled on a series of 5 pink noise bursts, each 300ms long that begin to fade out immediately so they are the most loud at the start of each burst. These short bursts are separated by 300ms of digital silence. When played, if you hear fewer than 5 bursts, or if the first burst sounds different from the others because the initial loudest part is cut off, you will know there is some delay when your DAC begins from a cold start.
To generate the test track file, we will use the utility sox (SoX - Sound eXchange) : man page
Sox may not be installed on your Linux system by default, but there is a chance some audio package you already have installed has installed it as a dependency. If not, it should be available under your Linux distributions package manager named "sox". When you install sox, the package manager should bring in any dependencies automatically.
Sox is also available for Linux, Windows and Mac at sourceforge. You can use any OS to produce your own test track using the commands in part 1, but I can't offer any help on how to play the tracks via Windows or MacOS that will make the results useful for others as I'm not at all familiar with them. The commands in part 2 are for Linux only.
Sox is a tool that bills itself as the Swiss Army knife of audio manipulation. We will use it to synthesize our test track, but that only scratches the surface; it can do a lot of other things.
NOTE: The reference track created by the following steps in part 1 is available as an attachment to this post inside a zip archive. You may download this, unzip and proceed to part 2 as you still need to ensure you are playing the reference track under the right conditions. If you download it to your Ubuntu system, press play and it works, just because it works for you does not mean that anyone who has issues is doing something wrong and that it "works fine with Linux". For a start, Ubuntu uses pulseaudio, which can mask these kinds of issues because of its software volume control and mixer. Pulseaudio is a fine compromise for a mixed use desktop system - I used my RME ADI DAC in that way, but most dedicated commercial and DIY streamer setups avoid using pulseaudio.
If you play the reference track on your own be aware that it has a peak level of -3db from full scale. Make sure you listen at a low volume at first.
Create burst pink noise component
I'll describe each of the component parameters in the following table:
Create silence component
Combine burst and silence components into reference track
This command instructs sox to repeatedly splice the two tracks together that we created previously to produce an output file of 5 bursts separated by silence in between.
Now we have our reference track named 5_bursts.wav.
Part 2: Playing the test track file
In order to play the test track without interference from other software, we want to use ALSA to directly address the hardware when we play the track. We need to know the card and device numbers for this. To see the card and device numbers we use the command aplay: man page
aplay is part of the package "alsa-utils". It's very likely already installed on your system, but if it is not you can get it from your distributions package manager like we may have done for sox above.
Using the "list" option "-l" aplay enumerates all of the attached ALSA devices.
The command produces a list of attached the ALSA devices. This is an example of what my laptop produces:
In this example I don't have an external DAC attached. You can see the HDMI ports - I have a monitor attached to HDMI 1: [VX2728-QHD]. It is assigned card 0, device 7. HDMI 0 and HDMI 2 have nothing attached to them, so while you can address those to produce output, you won't hear anything. You can also see the laptop's built in sound device [ALC257 Analog]. It is assigned card 1, device 0. Note the card and device number of the device you want to test for the remaining steps.
CAUTION - The following commands bypass the software volume control of your computer. If you rely on it to control the volume of your system, ensure you take steps to protect your speakers and hearing.
To play the test track, we want to ensure that the device under test is not already in use by the operating system or other user software. If the device is in use, understanding cold start behavior can be impossible. To find out if anything is already using the device we want to test, we can simply use aplay to play the test track and direct the output to the hardware using the card and device numbers.
If you hear the track, sweet! You can skip down to the evaluation section.
If you see this, then something is using the device - most likely pulseaudio.
If you know that it is another piece of software like mpd that uses the device directly causing it to be busy, you can play the reference track by loading it into your music database so that mpd can play it from a cold start. Or you can stop the software player using the device, try the above aplay command again and afterward restart the software player.
One way to side step the above error if pulseaudio is using the device is to go to your OS settings and change the audio device in use to any except the one you wish to test. For example if you want to test your USB DAC, change the default OS sound device on your compter to the internal sound device. This should free up your USB DAC for testing and you can change the OS default back to the USB DAC after the test.
If you cannot change the OS default sound to use something else under pulseaudio, fortunately the "pulseaudio-utils" package contains a handy little utility named pasuspender: man page. You may need to install this package via your distribution's package manager. This utility temporarily suspends pulseaudio, releasing any sound devices it uses, and then starts a child process which can contain any commands that you want to run while pulseaudio is suspended. When the child process finishes, pulseaudio is restored.
We will run our aplay command via pasuspender, with a couple of additions to ensure that the device cold starts when aplay begins the reference track.
The above command instructs pasuspender to suspend pulseaudio, then run a shell command "sh -c" that consists of three commands: 1- sleep for 20 seconds, 2- use aplay to play our reference track, 3- followed by another 20 second sleep. After the shell command completes pulseaudio is restored.
One of the above methods should have successfully played the reference track, so we can continue with the evaluation.
Part 3: Evaluation
As mentioned previously, if (after a 20 second delay if you use pasuspender) you hear fewer than 5 bursts, or if the first burst sounds different from the others because the initial loudest part is cut off, you will know there is some delay when your DAC begins from a cold start.
This method may also reveal clicks and pops when the track cold starts or stops that were previously unheard because some other process kept the DAC "on" at all times.
I would be very pleased to receive feedback on this post. Particularly from people who have tried to use the method. This was a learning process for me over the past few days - I am by no means an expert on the Linux audio stack!
Also I would be interested to find out which DACs do and do not suffer from issues. For example, my internal sound card produces no detectable delays or noises, but the sound in my HDMI monitor takes more than 200ms to "wake up". I only hear the end of the first burst followed by the four remaining bursts.
I started using Linux based streamers in 2009. I started my journey following in the footsteps of the writer of this blog, as did many others. I can't believe it's still up!
https://cheap-silent-usb-linux-music-server.blogspot.com/2009/03/where-it-all-started.html
My PC Engines Alix based streamers still work and function flawlessly even with 192/24 formats, but Voyage Linux is no longer maintained as Debian no longer supports the processor architecture of the Alix. I can't get security updates or newer features of mpd. Because of that, I've recently moved over to thin clients like the Wyse 5070. I once tried using the Raspberry Pi but at the time, it was limited in bandwidth and struggled with heavier formats. I suspect that has changed but the newer Pis aren't as cheap as their old counterparts.
I've added this introduction to show I've been doing this for a while. I've written this post because in my search for a new DAC, I'm seeing a lot of complaints about how the DAC handles cold starting, stopping or changing sample rates. By "cold starting" I mean the DAC is powered up but not already playing or paused. Some of the issues that I've seen reported are:
- slow to "wake up" when cold starting a track, resulting in missing the starting few hundred milliseconds of the track
- spurious noises when cold starting or stopping a track
- slow to "wake up" after sample rate changes between tracks
- spurious noises when sample rate changes between tracks
If manufacturers test for these issues under Linux, they do not perform the testing in a way that will demonstrate issues in a wide variety of setups or sometimes even at all. For example, most modern Linux OS use pulseaudio. Sometimes pulseaudio is configured to resample all output to a default format with a single sample rate. In that case the DAC will never experience a sample rate change.
The "fix" of playing a silent stream in the background to prevent track handling issues is often recommended. The reason this "fix" works is that the pulseaudio mixer resamples any new streams to match the format of the already playing silent stream, even if pulseaudio is not configured to resample by default. It must as the downstream device cannot play two differing formats at once. The "fix" can also conceal cold start or stop issues because there is never a cold start or stop once the silent stream is playing.
In my opinion, the DAC manufacturers could implement better Linux testing by ensuring they function properly in ALSA direct hardware mode - which is the mode that most Linux based, dedicated streamers use. If the DAC behaves well in ALSA direct hardware mode but does not behave well in the other modes, then the manufacturer can point to the software as the source of the issues. If the DAC does not behave well in ALSA hardware direct mode, the best the software can do is cover up the issues by keeping the DAC "always on" by some methods like the silent stream.
I want to design tests that anyone can use to test their DAC under conditions likely to reveal these issues. If the issues are reported, others can get reliable information on how well DACs perform the task of track handling under Linux.
In order to perform these tests you will need to use the Linux terminal command line from a computer such as a PC or Raspberry Pi. The method uses standard Linux utilities that, if not already installed, will be available from the official package manager. I'm hoping to encourage people to run these tests, so I'll carefully describe the commands so you can understand what they do.
ISSUE 1 - Slow "wake up" from cold start
This issue may be caused by a number of things:
- power saving settings of USB devices - the OS puts the DAC into power saving mode and is slow to wake up
- power saving settings of DAC hardware and/or DAC firmware - the DAC itself goes into a standby mode after a period of no input signal and is slow to wake up
- hardware implementation of DAC, often related to muting - the DAC is slow to unmute or slow to lock on to the digital input signal
For testing purposes, it doesn't matter which of the aforementioned is the cause of the issue. All we need is a test methodology that ensures the DAC under test must "wake up" from a cold start to play a test track and that the test track contains audio content that will reveal issues.
To ensure the DAC under test "wakes up" from a cold start, we will play the track using ALSA direct hardware mode. This will bypass pulseaudio, allowing any issues to be revealed. I will outline that in part 2, but first we will focus on creating the test track.
Part 1: Generate test track file
There are many different approaches to the content of a suitable test track. I settled on a series of 5 pink noise bursts, each 300ms long that begin to fade out immediately so they are the most loud at the start of each burst. These short bursts are separated by 300ms of digital silence. When played, if you hear fewer than 5 bursts, or if the first burst sounds different from the others because the initial loudest part is cut off, you will know there is some delay when your DAC begins from a cold start.
To generate the test track file, we will use the utility sox (SoX - Sound eXchange) : man page
Sox may not be installed on your Linux system by default, but there is a chance some audio package you already have installed has installed it as a dependency. If not, it should be available under your Linux distributions package manager named "sox". When you install sox, the package manager should bring in any dependencies automatically.
Sox is also available for Linux, Windows and Mac at sourceforge. You can use any OS to produce your own test track using the commands in part 1, but I can't offer any help on how to play the tracks via Windows or MacOS that will make the results useful for others as I'm not at all familiar with them. The commands in part 2 are for Linux only.
Sox is a tool that bills itself as the Swiss Army knife of audio manipulation. We will use it to synthesize our test track, but that only scratches the surface; it can do a lot of other things.
NOTE: The reference track created by the following steps in part 1 is available as an attachment to this post inside a zip archive. You may download this, unzip and proceed to part 2 as you still need to ensure you are playing the reference track under the right conditions. If you download it to your Ubuntu system, press play and it works, just because it works for you does not mean that anyone who has issues is doing something wrong and that it "works fine with Linux". For a start, Ubuntu uses pulseaudio, which can mask these kinds of issues because of its software volume control and mixer. Pulseaudio is a fine compromise for a mixed use desktop system - I used my RME ADI DAC in that way, but most dedicated commercial and DIY streamer setups avoid using pulseaudio.
If you play the reference track on your own be aware that it has a peak level of -3db from full scale. Make sure you listen at a low volume at first.
Create burst pink noise component
Bash:
sox -n -r 44100 -c 2 -b 16 burst.wav synth 0.3 pinknoise gain -3 fade t 0 0.3 0.3I'll describe each of the component parameters in the following table:
| Parameter | Description |
|---|---|
| -n | null input file - tells sox to use a null input, no source audio is needed since we are instructing sox to synthesize the data it needs to make this file |
| -r 44100 | sample rate of output file - I chose the standard CD format here but you could choose any sample rate and bit depth (see below) supported by your DAC |
| -c 2 | number of channels |
| -b 16 | bit depth |
| burst.wav | output file name to create |
| synth 0.3 pinknoise | synthesize 300ms of pink noise |
| gain -3 | sets the output level to -3db from full scale (if you want a lower level to test your system lower the gain to -10) |
| fade t 0 0.3 0.3 | fade the track t = linear envelope fade 0 = length of fade in (no fade in) 0.3 = starting time of fade out (from end of track - so 0.3 begins the fade 300ms before the end of the track which is right at the start) 0.3 = length of fade out (i.e. fade out for 300ms) |
Create silence component
Bash:
sox -n -r 44100 -c 2 -b 16 gap.wav trim 0.0 0.3| Parameter | Description |
|---|---|
| -n | null input file - tells sox to use a null input |
| -r 44100 | sample rate of output file - use the same value as the burst track |
| -c 2 | number of channels - use the same value as the burst track |
| -b 16 | bit depth - use the same value as the burst track |
| gap.wav | output file name to create |
| trim 0.0 0.3 | this trims the null input (which is infinite silence) to 300ms in length |
Combine burst and silence components into reference track
Bash:
sox burst.wav gap.wav burst.wav gap.wav burst.wav gap.wav burst.wav gap.wav burst.wav 5_bursts.wavThis command instructs sox to repeatedly splice the two tracks together that we created previously to produce an output file of 5 bursts separated by silence in between.
Now we have our reference track named 5_bursts.wav.
Part 2: Playing the test track file
In order to play the test track without interference from other software, we want to use ALSA to directly address the hardware when we play the track. We need to know the card and device numbers for this. To see the card and device numbers we use the command aplay: man page
aplay is part of the package "alsa-utils". It's very likely already installed on your system, but if it is not you can get it from your distributions package manager like we may have done for sox above.
Using the "list" option "-l" aplay enumerates all of the attached ALSA devices.
Bash:
aplay -lThe command produces a list of attached the ALSA devices. This is an example of what my laptop produces:
Code:
**** List of PLAYBACK Hardware Devices ****
card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 7: HDMI 1 [VX2728-QHD]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Generic_1 [HD-Audio Generic], device 0: ALC257 Analog [ALC257 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0In this example I don't have an external DAC attached. You can see the HDMI ports - I have a monitor attached to HDMI 1: [VX2728-QHD]. It is assigned card 0, device 7. HDMI 0 and HDMI 2 have nothing attached to them, so while you can address those to produce output, you won't hear anything. You can also see the laptop's built in sound device [ALC257 Analog]. It is assigned card 1, device 0. Note the card and device number of the device you want to test for the remaining steps.
CAUTION - The following commands bypass the software volume control of your computer. If you rely on it to control the volume of your system, ensure you take steps to protect your speakers and hearing.
To play the test track, we want to ensure that the device under test is not already in use by the operating system or other user software. If the device is in use, understanding cold start behavior can be impossible. To find out if anything is already using the device we want to test, we can simply use aplay to play the test track and direct the output to the hardware using the card and device numbers.
Bash:
aplay -D hw:1,0 -i 5_bursts.wav| Parameter | Description |
|---|---|
| -D hw:1,0 | play to a specific device name using hardware addressing "-D hw: card_number,device_number" in my command I am addressing card 1, device 0 - you need to replace the numbers with those you noted from the previous step |
| -i 5_bursts.wav | specifies the input file to play |
If you hear the track, sweet! You can skip down to the evaluation section.
If you see this, then something is using the device - most likely pulseaudio.
Code:
aplay: main:850: audio open error: Device or resource busyIf you know that it is another piece of software like mpd that uses the device directly causing it to be busy, you can play the reference track by loading it into your music database so that mpd can play it from a cold start. Or you can stop the software player using the device, try the above aplay command again and afterward restart the software player.
One way to side step the above error if pulseaudio is using the device is to go to your OS settings and change the audio device in use to any except the one you wish to test. For example if you want to test your USB DAC, change the default OS sound device on your compter to the internal sound device. This should free up your USB DAC for testing and you can change the OS default back to the USB DAC after the test.
If you cannot change the OS default sound to use something else under pulseaudio, fortunately the "pulseaudio-utils" package contains a handy little utility named pasuspender: man page. You may need to install this package via your distribution's package manager. This utility temporarily suspends pulseaudio, releasing any sound devices it uses, and then starts a child process which can contain any commands that you want to run while pulseaudio is suspended. When the child process finishes, pulseaudio is restored.
We will run our aplay command via pasuspender, with a couple of additions to ensure that the device cold starts when aplay begins the reference track.
Bash:
pasuspender -- sh -c "sleep 20; aplay -D hw:1,0 -i 5_bursts.wav; sleep 20"The above command instructs pasuspender to suspend pulseaudio, then run a shell command "sh -c" that consists of three commands: 1- sleep for 20 seconds, 2- use aplay to play our reference track, 3- followed by another 20 second sleep. After the shell command completes pulseaudio is restored.
One of the above methods should have successfully played the reference track, so we can continue with the evaluation.
Part 3: Evaluation
As mentioned previously, if (after a 20 second delay if you use pasuspender) you hear fewer than 5 bursts, or if the first burst sounds different from the others because the initial loudest part is cut off, you will know there is some delay when your DAC begins from a cold start.
This method may also reveal clicks and pops when the track cold starts or stops that were previously unheard because some other process kept the DAC "on" at all times.
I would be very pleased to receive feedback on this post. Particularly from people who have tried to use the method. This was a learning process for me over the past few days - I am by no means an expert on the Linux audio stack!
Also I would be interested to find out which DACs do and do not suffer from issues. For example, my internal sound card produces no detectable delays or noises, but the sound in my HDMI monitor takes more than 200ms to "wake up". I only hear the end of the first burst followed by the four remaining bursts.
Last edited:
