I'm using a Terratec Aureon DualUSB for my sound server (http://www.terratec.net/media/filer_public/10542-en.pdf). This card can be used with either an analog-out or optical-out (SPDIF). The analog output has its own mixer called "Speaker". The digital output has no mixer. There is no "Master" either. The "Speaker" mixer provides wrong dB values to PA, I will file a bug for that later. The digital output can't be controlled at all. All PA does is change the "Speaker" value without having an effect on the volume. I realize that PA can't possibly know if the user is using the analog or digital out. So an important feature in such a case would be for PA to provide an option to skip the hardware mixer entirely and do it in software. This is already possible on a per-application basis, it just needs to be possible on a global scale aswell.
I agree that it would be good to make it possible to disable hardware volume control. I think it's necessary anyway if we want to support volume fading for device volumes some day. It would also serve as a workaround for this hardware as you describe. However, I think a simpler and more user-friendly way to solve this particular issue would be to write a special profile set configuration file for this sound card that would provide two profiles, one for analog and one for digital. The digital profile would be defined so that PulseAudio wouldn't try to use any alsa mixer controls for volume. It should be easy to write such configuration file for someone who knows how to write profile set files. I happen to have this hardware myself, and I'll write the configuration at some point before the 6.0 release. In the mean time, you can apply this simple workaround: In /usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conf there's this: [Element Speaker] required-any = any switch = mute volume = merge override-map.1 = all override-map.2 = all-left,all-right Change "volume = merge" to "volume = zero". That will set the Speaker element to 0dB, and volume control will be done in software. This will also affect the analog output, i.e. you won't have hardware volume control, but I suppose that's OK. Hmm, I guess muting the optical-out doesn't work either, so change "switch = mute" to "switch = on". That will make the device to be always unmuted at hardware level, and mute control will be done in software.
Actually, PA does control the volume to a certain degree. Weird. It seems that by default, it chains a software controller and the "Speaker" mixer together. So from 0-33% I get software control, and from 33-100% I get the Speaker control (which naturally doesn't do anything on the optical output). PA seems to base that decision on the (wrong) dB values that are reported to it. I haven't quite figured out who to complain to about this issue tho. Interestingly, if I set ignore_dB=1 then PA falls back to software-mixing only. That actually seems like a simpler workaround ten yours, Tanu :P
(In reply to comment #2) > Actually, PA does control the volume to a certain degree. Weird. It seems > that by default, it chains a software controller and the "Speaker" mixer > together. So from 0-33% I get software control, and from 33-100% I get the > Speaker control (which naturally doesn't do anything on the optical output). Yes, when dB information is available, PA applies software volume in addition to hardware volume to make arbitrary volumes available, instead of limiting the possible volumes to whatever steps the hardware happens to provide. > PA seems to base that decision on the (wrong) dB values that are reported to > it. I haven't quite figured out who to complain to about this issue tho. The alsa-devel mailing list would be the right place (it's also good to CC the maintainer of the USB audio driver or whatever component is responsible for the dB values - unfortunately, I don't know who that would be or how to find out). It should help your problem to get attention if you can also provide the correct dB values. If you want to work on figuring out the right values, the "decibel fix" feature in PulseAudio may be useful. You can specify the dB values manually in /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf. That file also contains some documentation about the DecibelFix configuration section, but feel free to ask questions if there's something unclear. > Interestingly, if I set ignore_dB=1 then PA falls back to software-mixing > only. That actually seems like a simpler workaround ten yours, Tanu :P That shouldn't happen... ignore_dB=1 should have the opposite effect: software volume should get disabled for the device.
Is this a release blocker because of the ignore_dB behaviour, or something else?
This is a release blocker mainly to remind me to fix this before the release. The bug isn't super important, it's just so simple to fix that I decided to add it to the list of tasks that I want to complete before the release. Feel free to remove the release blocker status if you think it's inappropriate.
Main, could you test if muting the Speaker mixer element has any effect when using digital output? I don't have hardware to test the digital output myself. I wrote a patch that should fix this bug. Instead of using two profiles for selecting between analog and digital, I decided to just disable hardware volume control in both modes, because requiring the user to select the profile manually wouldn't really be very user-friendly. I'll attach the patch here in case you want to try it, but I won't yet send it to the mailing list, because first I want to change things so that sinks default to 30% instead of 100% volume. 100% as the default volume becomes a problem when disabling hardware volume, because previously the alsa sink overrode the default volume for this card with the current value of the Speaker volume element, which alsa probably sets to something sensible by default, but with my patch PulseAudio always sets Speaker to 100% to ensure full volume range when using software volume.
Created attachment 109535 [details] [review] fix
I now sent the patches to the mailing list: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/22253
(In reply to Tanu Kaskinen from comment #3) > (In reply to comment #2) > > Interestingly, if I set ignore_dB=1 then PA falls back to software-mixing > > only. That actually seems like a simpler workaround ten yours, Tanu :P > > That shouldn't happen... ignore_dB=1 should have the opposite effect: > software volume should get disabled for the device. I swear that it reverts to exclusive software-mixing. Maybe it's because PA on this machine is quite old? (Debian stable has PA 2.0) (In reply to Tanu Kaskinen from comment #6) > Main, could you test if muting the Speaker mixer element has any effect when > using digital output? I don't have hardware to test the digital output > myself. I can confirm that muting works on the optical out. > I wrote a patch that should fix this bug. Instead of using two profiles for > selecting between analog and digital, I decided to just disable hardware > volume control in both modes, because requiring the user to select the > profile manually wouldn't really be very user-friendly. Cool, thanks! Wouldn't it suffice to make software mixing the default? Users who use the analog output may then still switch to hardware then (and get lower CPU usage I suppose)
(In reply to Tanu Kaskinen from comment #5) > This is a release blocker mainly to remind me to fix this before the > release. The bug isn't super important, it's just so simple to fix that I > decided to add it to the list of tasks that I want to complete before the > release. Feel free to remove the release blocker status if you think it's > inappropriate. Ok, I removed the release blocker status now.
(In reply to main.haarp from comment #9) > (In reply to Tanu Kaskinen from comment #3) > > (In reply to comment #2) > > > Interestingly, if I set ignore_dB=1 then PA falls back to software-mixing > > > only. That actually seems like a simpler workaround ten yours, Tanu :P > > > > That shouldn't happen... ignore_dB=1 should have the opposite effect: > > software volume should get disabled for the device. > I swear that it reverts to exclusive software-mixing. Maybe it's because PA > on this machine is quite old? (Debian stable has PA 2.0) It sounds unlikely that the behaviour would have changed that way. I'll have to test this myself when I get time. > (In reply to Tanu Kaskinen from comment #6) > > Main, could you test if muting the Speaker mixer element has any effect when > > using digital output? I don't have hardware to test the digital output > > myself. > I can confirm that muting works on the optical out. Hmm, PA seems to do software mute always, even when there's hardware mute available, so the test didn't prove anything. Sorry for wasting your time. If you could make another test with optical output, that'd be nice (but it's not super important): 1) Run "pasuspender -- bash". This will start a new shell, and as long as the shell is running, PA won't access the alsa devices. 2) Run "aplay -D plughw:Device /usr/share/sounds/alsa/Front_Center.wav". It should produce sound (assuming that the Speaker element is not muted). 3) Run "amixer -c Device sset Speaker off" to mute the Speaker element. 4) Run "aplay -D plughw:Device /usr/share/sounds/alsa/Front_Center.wav". 5) Run "amixer -c Device sset Speaker on" to unmute the Speaker element. 6) Exit the shell that was started in step 1. Was there sound in step 4? The reason why I'm so interested in this is that I should document the mute behaviour in the configuration file. I could write there that it's unconfirmed whether the hardware mute works with the optical output, but it would be much nicer to know the real behaviour. > > I wrote a patch that should fix this bug. Instead of using two profiles for > > selecting between analog and digital, I decided to just disable hardware > > volume control in both modes, because requiring the user to select the > > profile manually wouldn't really be very user-friendly. > Cool, thanks! > Wouldn't it suffice to make software mixing the default? Users who use the > analog output may then still switch to hardware then (and get lower CPU > usage I suppose) Yes, we could do that, but I have difficulty to make the profile naming user friendly. There would be three output profiles (plus combinations with inputs) to choose from: Off On (with software volume) On (with hardware volume when using analog output and broken volume when using optical output) Especially the third option name is far too long, and I don't think most users have any idea anyway about what difference it makes to their life whether the volume is "software" or "hardware". I feel that complicating the UI isn't really worth the small performance benefit of hardware volume. By the way, this bug probably won't be fixed in 6.0 unfortunately. The fix has the side effect of making the default volume 100% for this card, which I think is not acceptable, and altering the default volume logic is a bit complicated, so we decided to postpone fiddling with that until the next release. I've made a note for myself to get back to this bug right after the release.
> The digital output can't be controlled at all. All PA does is change the > "Speaker" value without having an effect on the volume. I realize that PA > can't possibly know if the user is using the analog or digital out. So an > important feature in such a case would be for PA to provide an option to > skip the hardware mixer entirely and do it in software. This is already > possible on a per-application basis, it just needs to be possible on a > global scale aswell. what do you mean when you say digital output can't be controlled at all ? do you mean the red light of the optical spdif cannot be turned off ?
(In reply to Raymond from comment #12) > what do you mean when you say digital output can't be controlled at all ? It means that the Speaker volume element doesn't have any effect on the volume when using digital output.
(In reply to Tanu Kaskinen from comment #11) > If you could make another test with optical output, that'd be nice (but it's > not super important): > > 1) Run "pasuspender -- bash". This will start a new shell, and as long as > the shell is running, PA won't access the alsa devices. > > 2) Run "aplay -D plughw:Device /usr/share/sounds/alsa/Front_Center.wav". It > should produce sound (assuming that the Speaker element is not muted). > > 3) Run "amixer -c Device sset Speaker off" to mute the Speaker element. > > 4) Run "aplay -D plughw:Device /usr/share/sounds/alsa/Front_Center.wav". > > 5) Run "amixer -c Device sset Speaker on" to unmute the Speaker element. > > 6) Exit the shell that was started in step 1. > > Was there sound in step 4? There is indeed sound in step 4. So it would appear that neither muting nor volume changes have any sort of influence on the optical output
(In reply to Tanu Kaskinen from comment #11) > (In reply to main.haarp from comment #9) > > (In reply to Tanu Kaskinen from comment #3) > > > (In reply to comment #2) > > > > Interestingly, if I set ignore_dB=1 then PA falls back to software-mixing > > > > only. That actually seems like a simpler workaround ten yours, Tanu :P > > > > > > That shouldn't happen... ignore_dB=1 should have the opposite effect: > > > software volume should get disabled for the device. > > I swear that it reverts to exclusive software-mixing. Maybe it's because PA > > on this machine is quite old? (Debian stable has PA 2.0) > > It sounds unlikely that the behaviour would have changed that way. I'll have > to test this myself when I get time. I now tested ignore_dB with the Aureon card, and it behaved as I expected (hardware volume is still used). What exactly do you mean by "software-mixing"? My assumption is that you mean software volume, not mixing multiple streams (mixing multiple streams is always done in software, since PulseAudio doesn't support hardware mixing). How do you determine whether "software-mixing" or software volume is being used?
did your usb support ac3 passthrough using optical output since there is no iec958 controls and only one plaback device ?
(In reply to Tanu Kaskinen from comment #15) > (In reply to Tanu Kaskinen from comment #11) > > (In reply to main.haarp from comment #9) > > > (In reply to Tanu Kaskinen from comment #3) > > > > That shouldn't happen... ignore_dB=1 should have the opposite effect: > > > > software volume should get disabled for the device. > > > I swear that it reverts to exclusive software-mixing. Maybe it's because PA > > > on this machine is quite old? (Debian stable has PA 2.0) > > > > It sounds unlikely that the behaviour would have changed that way. I'll have > > to test this myself when I get time. > > I now tested ignore_dB with the Aureon card, and it behaved as I expected > (hardware volume is still used). What exactly do you mean by > "software-mixing"? My assumption is that you mean software volume, not > mixing multiple streams (mixing multiple streams is always done in software, > since PulseAudio doesn't support hardware mixing). How do you determine > whether "software-mixing" or software volume is being used? Whoops, I meant software volume, of course. I determined it by changing the volume after enabling ignore_dB. Seeing as I could change the volume of the optical-out properly, it was clear that software volume was used. (In reply to Raymond from comment #16) > did your usb support ac3 passthrough using optical output since there is no > iec958 controls and only one plaback device ? I'm not sure. Never had the opportunity to test that.
can you post the output of your usb audio device lsusb -vvvv
Created attachment 115170 [details] lsusb -vvvv output (In reply to Raymond from comment #18) > can you post the output of your usb audio device > > lsusb -vvvv Here it is.
@Tanu Kaskinen The last two of your three patches never got merged, did they? I recently dug out my Terratec again and gave it another whirl, this time on a modern Gentoo box with Pulseaudio 8. This bug was still present, so I applied the patches myself. This does the job beautifully. I wonder why they didn't get merged. btw. ignore_dB=1 now works for me the same way it did for you.
(In reply to main.haarp from comment #20) > This does the job beautifully. I wonder why they didn't get merged. They didn't get merged, because the "use 30% default volume for all sinks without hardware volume" rule was not good. For example, HDMI sinks don't have hardware volume, but they should have 100% default volume. I haven't prioritized this bug lately as high as previously. I still intend to fix this, but judging from past performance on completing low-priority tasks, the realistic expectation is that I will not get this done any time soon. Sorry about that.
As far as I can tell, the third patch should work fine on its own tho (without the default volume one). Oh well, manual patching works for me in the meantime. Still hoping this gets merged eventually. Thanks for your work on this!
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/106.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.