Bug #13098
open
Low output level from audio devices
0%
Description
Many people have noticed this problem, but I have actual measurements that illustrate it. For measurement, I used Audacity running on a Windows computer. For the connection from the audio source to the measurement box, I used a stereo splitter with a cable to the Windows audio input. I used three source computers, Intel and AMD systems and the Windows system. On the first two, I generated audio with both audioplay and firefox. On each source, I also had speakers connected to the splitter as well, so I could hear the sound.
In Audacity, I had the input slider set at 0.5 . I enabled monitoring, and noted the peak input level on the input meter.
With audioplay, I ran rooster.au in a loop until I got the measurement I needed. Audioplay sends the audio directly to the audio device. Pulseaudio is not involved.
With firefox, I played the same youtube song on each source computer. I assume that Pulseaudio is involved in this test.
The Intel computer used an ASUS PRIME B360M-A motherboard with an Intel(r) Core(tm) i3-9100 CPU and ran OI. It used the audiohd driver. The audio output slider was at 94%. With both audioplay and firefox, the output level was -24 db. I'd call this audio level low but acceptagle.
The AMD computer used an ASUS PRIME B350M-A motherboard with an AMD Ryzen 3 1200 CPU. It also ran OI and also used the audiohd driver. The audio output slider was at 93%. With both audioplay and firefox, the output level was -33 db. I'd call this audio level faint and unacceptable.
The Windows computer was an HP 8000 Elite SFF machine with an Intel Core2 Duo E8500 CPU and ran Windows 10. The audio output slider was at 98%. With firefox, the output level was -6 db. I'd call this audio level loud.
I conclude that the driver or the hardware is responsible for the low volume, since audioplay and firefox produce the same output level. People usually blame pulseaudio for the low volume, but this seems not to be the case. I also conclude that the volume on AMD is lower than on Intel, by 9 db and that the volume on both OI machines is lower than on Windows, by 15 and 24 db respectively.
Updated by Gary Mills over 2 years ago
The AMD computer has two audio devices and two mixers. In my audio level tests, pulseaudio was using the correct audio device but the wrong mixer. When I fixed this problem in pulseaudio, the audio level increased to become similar to the Intel computer. With my firefox test, the audio level was -25 db. I'd call this level low but acceptable.
That result again implicates the device driver as the software responsible for the low audio level.
Updated by Tony Albers over 2 years ago
I'm seeing this issue too, makes it impossible to use Zoom in a Virtualbox VM running linux. Sound output is low, but not unacceptable. The microhone is so low that it's almost inaudible. This makes the microphone unusable.
It does not seem to be pulseaudio related, since audiorecord and audioplay which uses the hardware directly shows exactly the same behaviour.
IMO this should probably be looked into ASAP since using a VM with linux actually makes OI usable as an everyday workstation even for businesses that use zoom and MS Teams.
Thanks,
/tony
Updated by Jeremy Andrews over 1 year ago
I definitely encountered this issue, but I assumed the low level of audio output was intentional behavior rather than a bug. Essentially, I thought that the kernel was originally designed to run on high-end Sun workstations, and so any use of audio on such a workstation have would have likely used a setup that sends line-level audio through a pre-amplifier rather than being directly attached to the machine like on a normal desktop. Often audio professionals prefer to have line-level output that is very pure, so it can be sent to a pre-amplifier and dealt with manually, therefore no software/driver amplification of the signal is performed.
And naturally, if illumos is also mostly used on servers or workstations that would only deal with audio through a powered amplifier or something if at all, then a lot of people would not notice the issues you see when you hav audio devices directly attached to a machine running it.
I have my audio outputs running into a stereo system on my machine, and I essentially have to turn the volume knob up several notches more than normal to amplify the audio, but the sound seems clean enough as long as it is manually amplified later on. I guess the question is, should the audio outputs be considered a line-level output that needs external amplification, or should it be amplified with the assumption that audio hardware could be directly attached without an amplifier sitting in-between?
Updated by Joshua M. Clulow over 1 year ago
Jeremy Andrews wrote in #note-3:
I definitely encountered this issue, but I assumed the low level of audio output was intentional behavior rather than a bug. Essentially, I thought that the kernel was originally designed to run on high-end Sun workstations, and so any use of audio on such a workstation have would have likely used a setup that sends line-level audio through a pre-amplifier rather than being directly attached to the machine like on a normal desktop. Often audio professionals prefer to have line-level output that is very pure, so it can be sent to a pre-amplifier and dealt with manually, therefore no software/driver amplification of the signal is performed.
And naturally, if illumos is also mostly used on servers or workstations that would only deal with audio through a powered amplifier or something if at all, then a lot of people would not notice the issues you see when you hav audio devices directly attached to a machine running it.
I have my audio outputs running into a stereo system on my machine, and I essentially have to turn the volume knob up several notches more than normal to amplify the audio, but the sound seems clean enough as long as it is manually amplified later on. I guess the question is, should the audio outputs be considered a line-level output that needs external amplification, or should it be amplified with the assumption that audio hardware could be directly attached without an amplifier sitting in-between?
I expect that when working correctly, it would be able to reach the same volume of output as other operating systems when running on identical hardware. If another operating system can reach a higher output volume than we can, that's almost certainly a bug that can be fixed and not intentional behaviour.
Updated by Gary Mills over 1 year ago
A slightly related bug is this one: 10619 audiohd ignores digital output pins such as HDMI/DP
Updated by Stephan Althaus over 1 year ago
Some additional information regarding the topic from my perspective/case
I am happy with the output volume (laptop integrated audio via laptop-speakers) with my settings doing this way:
$ audioctl list-devices -v
audiohd#5 (/dev/sound/audiohd:5mixer)
audiohd#6 (/dev/sound/audiohd:6mixer)
$ audioctl set-control -d audiohd#5 volume 95
$ audioctl set-control -d audiohd#5 -v speaker 100:100
$ audioctl set-control -d audiohd#5 -v headphones 100:100
$ audioctl set-control -d audiohd#5 -v front 100:100
$ audioctl set-control -d audiohd#5 -v mic 100:100
$ audioctl show-control -d audiohd#5
Mic is working well with an USB headset, tested with audacity with temporarily disabled pulseaudio (pulseaudio -k).
(Web Mic with firefox not working yet)