Digital volume control belongs to the golden bestsellers among audiophiles 
Input precision (information): 16 bit number - X
Divisor: 16 bit number - K
Output: 16 bit number - Y
Y16 = X16 / K16
Now what happens if we add more zero bits to X, some non-zero bits to the divisor K and do the division in higher bitwidth:
Y48 = X48 / K48
Yes, Y48 will have 32 extra non-zero bits. BUT the first 16 bits will be absolutely identical to Y16, for any input values of X16 and K16.
If we decimate back to Y16 by removing the lower 4 bytes (32 bits), we will always get the same number as in the original Y16 calculation. It is simple math.
OK, decimation should be done with dither. But dither by principle affects only the LSB. That means the only difference can be at the 16th, least significant bit. No matter how precise the volume calculation is.
However, we often have 24bit DACs and 16 bit source music. The 24th bit (plus a few more) is always way below the noise of the DAC, dithering at 24 bits is useless (and sound-processing softwares do not do it, unless they are aimed at audiophiles, how typical). Therefore, anything above volume calculation at 24 bits without dither with output at 24 bits without subsequent decimation to 16bits is plain audiophile voodoo. Internal volume control in 24bit DACs does division in 24bits without any dither too and nobody asks about its quality. Well, in the end it is done in HW, thus must be perfect
I understand devices claiming 48bit volume control sell better, as clueless customers do not understand it is just a marketing ploy.
OK, how to do the above. Define output alsa device accepting only 32bits, put softvol below, and let softvol output to the plug plugin adjusting sample width to that supported by your soundcard. That way softvol will run at 32 bits.
Or look at MPD source code, find its internal volume control algorithm (most likely in float or int32), and use that.
In all cases it will not have any effect on the resultant sound whatsoever. But the mind will be calm and that is what counts
Input precision (information): 16 bit number - X
Divisor: 16 bit number - K
Output: 16 bit number - Y
Y16 = X16 / K16
Now what happens if we add more zero bits to X, some non-zero bits to the divisor K and do the division in higher bitwidth:
Y48 = X48 / K48
Yes, Y48 will have 32 extra non-zero bits. BUT the first 16 bits will be absolutely identical to Y16, for any input values of X16 and K16.
If we decimate back to Y16 by removing the lower 4 bytes (32 bits), we will always get the same number as in the original Y16 calculation. It is simple math.
OK, decimation should be done with dither. But dither by principle affects only the LSB. That means the only difference can be at the 16th, least significant bit. No matter how precise the volume calculation is.
However, we often have 24bit DACs and 16 bit source music. The 24th bit (plus a few more) is always way below the noise of the DAC, dithering at 24 bits is useless (and sound-processing softwares do not do it, unless they are aimed at audiophiles, how typical). Therefore, anything above volume calculation at 24 bits without dither with output at 24 bits without subsequent decimation to 16bits is plain audiophile voodoo. Internal volume control in 24bit DACs does division in 24bits without any dither too and nobody asks about its quality. Well, in the end it is done in HW, thus must be perfect
I understand devices claiming 48bit volume control sell better, as clueless customers do not understand it is just a marketing ploy.
OK, how to do the above. Define output alsa device accepting only 32bits, put softvol below, and let softvol output to the plug plugin adjusting sample width to that supported by your soundcard. That way softvol will run at 32 bits.
Or look at MPD source code, find its internal volume control algorithm (most likely in float or int32), and use that.
In all cases it will not have any effect on the resultant sound whatsoever. But the mind will be calm and that is what counts
I think you missed my point- the internal registers for 2 24 bit numbers need to be at least 48 bits. The result if truncated to 16 bits (or even 24 bits) it would benefit from dither.
One of the significant enhancements in the "32" bit DAC's is 32 bit digital volume control. The DACs are still not much better than 22 bits but the reduction in artifacts from the volume control are supposed to be significant. This may explain better: The Well-Tempered Computer or this http://www.esstech.com/PDF/digital-vs-analog-volume-control.pdf . The only reason I brought this up is that a better volume control, like a better sample rate converter, brings a burden in cpu demand, something that is always a tradeout.
One of the significant enhancements in the "32" bit DAC's is 32 bit digital volume control. The DACs are still not much better than 22 bits but the reduction in artifacts from the volume control are supposed to be significant. This may explain better: The Well-Tempered Computer or this http://www.esstech.com/PDF/digital-vs-analog-volume-control.pdf . The only reason I brought this up is that a better volume control, like a better sample rate converter, brings a burden in cpu demand, something that is always a tradeout.
Honestly, I do not know the exact implementation of ALUs, but I am pretty sure the algorithm for multiplication of two numbers in them has been done correctly for a few decades.
How would the truncation to 24bits benefit from dither in the real world?
If the 8 LSBits of 32bit DAC as opposed to 24bit DACs are below the noise level, how do they contribute to the higher resolution? What artifacts of volume control do you mean? It is a simple division/multiplication of all samples by a fixed number.
That material has been here several times. I do not see any valid argument for 32bit DAC in it, it is marketing IMO. If the noise floor is way above 24 bits, what is the advantage of the remaining bits?
Sample rate conversion quality can be measured, pretty much at arbitrary precision. How do you define "better volume control", when the bits below the 24th bit get dropped (or get blurred in the noise for 32bit DACs)?
Digital volume control belongs to the golden bestsellers among audiophiles
Input precision (information): 16 bit number - X
Divisor: 16 bit number - K
Output: 16 bit number - Y
Y16 = X16 / K16
Now what happens if we add more zero bits to X, some non-zero bits to the divisor K and do the division in higher bitwidth:
Y48 = X48 / K48
Yes, Y48 will have 32 extra non-zero bits. BUT the first 16 bits will be absolutely identical to Y16, for any input values of X16 and K16.
If we decimate back to Y16 by removing the lower 4 bytes (32 bits), we will always get the same number as in the original Y16 calculation. It is simple math.
OK, decimation should be done with dither. But dither by principle affects only the LSB. That means the only difference can be at the 16th, least significant bit. No matter how precise the volume calculation is.
However, we often have 24bit DACs and 16 bit source music. The 24th bit (plus a few more) is always way below the noise of the DAC, dithering at 24 bits is useless (and sound-processing softwares do not do it, unless they are aimed at audiophiles, how typical). Therefore, anything above volume calculation at 24 bits without dither with output at 24 bits without subsequent decimation to 16bits is plain audiophile voodoo. Internal volume control in 24bit DACs does division in 24bits without any dither too and nobody asks about its quality. Well, in the end it is done in HW, thus must be perfect
I understand devices claiming 48bit volume control sell better, as clueless customers do not understand it is just a marketing ploy.
OK, how to do the above. Define output alsa device accepting only 32bits, put softvol below, and let softvol output to the plug plugin adjusting sample width to that supported by your soundcard. That way softvol will run at 32 bits.
Or look at MPD source code, find its internal volume control algorithm (most likely in float or int32), and use that.
In all cases it will not have any effect on the resultant sound whatsoever. But the mind will be calm and that is what counts
After a review of some materials, I’d agree with you.
We always talk about individual items like volume controls or dac chips, but if one considers the entire digital signal chain in a playback system, can it possibly support 24 bits of resolution end-to-end?
If not then what resolution?
You system is very likely delivering 24bit dynamic range to your DAC, some parts of it very likely at 32bits. Perhaps if you turn to CERN or NASA engineers, they might help you with a nitrogen-cooled DAC and amplifier delivering 24bit dynamic range to your ears.
However, if you put your volume high enough to discern the 24th bit, at full scale your head will blow up.
Look at e.g. Dynamic Range of Home Listening Roomes and Theaters
However, if you put your volume high enough to discern the 24th bit, at full scale your head will blow up.
Look at e.g. Dynamic Range of Home Listening Roomes and Theaters
I've already tried liquid nitrogen on the DAC and the music sounded too cold.
Its an interesting article that concludes maybe 20 bits under ideal conditions, and of course a golden brain and ears to process the extra bits.
If I knock off a few more bits for age related loss of hearing sensitivity then we are probably around 16 bits no?
Its an interesting article that concludes maybe 20 bits under ideal conditions, and of course a golden brain and ears to process the extra bits.
If I knock off a few more bits for age related loss of hearing sensitivity then we are probably around 16 bits no?
Did you folks notice, that more and more "audiophile" Linux distros (images) for embedded systems are popping up that run either mpd or squeezelite as base !?!?
Usually people report "better sound" than any of the Windows/Mac based audiophile installations and programs ( and that includes those "audiophile" MS/MAC rip offs).
Yep. Took them a while to figure it out.
"Linux Audio - The way to go !!"
That's what I said in 2007.
I'm running a CubieTruck (100$) + (tailormade) ArchLinux + Squeezelite nowadays. This setup runs at 2.5W and even runs on batteries.
Arch is installed to Nand. With a 80$ USB DAC attached and a little extra tuning I've got my best system ever up'n running.
And I do think we're talking about a rather serious "audiophile" performance.
Last night I cleaned up my workshop. Not sure how many boards and parts I've been collecting over the years. PCs, power supplies, DDACS, Twisted Pear Sabres, DDX320, Squeezebox Duet and Touch, asf. asf,.............
All gone. What a relieve.
Great stuff.
Enjoy.
Usually people report "better sound" than any of the Windows/Mac based audiophile installations and programs ( and that includes those "audiophile" MS/MAC rip offs).
Yep. Took them a while to figure it out.
"Linux Audio - The way to go !!"
That's what I said in 2007.
I'm running a CubieTruck (100$) + (tailormade) ArchLinux + Squeezelite nowadays. This setup runs at 2.5W and even runs on batteries.
Arch is installed to Nand. With a 80$ USB DAC attached and a little extra tuning I've got my best system ever up'n running.
And I do think we're talking about a rather serious "audiophile" performance.
Last night I cleaned up my workshop. Not sure how many boards and parts I've been collecting over the years. PCs, power supplies, DDACS, Twisted Pear Sabres, DDX320, Squeezebox Duet and Touch, asf. asf,.............
All gone. What a relieve.
Great stuff.
Enjoy.
Just found your website the other day, soundcheck, while digging around for brutefir and squeezelite info. And now I find you here as well. Awesome info.
I'm in the middle of a project attempting to use hdmi to send 8 channels of LPCM to a standard off-the-shelf HT receiver -- a Denon AVR 790, using xbmc, alsa/jack, brutefir, etc. My initial config consists of a 5.0 system, with the front L/R biamped, filters run by brutefir. I'll be playing with drc-fir initially, and may try Uli's Acourate ($!) at some point.
I'm a Linux nut -- mostly from the server world -- and first used Linux during the floppy distribution days of the 90s. These days I mostly stick with Gentoo, and am obsessed with custom-compiling everything. (I've been using the Gentoo Studio build approach lately, Gentoo Studio - Free and Open Source Professional Digital Audio/MIDI Workstation, even for my servers. I just leave out the realtime preemption where not needed.) Or Xubuntu when I'm feeling lazy and just need something to work quickly.
My gut tells me my Denon AVR DACs won't compete with decent studio-grade DACs, so I may just slap a Layla24 I have into the PC and convert locally, then send 7 channels of line level to the Denon. It will run up to 96kHz without resampling -- well, as far as I know, it's not resampling.
I do have an RME 9652, which would allow connectivity to outboard, ADAT-attached DACs, with full wordclock sync over ADAT. For those who are unaware, ADAT can carry 8 channels of uncompressed 48/24 over a single optical toslink cable. Just thinking out loud. I also see that the minidsp guys now have usb/adat devices, but cannot imagine their clock competes with RME's.
I also have a 2-channel system in the dining room (Denon / Definitive), and this is where squeezelite will likely come in handy. I have an old laptop that I may put Puppy Linux on, and use an Echo cardbus interface to convert. Can you tell I like Echo Audio?
Anyway, this seems like a great place to report on my progress, and I'll hopefully be able to contribute to knowledge pool in the process.
I'm in the middle of a project attempting to use hdmi to send 8 channels of LPCM to a standard off-the-shelf HT receiver -- a Denon AVR 790, using xbmc, alsa/jack, brutefir, etc. My initial config consists of a 5.0 system, with the front L/R biamped, filters run by brutefir. I'll be playing with drc-fir initially, and may try Uli's Acourate ($!) at some point.
I'm a Linux nut -- mostly from the server world -- and first used Linux during the floppy distribution days of the 90s. These days I mostly stick with Gentoo, and am obsessed with custom-compiling everything. (I've been using the Gentoo Studio build approach lately, Gentoo Studio - Free and Open Source Professional Digital Audio/MIDI Workstation, even for my servers. I just leave out the realtime preemption where not needed.) Or Xubuntu when I'm feeling lazy and just need something to work quickly.
My gut tells me my Denon AVR DACs won't compete with decent studio-grade DACs, so I may just slap a Layla24 I have into the PC and convert locally, then send 7 channels of line level to the Denon. It will run up to 96kHz without resampling -- well, as far as I know, it's not resampling.
I do have an RME 9652, which would allow connectivity to outboard, ADAT-attached DACs, with full wordclock sync over ADAT. For those who are unaware, ADAT can carry 8 channels of uncompressed 48/24 over a single optical toslink cable. Just thinking out loud. I also see that the minidsp guys now have usb/adat devices, but cannot imagine their clock competes with RME's.
I also have a 2-channel system in the dining room (Denon / Definitive), and this is where squeezelite will likely come in handy. I have an old laptop that I may put Puppy Linux on, and use an Echo cardbus interface to convert. Can you tell I like Echo Audio?
Anyway, this seems like a great place to report on my progress, and I'll hopefully be able to contribute to knowledge pool in the process.
Usually people report better sound whenever they change anything in their system.
This is so much true...
Hi guys, I would like to have a suggestion from you. I'm searching for a linux distro that is the most complete and easy to use for audio only purpose.
In particular it has to be controllable via android smartphone and I would like to do some things that are really easy to apply on foobar such as: DRC, upsampling, last.fm scrobbler, convolver and other things like that.
Another thing: in your experience is better a very low power fanless pc that only plays music, or a pc that is able to do some upsampling etc?
I have to decide if I'm going to use a low power atom or a sony vaio notebook with a dual-core.
Thanks.
In particular it has to be controllable via android smartphone and I would like to do some things that are really easy to apply on foobar such as: DRC, upsampling, last.fm scrobbler, convolver and other things like that.
Another thing: in your experience is better a very low power fanless pc that only plays music, or a pc that is able to do some upsampling etc?
I have to decide if I'm going to use a low power atom or a sony vaio notebook with a dual-core.
Thanks.
Check out Volumio, which started out as Raspfi, or Rune Audio, there are threads for both of them on DIYAudio, both are designed for ease of use/installation and run on very low power boards such as the Raspberry Pi, and Beaglebone Black, and eventually the Cuebox, Cubieboard(or a variation of it, likely the Cubietruck since it has the most I/O options, and others (Uudoo?). The webUI was developed by the guys who are behind Rune and although they are somewhat behind in adoption, they have been updating the UI and may be the ones to go with.
Home - Volumio - audiophile music player
RuneAudio - Embedded Hi-Fi music player
Home - Volumio - audiophile music player
RuneAudio - Embedded Hi-Fi music player
Last edited:
Hi folks.
I'm currently testing the RME Fireface UCX. The device received quite some good reviews. From a soundquality perspective I think it is really nice.
Most of its great features work well under Windows and OSX only. As usual.
However. The UCX comes with a class compliant (CC) mode.
I've installed latest firmware and newest Alsa.
The latest firmware supposedly allows for multichannel CC mode.
Playback on channel 1/2 immediatly worked with CC turned on. Great!
aplay -L is showing me all kind of surround PCMs, such as surround51,surround71, etc..
It seems Alsa recognizes multichannel PCM option of the UCX.
However. Until now I didn't manage to get anything out of these surround devices. (I tried speaker-test btw). This blog got me started btw.
I'm running a minimal/server installation of Ubuntu btw. No pulseaudio etc. involved.
Any hint how to analyse the issue is highly appreciated.
Thx
I'm currently testing the RME Fireface UCX. The device received quite some good reviews. From a soundquality perspective I think it is really nice.
Most of its great features work well under Windows and OSX only. As usual.
However. The UCX comes with a class compliant (CC) mode.
I've installed latest firmware and newest Alsa.
The latest firmware supposedly allows for multichannel CC mode.
Playback on channel 1/2 immediatly worked with CC turned on. Great!
aplay -L is showing me all kind of surround PCMs, such as surround51,surround71, etc..
It seems Alsa recognizes multichannel PCM option of the UCX.
However. Until now I didn't manage to get anything out of these surround devices. (I tried speaker-test btw). This blog got me started btw.
I'm running a minimal/server installation of Ubuntu btw. No pulseaudio etc. involved.
Any hint how to analyse the issue is highly appreciated.
Thx
For the record.
RTFM. Or better STFM (S for study)
This device is not what I'd call plug'n play. And the manual I'd call a book.
1. In CC mode I had to enable CA for 1:1 routing of all (18) channels.
2. I had to check and adjust all relevant channel gain settings.
All my systems had kernels >3.8 respectively newest Alsa (Cubitruck+Debian Wheezy image + up2date 3.4 kernel)
Below is working:
ecasound -tl -i chan_labels_6.wav -f:s24_le,6,44100 -o alsaplugin,1,0
The 6 channel testfile I downloaded here .
RTFM. Or better STFM (S for study)
This device is not what I'd call plug'n play.
And the manual I'd call a book.1. In CC mode I had to enable CA for 1:1 routing of all (18) channels.
2. I had to check and adjust all relevant channel gain settings.
All my systems had kernels >3.8 respectively newest Alsa (Cubitruck+Debian Wheezy image + up2date 3.4 kernel)
Below is working:
ecasound -tl -i chan_labels_6.wav -f:s24_le,6,44100 -o alsaplugin,1,0
The 6 channel testfile I downloaded here .
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.