phofman said:
I remember the "mixer" setting in the mpd.conf and will try if setting this has the right effect with pulseaudio. The "running at 24+bit" part I will have to read into as well.
Thanks for the thoughts!
Hi there.
Folks keep in mind if doing digital volume control, for best results it should be IMO 64bit float+dither.
Most of the standard sw volume controls will degrade the sound even if you run 24bit.
So - you better make sure to get to know what your chosen volume control is actually
doing.
And you'd better avoid large scale attentuations if running digital.
Cheers
Folks keep in mind if doing digital volume control, for best results it should be IMO 64bit float+dither.
Most of the standard sw volume controls will degrade the sound even if you run 24bit.
So - you better make sure to get to know what your chosen volume control is actually
doing.
And you'd better avoid large scale attentuations if running digital.
Cheers
Please could you give any explanation why volume control in 64-bit float is better than 24-bit integer?
These days most cards regulate volume via DAC control circuits which is pure division, perhaps including dither. Even the best 24-bit audio DACs have a S/N resolution of around 20 bits max, there is a 4-bit margin (-24dB) available for digital division with no practical effect.
It certainly makes sense to control volume after upsampling, to keep maximum resolution of the DSP routines.
These days most cards regulate volume via DAC control circuits which is pure division, perhaps including dither. Even the best 24-bit audio DACs have a S/N resolution of around 20 bits max, there is a 4-bit margin (-24dB) available for digital division with no practical effect.
It certainly makes sense to control volume after upsampling, to keep maximum resolution of the DSP routines.
Indeed, however there can be practical reasons for favouring floating point even if not doubles for some gain controls (primarily if using jackd which carts all audio around as floating point with conversion to whatever the soundcard uses only occurring in the back end (and yes, it does dither)).
About the only time doubles are really required for audio work is in IIR filters which can be sensitive to truncation (especially true of low frequency or high Q filters), normally very obvious when it becomes a problem. For most other things doubles are just ego boo for the allegedly golden eared, 32 bit FP is way more then any ADC or DAC can handle (and probably always will be, given the limitations imposed by thermal noise).
Floating point can be a bit subtle, but is IMHO normally the way to go for signal processing apps (At least on recent X86).
Regards, Dan.
About the only time doubles are really required for audio work is in IIR filters which can be sensitive to truncation (especially true of low frequency or high Q filters), normally very obvious when it becomes a problem. For most other things doubles are just ego boo for the allegedly golden eared, 32 bit FP is way more then any ADC or DAC can handle (and probably always will be, given the limitations imposed by thermal noise).
Floating point can be a bit subtle, but is IMHO normally the way to go for signal processing apps (At least on recent X86).
Regards, Dan.
Hi folks.
To shed some light on the Float/Dither subject I attached two links.
Float:
This is well worth reading: http://www.dspguide.com/ch28/4.htm
DITHER:
http://www.cadenzarecording.com/images/floatingdither.pdf
If you run brutefir you can hear the difference between 32bit and 64bit.
Q: How many 64 bit DSPs have you seen out there. Our dear manufacturers have to live
with the things which are available out there.
As you might have realized all serious sample rate conversions are calculating with a bit depth of 64bit
Don't mix up 64bit DSP with 24bitDA. After reading above you'd realize that this is
a different subject.
Cheers
To shed some light on the Float/Dither subject I attached two links.
Float:
This is well worth reading: http://www.dspguide.com/ch28/4.htm
DITHER:
http://www.cadenzarecording.com/images/floatingdither.pdf
If you run brutefir you can hear the difference between 32bit and 64bit.
Q: How many 64 bit DSPs have you seen out there. Our dear manufacturers have to live
with the things which are available out there.
As you might have realized all serious sample rate conversions are calculating with a bit depth of 64bit
Don't mix up 64bit DSP with 24bitDA. After reading above you'd realize that this is
a different subject.
Cheers
I thought the argument was about volume control. DA conversion is almost always in 24bit integer and volume control makes sense right before. Many alsa drivers utilize master volume using the softvol plugin which is in integer format too.
DSP operations are something else, volume control is just a single division operation.
DSP operations are something else, volume control is just a single division operation.
The soundcard interface controller chip, before the DAC, is quite commonly 32-bit floating point e.g. the via envy chipsets, I think the TI usb interfaces and probably all of those used in decent sound cards.
So integer software volume control will be converted to floating point in hardware before integer DA conversion in many cases.
It seems foobar on windows runs 64 bit floating point internally for all DSP and volume control, and then the applications output is set to match the sound card format.
Ross
So integer software volume control will be converted to floating point in hardware before integer DA conversion in many cases.
It seems foobar on windows runs 64 bit floating point internally for all DSP and volume control, and then the applications output is set to match the sound card format.
Ross
To rossco_50:
Envy24 datasheets are available on internet. I have read the document many times while working on several ice1724-based cards alsa support (e.g. Audiotrak Prodigy192, ESI Juli). There is no single mention of floating point. It makes perfect sense as envy has no DSP. It takes 32-bit integer input data via DMA (as most cards do), but outputs only 24-bit digital audio data.
TI - which USB controller supports floating point? I searched a few of their datasheets (mostly the classical pcm27xx family), no talk of floating point.
But there is no need to make guesses. We have alsa drivers, a perfect ultimate information source. Open http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/sound/pcm.h?a=ppc#L132 and have a look which drivers support which data format defined by SNDRV_PCM_FMTBIT_XXX constants. Mostly 32bits, some 16bits, very few float. E.g. the usb driver supports the floating point format USB_AUDIO_FORMAT_IEEE_FLOAT, but which usb card actually accepts this format?
Of course, sophisticated cards featuring DSP cores can calculate in floating point, X-Fi as an example. Though that does not say X-Fi accepts floating-point input data (which I doubt but have no supporting information).
Regulating volume by the audio player directly should be optional (as is the case with decent linux players (mpd, mplayer, etc). By default, the player should use controls provided by the driver via corresponding APIs. As I said, some cards have no internal master volume control and alsa-lib creates a virtual softvol control for them, some cards regulate volume in digital domain (mostly after upsampling in the DAC), some feature even analog domain attenuators, e.g. Revolution 5.1. You can control volume with a motor-driven Alps, just make a simple I2C control interface and modify the Alsa driver of your card to provide master volume via I2C (btw a rather simple task for envy-based cards using the envy's built-in i2c port). It would be fun watching the knob turn while scrolling the mouse wheel 🙂
Envy24 datasheets are available on internet. I have read the document many times while working on several ice1724-based cards alsa support (e.g. Audiotrak Prodigy192, ESI Juli). There is no single mention of floating point. It makes perfect sense as envy has no DSP. It takes 32-bit integer input data via DMA (as most cards do), but outputs only 24-bit digital audio data.
TI - which USB controller supports floating point? I searched a few of their datasheets (mostly the classical pcm27xx family), no talk of floating point.
But there is no need to make guesses. We have alsa drivers, a perfect ultimate information source. Open http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/sound/pcm.h?a=ppc#L132 and have a look which drivers support which data format defined by SNDRV_PCM_FMTBIT_XXX constants. Mostly 32bits, some 16bits, very few float. E.g. the usb driver supports the floating point format USB_AUDIO_FORMAT_IEEE_FLOAT, but which usb card actually accepts this format?
Of course, sophisticated cards featuring DSP cores can calculate in floating point, X-Fi as an example. Though that does not say X-Fi accepts floating-point input data (which I doubt but have no supporting information).
Regulating volume by the audio player directly should be optional (as is the case with decent linux players (mpd, mplayer, etc). By default, the player should use controls provided by the driver via corresponding APIs. As I said, some cards have no internal master volume control and alsa-lib creates a virtual softvol control for them, some cards regulate volume in digital domain (mostly after upsampling in the DAC), some feature even analog domain attenuators, e.g. Revolution 5.1. You can control volume with a motor-driven Alps, just make a simple I2C control interface and modify the Alsa driver of your card to provide master volume via I2C (btw a rather simple task for envy-based cards using the envy's built-in i2c port). It would be fun watching the knob turn while scrolling the mouse wheel 🙂
Phofman,
Thanks for the info - my mistake. I somehow remembered it as floating point, but you are quite correct.
By the way, I have an envyht-s card which is recognised as a chaintech av710 by alsa. However, it has spdif in and is more like the maddog entertainer. Alsa does not pick up the spdif in. the envyht-s seems to share a datasheet with the envyht which suggests that both can sync to spdif input - however this feature is never utilised in the windows drivers. Do you know if the card could be made to work like this under alsa?
One developer had indicated that he thought he could do this, but I never heard back from him.
Ross
Thanks for the info - my mistake. I somehow remembered it as floating point, but you are quite correct.
By the way, I have an envyht-s card which is recognised as a chaintech av710 by alsa. However, it has spdif in and is more like the maddog entertainer. Alsa does not pick up the spdif in. the envyht-s seems to share a datasheet with the envyht which suggests that both can sync to spdif input - however this feature is never utilised in the windows drivers. Do you know if the card could be made to work like this under alsa?
One developer had indicated that he thought he could do this, but I never heard back from him.
Ross
It is very likely feasible. Please post a high-definition picture of the card so that I can read letters on its chips. It may require manually tracing interconnects between pins, finding which GPIOs are hooked to the SPDIF receiver pins if I2C is not used.
BTW, it is interesting that the card identifies as Chaintech av710, i.e. having the same PCI identification codes.
We should move from this thread, perhaps private messages will do.
BTW, it is interesting that the card identifies as Chaintech av710, i.e. having the same PCI identification codes.
We should move from this thread, perhaps private messages will do.
Interesting read!
I remember a discussion on the amounts of bits DACs use internally (around here in another thread) and though it made sense. But that it is of importance to go 64 bit for 24bit streams? No, new for me.
Is there a way (link to page) to ensure digital attenuation in 64bit, as is suggested, on linux? Perhaps as example using mpd with alsa/pulseaudio? 😀
I remember a discussion on the amounts of bits DACs use internally (around here in another thread) and though it made sense. But that it is of importance to go 64 bit for 24bit streams? No, new for me.
Is there a way (link to page) to ensure digital attenuation in 64bit, as is suggested, on linux? Perhaps as example using mpd with alsa/pulseaudio? 😀
64-bit DSP processing makes good sense as a single sample can forgo thousands of multiplications by very long floats and additions of the other floating-point sub-results.
Volume control means dividing every sample by a single integer number. Quantization error is one least significant bit, which is way below noise level of any real-world 24-bit DAC. Of course, if you repeat the process many times (as in case of DSP), it makes a huge difference.
Volume control means dividing every sample by a single integer number. Quantization error is one least significant bit, which is way below noise level of any real-world 24-bit DAC. Of course, if you repeat the process many times (as in case of DSP), it makes a huge difference.
phofman speaks the truth.
Also I would prefer analog rather than digital volume control.
OK, let's suppose I want to be able to make quite loud parties. So I set the gain on the amp pretty loud. This will also be useful for those really quiet classical CDs. Generally though I'll listen to perhaps -30dB, which is about -5 bits. So I'm throwing away 5 DAC bits...
Not to mention the fact that when you'll get an OS sound bug (CLICK !) it's pretty annoying when the amp is set at max volume.
Also I would prefer analog rather than digital volume control.
OK, let's suppose I want to be able to make quite loud parties. So I set the gain on the amp pretty loud. This will also be useful for those really quiet classical CDs. Generally though I'll listen to perhaps -30dB, which is about -5 bits. So I'm throwing away 5 DAC bits...
Not to mention the fact that when you'll get an OS sound bug (CLICK !) it's pretty annoying when the amp is set at max volume.
.: ZMN :. said:
Something I stumbled across recently indicates that mpd uses a 16-bit internal architecture. If so, then you wouldn't want mpd to do any processing on the signal at all.
Jack runs with 32 bit floats internally, and IMHO this is fine if your volume control is the last element in your signal chain before it hits the soundcard. The computation is straightforward, and there really isn't any need for additional resolution for a single-stage computation.
If you really really really want 64 bit, then brutefir is probably the simplest path - start it up with the console port enabled and wrap a script around 'nc' to send vol change commands to it.
Right : jack is 32bit floats.
Is there a simple software volume control for JACK (something integrated to JACK or something light to put on the signal way in patchbay/connection tab of JACK).
32bit float is OK for me.
thanks in advance
Is there a simple software volume control for JACK (something integrated to JACK or something light to put on the signal way in patchbay/connection tab of JACK).
32bit float is OK for me.
thanks in advance
dwk123 said:
LOL. I would love to set things up 64-bit DSP throughout the sound paths, but the fanless CPU might think otherwise. 😀 I compared the mpd 'software' mixer with the direct pass through and noted the latter is slightly better. Thanks for mentioning!
Amazing how little changes to setup/settings improve sound. And it is such a puzzle!
If it helps someone starting: for me, the best changes so far to a standard Ubuntu 8.04 were the addition of rt-linux, setting up pulseaudio to use the rt and the speex-float-10 mixer (well, unfortunately it uses ~45% CPU on any mp3,
) and now added: the 'bypass' of the mpd mixer. I admit, in the whole sound chain in my setup (now: FLAC -> mpd -> pulseaudio -> USB receiver -> DAC) still many things are left to be improved. Next up using the optical out instead of the USB... and trying Jack.
phofman said:
I think understand what you mean, but I am not sure how to set/check to be sure of the situation now. It must be a daemon setting.
The FLAC files I produced from CD. MPD output goes via pulseaudio to a USB receiver which accepts 16bit/44k, so I think re-sampling is indeed not required. Good idea, will try PA without resampler.
I have actually not been able to figure out how/where pulseaudio changes volume in digital domain (at which accuracy, and if the speex resampler has anything to do with it at all).
You can set the default sample rate in pulseaudio configuration, see
http://manpages.ubuntu.com/manpages/hardy/man5/pulse-daemon.conf.html
I just found an interesting discussion about the sample rate in pulseaudio:
http://www.pulseaudio.org/ticket/262
BTW, I agree with the guy that the sample rate selection could be optimized when playing just a single stream.
That is why we have source code available 🙂 The volume control is handled by function pa_volume_memchunk http://pulseaudio.org/browser/src/pulsecore/sample-util.c#L525 . As you can see, the volume is processed for each sample format individually (well done). Nevertheless, in the end it is always just pure division, no need for anything else.
The resample plugin has nothing to do with volume control.
Perhaps you want to take a look around the project more. If you want to browse the code:
1. Install cscope
sudo aptitude install cscope
2. download the source code
apt-get source pulseaudio
Go to the created directory pulseaudio..., run
EDITOR=gedit cscope -R
Now you can search for definitions and occurences of structures and functions, found initially e.g. via http://pulseaudio.org/browser/src . Tab switches the mode, enter will open the file in gedit at the correct line.
Linux is no voodoo.
http://manpages.ubuntu.com/manpages/hardy/man5/pulse-daemon.conf.html
I just found an interesting discussion about the sample rate in pulseaudio:
http://www.pulseaudio.org/ticket/262
BTW, I agree with the guy that the sample rate selection could be optimized when playing just a single stream.
That is why we have source code available 🙂 The volume control is handled by function pa_volume_memchunk http://pulseaudio.org/browser/src/pulsecore/sample-util.c#L525 . As you can see, the volume is processed for each sample format individually (well done). Nevertheless, in the end it is always just pure division, no need for anything else.
The resample plugin has nothing to do with volume control.
Perhaps you want to take a look around the project more. If you want to browse the code:
1. Install cscope
sudo aptitude install cscope
2. download the source code
apt-get source pulseaudio
Go to the created directory pulseaudio..., run
EDITOR=gedit cscope -R
Now you can search for definitions and occurences of structures and functions, found initially e.g. via http://pulseaudio.org/browser/src . Tab switches the mode, enter will open the file in gedit at the correct line.
Linux is no voodoo.
Hi folks.
My point of view::
MPD 16bit:
It'll do perfect for 16bit material - just as a streaming client.
I e.g. don't use it's volume control, I don't need it. I stream right into the DAC.
It delivers a pretty low jitter stream, compared to other appliications and it is very
flexible.
Jack 32bit float:
Jack is made for manageing multiple sources and running multiple sinks with different formats. 32bit float is the chosen common denominator. For basic audio playback Jack is IMO total overkill. And finally it outputs to Alsa anyhow.
Pulseaudio:
I don't need it. The poor mans Jack. It is - again - just another layer in between.
Integer volumecontrol:
I don't really buy phofmans statement that volume control is fine when done as integers.
Any arithmetic operation on the samples should be done with -best- 64bit floats.
Would be nice to be able to directly compare these two.
VolumeControl:
We're at DIY audio over here - aren't we? I mentioned that before. Of course if you loose 5bits, digital control would be nonsense. But if you allign the gain in your entire chain
you'll get along with much less. I loose 2 bit max on high gain stuff (XRCDs or other "modern" high gain recordings). Standard stuff runs almost neutral. The losses are IMO
less of an evil compared to the pre-amps/pots/transformer-pots with all its cables/connectors/caps - you name it - inside the stream.
The good thing here, at a cost of almost nothing (loosing 2 bit max.) you'll beat real world pre-amps worth 100s or 1000s of $.
Other formats than .wav:
Due to sound degradation effects IMO .flac is not acceptable. I know this is a never ending discussion. I experienced 10% higher CPU consumption, when decoding flacs. The side-effects of the higher CPU consumption are most probably the cause for the sound degradation.
MP3 is of course not worth mentioning, when talking about high-end sound-quality.
Samplerates: In most of the cases it should really be avoided to touch these.
Cheers
My point of view::
MPD 16bit:
It'll do perfect for 16bit material - just as a streaming client.
I e.g. don't use it's volume control, I don't need it. I stream right into the DAC.
It delivers a pretty low jitter stream, compared to other appliications and it is very
flexible.
Jack 32bit float:
Jack is made for manageing multiple sources and running multiple sinks with different formats. 32bit float is the chosen common denominator. For basic audio playback Jack is IMO total overkill. And finally it outputs to Alsa anyhow.
Pulseaudio:
I don't need it. The poor mans Jack. It is - again - just another layer in between.
Integer volumecontrol:
I don't really buy phofmans statement that volume control is fine when done as integers.
Any arithmetic operation on the samples should be done with -best- 64bit floats.
Would be nice to be able to directly compare these two.
VolumeControl:
We're at DIY audio over here - aren't we? I mentioned that before. Of course if you loose 5bits, digital control would be nonsense. But if you allign the gain in your entire chain
you'll get along with much less. I loose 2 bit max on high gain stuff (XRCDs or other "modern" high gain recordings). Standard stuff runs almost neutral. The losses are IMO
less of an evil compared to the pre-amps/pots/transformer-pots with all its cables/connectors/caps - you name it - inside the stream.
The good thing here, at a cost of almost nothing (loosing 2 bit max.) you'll beat real world pre-amps worth 100s or 1000s of $.
Other formats than .wav:
Due to sound degradation effects IMO .flac is not acceptable. I know this is a never ending discussion. I experienced 10% higher CPU consumption, when decoding flacs. The side-effects of the higher CPU consumption are most probably the cause for the sound degradation.
MP3 is of course not worth mentioning, when talking about high-end sound-quality.
Samplerates: In most of the cases it should really be avoided to touch these.
Cheers
- Status
- Not open for further replies.