[alsa-devel] mmotm 2010-08-11 - audio volume issues
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
Something appears to be borked in the ALSA arena. There's no actual volume coming out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0 to 10% or so, no further. However, experimentation shows that the volume slider in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on what 'Amp-Out vals' lists.
A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only attaching one copy.
It may be the weekend before I find time to do a bisection of this.
At Thu, 12 Aug 2010 14:59:32 -0400, Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
Something appears to be borked in the ALSA arena. There's no actual volume coming out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0 to 10% or so, no further. However, experimentation shows that the volume slider in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on what 'Amp-Out vals' lists.
A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only attaching one copy.
Hm, there shouldn't be a change regarding the volume control. There can be an issue about PCM stream, e.g. in commit eb541337b7a43822fce7d0c9d967ee149b2d9a96 ALSA: hda - Make converter setups sticky
To be sure, could you try to revert it? If it doesn't help but still you get strange volume behavior, please get alsa-info.sh output at different volume levels for comparison.
thanks,
Takashi
On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
Something appears to be borked in the ALSA arena. There's no actual volume coming out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0 to 10% or so, no further. However, experimentation shows that the volume slider in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on what 'Amp-Out vals' lists.
A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only attaching one copy.
It may be the weekend before I find time to do a bisection of this.
Didn't you (like some other people) get into the state where pulseaudio doesn't work? It chooses as an output a dummy driver automatically, then you can change volume, play sound, but actually it all goes to /dev/null.
It took me a while before I figured out that it's a "dummy" driver I have in pulseaudio.
regards,
At Thu, 12 Aug 2010 23:06:22 +0200, Jiri Slaby wrote:
On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
Something appears to be borked in the ALSA arena. There's no actual volume coming out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0 to 10% or so, no further. However, experimentation shows that the volume slider in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on what 'Amp-Out vals' lists.
A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only attaching one copy.
It may be the weekend before I find time to do a bisection of this.
Didn't you (like some other people) get into the state where pulseaudio doesn't work? It chooses as an output a dummy driver automatically, then you can change volume, play sound, but actually it all goes to /dev/null.
It took me a while before I figured out that it's a "dummy" driver I have in pulseaudio.
Looks like there is a breakage regarding open/close due to fs/notify/* changes. I guess you can hear still sounds like:
% aplay -Dplughw foo.wav
Takashi
On Thu, 12 Aug 2010 23:11:42 +0200, Takashi Iwai said:
At Thu, 12 Aug 2010 23:06:22 +0200, Jiri Slaby wrote:
On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
Something appears to be borked in the ALSA arena. There's no actual volume coming out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0 to 10% or so, no further. However, experimentation shows that the volume slider in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on what 'Amp-Out vals' lists.
A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only attaching one copy.
It may be the weekend before I find time to do a bisection of this.
Didn't you (like some other people) get into the state where pulseaudio doesn't work? It chooses as an output a dummy driver automatically, then you can change volume, play sound, but actually it all goes to /dev/null.
It took me a while before I figured out that it's a "dummy" driver I have in pulseaudio.
Looks like there is a breakage regarding open/close due to fs/notify/* changes. I guess you can hear still sounds like:
% aplay -Dplughw foo.wav
Confirming that Linus's patch fixes it for me:
commit 2069601b3f0ea38170d4b509b89f3ca0a373bdc1 Author: Linus Torvalds torvalds@linux-foundation.org Date: Thu Aug 12 14:23:04 2010 -0700
Revert "fsnotify: store struct file not struct path"
This reverts commit 3bcf3860a4ff9bbc522820b4b765e65e4deceb3e (and the accompanying commit c1e5c954020e "vfs/fsnotify: fsnotify_close can delay the final work in fput" that was a horribly ugly hack to make it work at all).
participants (3)
-
Jiri Slaby -
Takashi Iwai -
Valdis.Kletnieks＠vt.edu