Bug#931507: [PATCHv2] hda: Fix 1-minute detection delay when i915 module is not available

[Takashi Iwai]

On Fri, 26 Jul 2019 23:47:02 +0200,
Samuel Thibault wrote:
> 
> Distribution installation images such as Debian include different sets
> of modules which can be downloaded dynamically.  Such images may notably
> include the hda sound modules but not the i915 DRM module, even if the
> latter was enabled at build time, as reported on
> https://bugs.debian.org/931507
> 
> In such a case hdac_i915 would be linked in and try to load the i915
> module, fail since it is not there, but still wait for a whole minute
> before giving up binding with it.
> 
> This fixes such as case by only waiting for the binding if the module
> was properly loaded (or module support is disabled, in which case i915
> is already compiled-in anyway).
> 
> Signed-off-by: Samuel Thibault 

Applied with a slight coding style fix in my side.  Also added Fixes
and Cc-to-stable tags.

At the next time, please check the patch before submission via
checkpatch.pl.


Thanks!

Takashi

Bug#931507: hda: Fix 1-minute detection delay when i915 module is not available

[Takashi Iwai]

On Fri, 26 Jul 2019 17:05:30 +0200,
Samuel Thibault wrote:
> 
> Distribution installation images such as Debian include different sets
> of modules which can be downloaded dynamically.  Such images may notably
> include the hda sound modules but not the i915 DRM module, even if the
> latter was enabled at build time, as reported on
> https://bugs.debian.org/931507
> 
> In such a case hdac_i915 would be linked in and try to load the i915
> module, fail since it is not there, but still wait for a whole minute
> before giving up binding with it.
> 
> This fixes such as case by only waiting for the binding if the module
> was properly loaded (or module support is disabled, in which case i915
> is already compiled-in anyway).
> 
> Signed-off-by: Samuel Thibault 
> ---
>  sound/hda/hdac_i915.c |   12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> --- a/sound/hda/hdac_i915.c
> +++ b/sound/hda/hdac_i915.c
> @@ -143,10 +143,14 @@ int snd_hdac_i915_init(struct hdac_bus *
>   if (!acomp)
>   return -ENODEV;
>   if (!acomp->ops) {
> - request_module("i915");
> - /* 60s timeout */
> - wait_for_completion_timeout(&bind_complete,
> - msecs_to_jiffies(60 * 1000));
> +#ifdef CONFIG_MODULES
> + if (request_module("i915") == 0)
> +#endif

Better to use IS_ENABLED(), so that we can avoid ugly ifdef.

if (!IS_ENABLED(CONFIG_MODULES) ||
!request_module("i915")) {


thanks,

Takashi

Bug#663090: [alsa-devel] amixer: convert percentage into db wrongly

[Takashi Iwai]

At Fri, 9 Mar 2012 18:06:17 +0800,
Adam Lee wrote:
> 
> On Fri, Mar 09, 2012 at 10:30:27AM +0100, Takashi Iwai wrote:
> > At Fri, 9 Mar 2012 17:07:17 +0800,
> > Adam Lee wrote:
> > > 
> > > On Fri, Mar 09, 2012 at 07:40:27AM +0100, Takashi Iwai wrote:
> > > > At Fri, 9 Mar 2012 12:22:47 +0800,
> > > > Adam Lee wrote:
> > > > > 
> > > > > Add Vincent in cc, because conky read amixer's result.
> > > > > 
> > > > > On Thu, Mar 08, 2012 at 05:45:14PM +0100, Takashi Iwai wrote:
> > > > > > > * Adam Lee  [2012-03-08 20:36 +0800]:
> > > > > > > 
> > > > > > > Package: alsa-utils
> > > > > > > Version: 1.0.25-1
> > > > > > > Severity: important
> > > > > > > 
> > > > > > > 
> > > > > > > db is not linear, but amixer believe it is.
> > > > > > > 
> > > > > > > "amixer get Master" says "Limits: Playback 0 - 74", then 
> > > > > > > everytime I run
> > > > > > > "amixer -q sset Master 10%-", there is 8db dec.
> > > > > > > 
> > > > > > > For example, at first Master is 100% and 0db, both alsamixer and 
> > > > > > > amixer
> > > > > > > think it is, and after I run "amixer -q sset Master 10%-", both
> > > > > > > alsamixer and amixer says Master is -8.00db, but alsamixer says 
> > > > > > > it is
> > > > > > > 72%, amixer says it is 89%.
> > > > > > > 
> > > > > > > alsamixer is right, amixer calc and set wrongly.
> > > > > > 
> > > > > > No, both are correct.  You are dreaming too much on the world 
> > > > > > unified
> > > > > > percentage representation :)
> > > > > > 
> > > > > > The percentage in amixer has nothing to do with dB level.
> > > > > > It's just the percentage of the raw value range of that mixer
> > > > > > element.  Thus showing 89% is correct.  It's 10% down from 100%
> > > > > > (1% is because of the resolution of the raw values).
> > > > > > 
> > > > > > Now, alsamixer shows the percentage in a different way.  It's
> > > > > > explained well in the source code (alsamixer/volume_mapping.c), but
> > > > > > not mentioned in the man page, unfortunately.
> > > > > > 
> > > > > >  * The mapping is designed so that the position in the interval is 
> > > > > > proportional
> > > > > >  * to the volume as a human ear would perceive it (i.e., the 
> > > > > > position is the
> > > > > >  * cubic root of the linear sample multiplication factor).  For 
> > > > > > controls with
> > > > > >  * a small range (24 dB or less), the mapping is linear in the dB 
> > > > > > values so
> > > > > >  * that each step has the same size visually.  Only for controls 
> > > > > > without dB
> > > > > >  * information, a linear mapping of the hardware volume register 
> > > > > > values is used
> > > > > >  * (this is the same algorithm as used in the old alsamixer).
> > > > > > 
> > > > > > The percentage representation in alsamixer corresponds to this
> > > > > > mapping, thus it's neither dB nor linear percent.
> > > > > > 
> > > > > 
> > > > > Hi, Takashi
> > > > > 
> > > > > Thank you for replying. But I still insist this is a bug. Three
> > > > > questions:
> > > > > 
> > > > > 1, several months ago, it's OK, both amixer and alsamixer use the 
> > > > > human
> > > > > mapping(0-10% and 90%-100% are the same change by a human ear), why 
> > > > > not
> > > > > now?
> > > > 
> > > > amixer hasn't been changed until yet.  It handles either in raw values
> > > > or in dB.  No human-ear mapping at all.  It's never changed since
> > > > years, and won't be changed.  If the volume mapping would be
> > > > implemented to amixer in future, it must be only optional.
> > > > 
> > > > Only the rec

Bug#663090: [alsa-devel] amixer: convert percentage into db wrongly

[Takashi Iwai]

At Fri, 9 Mar 2012 17:07:17 +0800,
Adam Lee wrote:
> 
> On Fri, Mar 09, 2012 at 07:40:27AM +0100, Takashi Iwai wrote:
> > At Fri, 9 Mar 2012 12:22:47 +0800,
> > Adam Lee wrote:
> > > 
> > > Add Vincent in cc, because conky read amixer's result.
> > > 
> > > On Thu, Mar 08, 2012 at 05:45:14PM +0100, Takashi Iwai wrote:
> > > > > * Adam Lee  [2012-03-08 20:36 +0800]:
> > > > > 
> > > > > Package: alsa-utils
> > > > > Version: 1.0.25-1
> > > > > Severity: important
> > > > > 
> > > > > 
> > > > > db is not linear, but amixer believe it is.
> > > > > 
> > > > > "amixer get Master" says "Limits: Playback 0 - 74", then everytime I 
> > > > > run
> > > > > "amixer -q sset Master 10%-", there is 8db dec.
> > > > > 
> > > > > For example, at first Master is 100% and 0db, both alsamixer and 
> > > > > amixer
> > > > > think it is, and after I run "amixer -q sset Master 10%-", both
> > > > > alsamixer and amixer says Master is -8.00db, but alsamixer says it is
> > > > > 72%, amixer says it is 89%.
> > > > > 
> > > > > alsamixer is right, amixer calc and set wrongly.
> > > > 
> > > > No, both are correct.  You are dreaming too much on the world unified
> > > > percentage representation :)
> > > > 
> > > > The percentage in amixer has nothing to do with dB level.
> > > > It's just the percentage of the raw value range of that mixer
> > > > element.  Thus showing 89% is correct.  It's 10% down from 100%
> > > > (1% is because of the resolution of the raw values).
> > > > 
> > > > Now, alsamixer shows the percentage in a different way.  It's
> > > > explained well in the source code (alsamixer/volume_mapping.c), but
> > > > not mentioned in the man page, unfortunately.
> > > > 
> > > >  * The mapping is designed so that the position in the interval is 
> > > > proportional
> > > >  * to the volume as a human ear would perceive it (i.e., the position 
> > > > is the
> > > >  * cubic root of the linear sample multiplication factor).  For 
> > > > controls with
> > > >  * a small range (24 dB or less), the mapping is linear in the dB 
> > > > values so
> > > >  * that each step has the same size visually.  Only for controls 
> > > > without dB
> > > >  * information, a linear mapping of the hardware volume register values 
> > > > is used
> > > >  * (this is the same algorithm as used in the old alsamixer).
> > > > 
> > > > The percentage representation in alsamixer corresponds to this
> > > > mapping, thus it's neither dB nor linear percent.
> > > > 
> > > 
> > > Hi, Takashi
> > > 
> > > Thank you for replying. But I still insist this is a bug. Three
> > > questions:
> > > 
> > > 1, several months ago, it's OK, both amixer and alsamixer use the human
> > > mapping(0-10% and 90%-100% are the same change by a human ear), why not
> > > now?
> > 
> > amixer hasn't been changed until yet.  It handles either in raw values
> > or in dB.  No human-ear mapping at all.  It's never changed since
> > years, and won't be changed.  If the volume mapping would be
> > implemented to amixer in future, it must be only optional.
> > 
> > Only the recent alsamixer introduced the volume mapping to visualize
> > the volumes reasonably.
> > 
> 
> OK, thank you. Maybe an optional will make everyone happy.
> 
> > > 2, conky(Vincent, I mean ${mixer}), some other software, lot of user's
> > > scripts use amixer to set or get volume, expecting the human mapping,
> > > why change the behavior?
> > 
> > You must be smoking something bad.  The behavior of amixer hasn't been
> > changed.
> > 
> 
> I figured out a reason probably, when the limits range is wide, like
> 0-65536, amixer's mapping and alsamixer's human-ear mapping are close.
> 
> If I remember right, my hardware's limits was 0-65536, but it becomes
> 0-74 after I run "alsactl init", but unfortunately, I don't know how to
> modify it back.
> 
> > > 3, alsamixer and amixer use the same dB value, why there is difference
> > > in percentage

Bug#663090: [alsa-devel] amixer: convert percentage into db wrongly

[Takashi Iwai]

At Fri, 9 Mar 2012 12:22:47 +0800,
Adam Lee wrote:
> 
> Add Vincent in cc, because conky read amixer's result.
> 
> On Thu, Mar 08, 2012 at 05:45:14PM +0100, Takashi Iwai wrote:
> > > * Adam Lee  [2012-03-08 20:36 +0800]:
> > > 
> > > Package: alsa-utils
> > > Version: 1.0.25-1
> > > Severity: important
> > > 
> > > 
> > > db is not linear, but amixer believe it is.
> > > 
> > > "amixer get Master" says "Limits: Playback 0 - 74", then everytime I run
> > > "amixer -q sset Master 10%-", there is 8db dec.
> > > 
> > > For example, at first Master is 100% and 0db, both alsamixer and amixer
> > > think it is, and after I run "amixer -q sset Master 10%-", both
> > > alsamixer and amixer says Master is -8.00db, but alsamixer says it is
> > > 72%, amixer says it is 89%.
> > > 
> > > alsamixer is right, amixer calc and set wrongly.
> > 
> > No, both are correct.  You are dreaming too much on the world unified
> > percentage representation :)
> > 
> > The percentage in amixer has nothing to do with dB level.
> > It's just the percentage of the raw value range of that mixer
> > element.  Thus showing 89% is correct.  It's 10% down from 100%
> > (1% is because of the resolution of the raw values).
> > 
> > Now, alsamixer shows the percentage in a different way.  It's
> > explained well in the source code (alsamixer/volume_mapping.c), but
> > not mentioned in the man page, unfortunately.
> > 
> >  * The mapping is designed so that the position in the interval is 
> > proportional
> >  * to the volume as a human ear would perceive it (i.e., the position is the
> >  * cubic root of the linear sample multiplication factor).  For controls 
> > with
> >  * a small range (24 dB or less), the mapping is linear in the dB values so
> >  * that each step has the same size visually.  Only for controls without dB
> >  * information, a linear mapping of the hardware volume register values is 
> > used
> >  * (this is the same algorithm as used in the old alsamixer).
> > 
> > The percentage representation in alsamixer corresponds to this
> > mapping, thus it's neither dB nor linear percent.
> > 
> 
> Hi, Takashi
> 
> Thank you for replying. But I still insist this is a bug. Three
> questions:
> 
> 1, several months ago, it's OK, both amixer and alsamixer use the human
> mapping(0-10% and 90%-100% are the same change by a human ear), why not
> now?

amixer hasn't been changed until yet.  It handles either in raw values
or in dB.  No human-ear mapping at all.  It's never changed since
years, and won't be changed.  If the volume mapping would be
implemented to amixer in future, it must be only optional.

Only the recent alsamixer introduced the volume mapping to visualize
the volumes reasonably.

> 2, conky(Vincent, I mean ${mixer}), some other software, lot of user's
> scripts use amixer to set or get volume, expecting the human mapping,
> why change the behavior?

You must be smoking something bad.  The behavior of amixer hasn't been
changed.

> 3, alsamixer and amixer use the same dB value, why there is difference
> in percentage? If alsa-utils developer think the human mapping sucks,
> why you guys still use it in alsamixer? There is no "both correct", the
> difference confuses user...

That's true.  alsamixer should have stopped showing the stupid
percentage.

The biggest understand is that people (including you) think there is
an absolutely perfect percentage definition for the sound level.  It's
an illusion.

> IMO: Any, any human says 10% plus, she or he definitely wants the human
> mapping. Maybe you developing guys think there is nothing wrong now, but
> how about think it from the perspective of user?
> 
> Please consider about fixing it, at least discuss it in alsa-utils mail
> list, thank you.

There is no such ML...


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#663090: [alsa-devel] amixer: convert percentage into db wrongly

[Takashi Iwai]

At Thu, 8 Mar 2012 17:30:02 +0100,
Elimar Riesebieter wrote:
> 
> severity 663090 normal
> forwarded 663090 alsa-de...@alsa-project.org
> thanks
> 
> 
> * Adam Lee  [2012-03-08 20:36 +0800]:
> 
> > Package: alsa-utils
> > Version: 1.0.25-1
> > Severity: important
> > 
> > 
> > db is not linear, but amixer believe it is.
> > 
> > "amixer get Master" says "Limits: Playback 0 - 74", then everytime I run
> > "amixer -q sset Master 10%-", there is 8db dec.
> > 
> > For example, at first Master is 100% and 0db, both alsamixer and amixer
> > think it is, and after I run "amixer -q sset Master 10%-", both
> > alsamixer and amixer says Master is -8.00db, but alsamixer says it is
> > 72%, amixer says it is 89%.
> > 
> > alsamixer is right, amixer calc and set wrongly.

No, both are correct.  You are dreaming too much on the world unified
percentage representation :)

The percentage in amixer has nothing to do with dB level.
It's just the percentage of the raw value range of that mixer
element.  Thus showing 89% is correct.  It's 10% down from 100%
(1% is because of the resolution of the raw values).

Now, alsamixer shows the percentage in a different way.  It's
explained well in the source code (alsamixer/volume_mapping.c), but
not mentioned in the man page, unfortunately.

 * The mapping is designed so that the position in the interval is proportional
 * to the volume as a human ear would perceive it (i.e., the position is the
 * cubic root of the linear sample multiplication factor).  For controls with
 * a small range (24 dB or less), the mapping is linear in the dB values so
 * that each step has the same size visually.  Only for controls without dB
 * information, a linear mapping of the hardware volume register values is used
 * (this is the same algorithm as used in the old alsamixer).

The percentage representation in alsamixer corresponds to this
mapping, thus it's neither dB nor linear percent.


Takashi

> > Several months ago, they both right, and I upgraded, and amixer messed
> > up. Please fix it. Thank you.
> > 
> > FYI, my hardware is:
> > "HDA-Intel" "Conexant CX20585" "HDA:14f15069,17aa214c,00100302 
> > HDA:14f12c06,17aa2122,0010" "0x17aa" "0x215e"
> > 
> > 
> > -- System Information:
> > Debian Release: wheezy/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > 
> > Versions of packages alsa-utils depends on:
> > ii  dialog 1.1-20120215-1
> > ii  libasound2 1.0.25-2
> > ii  libc6  2.13-27
> > ii  libncursesw5   5.9-4
> > ii  libsamplerate0 0.1.8-3
> > ii  libtinfo5  5.9-4
> > ii  linux-sound-base   1.0.23+dfsg-4
> > ii  lsb-base   3.2+Debian29
> > ii  module-init-tools  6-1
> > ii  whiptail   0.52.14-8
> > 
> > Versions of packages alsa-utils recommends:
> > ii  alsa-base  1.0.23+dfsg-4
> > ii  pciutils   1:3.1.8-2
> > 
> > alsa-utils suggests no packages.
> > 
> > -- no debconf information
> > 
> > 
> > 
> > ___
> > Pkg-alsa-devel mailing list
> > pkg-alsa-de...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
> > 
> 
> -- 
>   The path to source is always uphill!
> -unknown-
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#660111: [alsa-devel] multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

[Takashi Iwai]

At Sun, 04 Mar 2012 03:43:20 +0100,
David Henningsson wrote:
> 
> >> Let me also push for the hda-jack-retask [2] application, which is an
> >> easy-to-use GUI for creating these types of firmware files. I advertised it
> >> here a while ago [3] but it seems to have gone unnoticed.
> >
> > This sounds like a good tool for making this happen. I will submit a
> > Request For Package in Debian... but this can take time. Would you
> > consider packaging it there? then it would easily flow into Ubuntu.
> 
> Certainly, if there is interest from the Debian side to have it.
> 
> I would also not mind if it became a part of upstream ALSA, I think it 
> would make a nice addition to the hda-analyzer, hda-verb etc tool set.

It could be indeed helpful to merge it to alsa-tools package.  Feel
free to submit the patches or a git pull request.

hda-analyzer is currently in alsa.git, not in alsa-tools.git, by some
reason.  I guess it'd be no big problem to move it to alsa-tools if
Jaroslav doesn't mind.

hda-verb can be certainly to be merged to alsa-tools.  I'll add it
later.

OTOH, hda-emu doesn't fit to alsa-tools.  It's a no program to be
provided in a pre-compiled form such as a distro package.


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#654799: Cranking sound coming out of speakers with the new 3.1 kernel

[Takashi Iwai]

At Thu, 1 Mar 2012 08:44:33 +0100,
Jan Prunk wrote:
> 
> Hello !
> 
> The sound has been stable for the last days without noises,
> after applying % amixer -c0 set "Auto-Mute Mode" "Disabled"

OK, another question is whether the auto-mute feature works in hardware,
i.e. even when this mixer is set off, the hardware switches the
speaker upon plugging the headphone?  If yes, we can simply remove
this switch and software feature from the driver.


thanks,

Takashi

> 
> It seems this has solved it, until further notice.
> You might want to keep the bug open for a while,
> so I can check with all the kernels (it works with latest).
> 
> Kind regards,
> Jan
> 
> On Tue, Feb 28, 2012 at 4:38 PM, Takashi Iwai  wrote:
> > At Tue, 28 Feb 2012 16:16:48 +0100,
> > Jan Prunk wrote:
> >>
> >> Hello !
> >>
> >> On Sat, Jan 14, 2012 at 12:04 AM, Jonathan Nieder  
> >> wrote:
> >> > Hi again,
> >> >
> >> > Jan Prunk wrote:
> >> >
> >> >> I tried booting into 3.2.0-rc7-686-pae, but the crunching sound
> >> >> is still present, I am able to play music file properly, and
> >> >> crunching is in the background, and also while not processing
> >> >> any sounds, the crunching appears out of the speakers.
> >> >
> >> > Ok, thanks for testing.  Please send a summary of this regression to
> >> > alsa-de...@alsa-project.org, cc-ing Takashi Iwai  and
> >> > either me or this bug log so we can track it.
> >> >
> >> > Be sure to mention:
> >> >
> >> >  - steps to reproduce, what you expect versus what actually happens,
> >> >   and how that indicates a bug
> >>
> >> The sound is ok in kernel version "3.0.0-1-686-pae" but on all newer
> >> versions there are sparkling/farting noises coming out of the speaker.
> >> The noise is not very loud, its barely noticeable, but its repetative
> >> and doesn't go away. And I think it happens while typing on the
> >> keyboard and a bit later, then it dissapears for a few seconds,
> >> or by the time that I type again.
> >>
> >> >  - which kernel versions you tried, and what happens with each
> >> I tried running alsa-info.sh as a "user".
> >>
> >> I tried 3.0.0-1-686-pae here is the debug:
> >> http://www.alsa-project.org/db/?f=c1149b6466b2068d79c7517a8b0808d8b5c26e6b
> >> ---
> >> Linux vaio 3.2.0-1-686-pae #1 SMP Fri Feb 17 06:27:21 UTC 2012 i686 
> >> GNU/Linux
> >> ii  linux-image-3.2.0-1-686-pae          3.2.6-1
> >> http://www.alsa-project.org/db/?f=fddbfbdc4fc44555a6dc851ecdc70760da6dd840
> >> ---
> >> Linux vaio 3.2.0-rc7-686-pae #1 SMP Wed Dec 28 21:26:25 UTC 2011 i686 
> >> GNU/Linux
> >> ii  linux-image-3.2.0-rc7-686-pae        3.2~rc7-1~experimental.1
> >> http://www.alsa-project.org/db/?f=78c8919e87dd03294484f83b5f7ae44331b5edfe
> >> Being booted into this version for 15 minutes, it seems to not make any 
> >> noises,
> >> but I will resubmit the info later if the noises will start to appear.
> >
> > 3.2.0-rc7 alsa-info shows that the headphone jack is plugged, thus the
> > speaker is muted.  It's natural that the noise goes away in this
> > state.
> >
> > Apart from that, I see no obvious problem in 3.2.0 output.
> >
> > Does the problem still happen when you disable "Auto-Mute Mode" mixer
> > enum?
> >        % amixer -c0 set "Auto-Mute Mode" "Disabled"
> >
> > Also, try to pass algin_buffer_size=0 option to snd-hda-intel.
> > I don't expect much that this will influence, but at least, it's a
> > difference between 3.0 and 3.2.
> >
> >
> > Takashi
> >
> >
> >> >  - alsa-info.sh output, as an attachment
> >> >
> >> >  - if you can make a recording of the strange sound available
> >> >   somewhere online, that would be ideal
> >>
> >> Because the noise is barely heard, I would need to find a good mic.
> >> to be able to record it, but I could do that in the next bug submission.
> >>
> >> >  - whether you are able to bisect or test patches if needed
> >>
> >> I might try that, if there are any manuals around how to do it,
> >> but my response might take some time.
> >>
> >> > [1] may have more hints.
> >> >
> >> > Thanks and good luck,
> >> > Jonathan
> >> >
> >> > [1] http://alsa-project.org/main/index.php/Help_To_Debug_Intel_HDA
> >>
> >> Kind regards,
> >> Jan Prunk
> >> --
> >> Jan Prunk   http://www.prunk.si
> >> 0x00E80E86  http://pgp.prunk.si
> >> http://AS50763.peeringdb.com
> >>
> 
> 
> 
> -- 
> Jan Prunk   http://www.prunk.si
> 0x00E80E86  http://pgp.prunk.si
> http://AS50763.peeringdb.com
> 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#654799: Cranking sound coming out of speakers with the new 3.1 kernel

[Takashi Iwai]

At Tue, 28 Feb 2012 16:16:48 +0100,
Jan Prunk wrote:
> 
> Hello !
> 
> On Sat, Jan 14, 2012 at 12:04 AM, Jonathan Nieder  wrote:
> > Hi again,
> >
> > Jan Prunk wrote:
> >
> >> I tried booting into 3.2.0-rc7-686-pae, but the crunching sound
> >> is still present, I am able to play music file properly, and
> >> crunching is in the background, and also while not processing
> >> any sounds, the crunching appears out of the speakers.
> >
> > Ok, thanks for testing.  Please send a summary of this regression to
> > alsa-de...@alsa-project.org, cc-ing Takashi Iwai  and
> > either me or this bug log so we can track it.
> >
> > Be sure to mention:
> >
> >  - steps to reproduce, what you expect versus what actually happens,
> >   and how that indicates a bug
> 
> The sound is ok in kernel version "3.0.0-1-686-pae" but on all newer
> versions there are sparkling/farting noises coming out of the speaker.
> The noise is not very loud, its barely noticeable, but its repetative
> and doesn't go away. And I think it happens while typing on the
> keyboard and a bit later, then it dissapears for a few seconds,
> or by the time that I type again.
> 
> >  - which kernel versions you tried, and what happens with each
> I tried running alsa-info.sh as a "user".
> 
> I tried 3.0.0-1-686-pae here is the debug:
> http://www.alsa-project.org/db/?f=c1149b6466b2068d79c7517a8b0808d8b5c26e6b
> ---
> Linux vaio 3.2.0-1-686-pae #1 SMP Fri Feb 17 06:27:21 UTC 2012 i686 GNU/Linux
> ii  linux-image-3.2.0-1-686-pae  3.2.6-1
> http://www.alsa-project.org/db/?f=fddbfbdc4fc44555a6dc851ecdc70760da6dd840
> ---
> Linux vaio 3.2.0-rc7-686-pae #1 SMP Wed Dec 28 21:26:25 UTC 2011 i686 
> GNU/Linux
> ii  linux-image-3.2.0-rc7-686-pae3.2~rc7-1~experimental.1
> http://www.alsa-project.org/db/?f=78c8919e87dd03294484f83b5f7ae44331b5edfe
> Being booted into this version for 15 minutes, it seems to not make any 
> noises,
> but I will resubmit the info later if the noises will start to appear.

3.2.0-rc7 alsa-info shows that the headphone jack is plugged, thus the
speaker is muted.  It's natural that the noise goes away in this
state.

Apart from that, I see no obvious problem in 3.2.0 output.

Does the problem still happen when you disable "Auto-Mute Mode" mixer
enum?
% amixer -c0 set "Auto-Mute Mode" "Disabled"

Also, try to pass algin_buffer_size=0 option to snd-hda-intel.
I don't expect much that this will influence, but at least, it's a
difference between 3.0 and 3.2.


Takashi


> >  - alsa-info.sh output, as an attachment
> >
> >  - if you can make a recording of the strange sound available
> >   somewhere online, that would be ideal
> 
> Because the noise is barely heard, I would need to find a good mic.
> to be able to record it, but I could do that in the next bug submission.
> 
> >  - whether you are able to bisect or test patches if needed
> 
> I might try that, if there are any manuals around how to do it,
> but my response might take some time.
> 
> > [1] may have more hints.
> >
> > Thanks and good luck,
> > Jonathan
> >
> > [1] http://alsa-project.org/main/index.php/Help_To_Debug_Intel_HDA
> 
> Kind regards,
> Jan Prunk
> -- 
> Jan Prunk   http://www.prunk.si
> 0x00E80E86  http://pgp.prunk.si
> http://AS50763.peeringdb.com
> 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB

[Takashi Iwai]

n a stream's open and cleanup calls. The dynamic
> de-assignment of converters to PCMs occurs within cleanup, not close,
> in order for it to co-incide with when controller stream IDs are
> cleaned up from converters.
> 
> While the PCM for a pin is not open, the pin is disabled (its widget
> control's PIN_OUT bit is cleared) so that if the currently routed
> converter is used to drive a different PCM/pin, that audio does not
> leak out over a disabled pin.
> 
> We use the recently added SPDIF virtualization feature in order to
> create SPDIF controls for each pin widget instead of each converter
> widget, so that state is specific to a PCM.
> 
> In order to support this, a number of more mechanical changes are made:
> 
> * s/nid/pin_nid/ or s/nid/cvt_nid/ in many places in order to make it
>   clear exactly what the code is dealing with.
> 
> * We now have per_pin and per_cvt arrays in hdmi_spec to store relevant
>   data. In particular, we store a converter's capabilities in the per_cvt
>   entry, rather than relying on a combination of codec_pcm_pars and
>   the struct hda_pcm_stream.
> 
> * ELD-related workarounds were removed from hdmi_channel_allocation
>   into hdmi_instrinsic in order to simplifiy infoframe calculations and
>   remove HW dependencies.
> 
> * Various functions only apply to a single pin, since there is now
>   only 1 pin per PCM. For example, hdmi_setup_infoframe,
>   hdmi_setup_stream.
> 
> * hdmi_add_pin and hdmi_add_cvt are more oriented at pure codec parsing
>   and data retrieval, rather than determining which pins/converters
>   are to be used for creating PCMs.
> 
> This is quite a large change; it may be appropriate to simply read the
> result of the patch rather than the diffs. Some small parts of the change
> might be separable into different patches, but I think the bulk of the
> change will probably always be one large patch. Hopefully the change
> isn't too opaque!
> 
> This has been tested on:
> 
> * NVIDIA GeForce 400 series discrete graphics card. This model has the
>   classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM
>   audio to a PC monitor that supports audio.
> 
> * NVIDIA GeForce 520 discrete graphics card. This model is the new
>   1 codec n converters m pins m>n model. Tested stereo PCM audio to a
>   PC monitor that supports audio.
> 
> * NVIDIA GeForce 400 series laptop graphics chip. This model has the
>   classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM,
>   multi-channel PCM, and AC3 pass-through to an AV receiver.
> 
> * Intel Ibex Peak laptop. This model is the new 1 codec n converters m
>   pins m>n model. Tested stereo PCM, multi-channel PCM, and AC3 pass-
>   through to an AV receiver.
> 
> Note that I'm not familiar at all with AC3 pass-through. Hence, I may
> not have covered all possible mechanisms that are applicable here. I do
> know that my receiver definitely received AC3, not decoded PCM. I tested
> with mplayer's "-afm hwac3" and/or "-af lavcac3enc" options, and alsa a
> WAV file that I believe has AC3 content rather than PCM.
> 
> I also tested:
> * Play a stream
> * Mute while playing
> * Stop stream
> * Play some other streams to re-assign the converter to a different
>   pin, PCM, set of SPDIF controls, ... hence hopefully triggering
>   cleanup for the original PCM.
> * Unmute original stream while not playing
> * Play a stream on the original pin/PCM.
> 
> This was to test SPDIF control virtualization.
> 
> Signed-off-by: Stephen Warren 
> Signed-off-by: Takashi Iwai 
> 
> :04 04 894370c6534b1bf03df9a8a8c7d85c2eeffc7555 
> 98cb8a73a0ed46f034e25bd35002930bc22376ef Msound
> [3 git_bisect_log.txt ]
> git bisect log
> git bisect start
> # bad: [76531d4166fb620375ff3c1ac24753265216d579] Merge branch 'topic/hda' 
> into for-linus
> git bisect bad 76531d4166fb620375ff3c1ac24753265216d579
> # good: [7d339ae99758bc21033d4a19bcd4f7b55f96e24e] Merge branch 'topic/misc' 
> into for-linus
> git bisect good 7d339ae99758bc21033d4a19bcd4f7b55f96e24e
> # bad: [39fa84e94a7df64a6ba27669ef98b51994fb6894] ALSA: hda - Simplify EAPD 
> control in patch_realtek.c
> git bisect bad 39fa84e94a7df64a6ba27669ef98b51994fb6894
> # bad: [096a885494f6b89a9962c6faf18e1c6092e7919c] ALSA: hda - Initialize 
> input-path dynamically in patch_via.c
> git

Bug#658728: linux-image-3.2.0-1-amd64: No more sound

[Takashi Iwai]

At Fri, 10 Feb 2012 18:57:34 -0500,
A. Costa wrote:
> 
> On Fri, 10 Feb 2012 11:58:46 +0100
> Takashi Iwai  wrote:
> 
> > > Sound silently playing in the background (via 'audacious' and
> > > 'pulseaudio') suddenly went on.  The headphones when plugged in also
> > > worked correctly.
> > 
> > Do you mean that the speaker is still muted automatically with the
> > headphone plugging, even though "Auto-Mute Mode" mixer element is
> > disabled?  Or the speaker keeps playing?
> 
> When plugged in, the headphones played and the speaker muted.
> Unplugging the phones, the speakers play.
> 
> At the risk of being redundant, here's what I have so far:
> 
> First off, with plain kernel v3.2.0-1-686-pae, I run 'audacious' with a
> playlist.  'pavucontrol' shows movement.  The speakers are mute.
> Plugged in, the headphone are also mute.
> 
> Then I ran 'amixer -c0 set "Auto-Mute Mode" Disabled'.
> The speakers (line out) play.  Plug in the headphones, the speaker
> mutes, the headphones play.  Unplug the phones, the speakers play.

Thanks for confirmation.

I fixed the upstream code no to create the superfluous Auto-Mute
control.  But the change is a bit intrusive so it's targeted only for
3.4 kernel, as you can work around it easily by turning off Auto-Mute
even in the current tree.


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658728: linux-image-3.2.0-1-amd64: No more sound

[Takashi Iwai]

At Tue, 7 Feb 2012 21:16:57 -0500,
A. Costa wrote:
> 
> On Tue, 07 Feb 2012 10:17:37 +0100
> Takashi Iwai  wrote:
> 
> > > On the good kernel (3.1.0-1), this happens:
> > > 
> > >   % amixer -c0 set "Auto-Mute Mode" Disabled ; echo $?
> > >   amixer: Unable to find simple control 'Auto-Mute Mode',0
> > > 
> > >   1
> > > 
> > > Haven't tried that 'amixer' command on the silent kernel (3.2.0-1).
> > 
> > The question above was only for 3.2 kernel.  It wasn't enabled for 3.1
> > kernel for your device unless you passed model=auto explicitly.
> 
> Success:
> 
>   % cat /proc/version 
>   Linux version 3.2.0-1-686-pae (Debian 3.2.4-1) (wa...@debian.org) (gcc 
> version 4.6.2 (Debian 4.6.2-12) ) #1 SMP Sun Feb 5 23:52:49 UTC 2012
> 
>   % amixer -c0 set "Auto-Mute Mode" Disabled ; echo $?
>   Simple mixer control 'Auto-Mute Mode',0
> Capabilities: enum
> Items: 'Disabled' 'Enabled'
> Item0: 'Disabled'
>   0
> 
> Sound silently playing in the background (via 'audacious' and
> 'pulseaudio') suddenly went on.  The headphones when plugged in also
> worked correctly.

Do you mean that the speaker is still muted automatically with the
headphone plugging, even though "Auto-Mute Mode" mixer element is
disabled?  Or the speaker keeps playing?

> Exactly which jacks were tested before: the line out (the main stereo
> only), and the headphone jack.  Did not test surround, line in, or the
> mic.  (I don't ordinarily use those jacks.)
> 
> At present the additional tests you suggested, ('hda-verb', 'aplay', and
> 'pasuspender'), might not be necessary.  If those would still be useful,
> please say so.

If disabling auto-mute mode fixes the thing, I'll create a blacklist
and add this device to it so that this control won't be created in
future.


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658728: linux-image-3.2.0-1-amd64: No more sound

[Takashi Iwai]

At Mon, 6 Feb 2012 22:53:59 -0500,
A. Costa wrote:
> 
> On Mon, 06 Feb 2012 10:21:40 +0100
> Takashi Iwai  wrote:
> 
> > No sound from which output exactly?
> 
> Which?  None.

"None" means almost nothing :)  Tell which outputs you have tried.
I don't know exactly whether you checked only the speaker, or only the
headphone, or any jacks what ever.  (Judging from the text, I can
guess you tested the headphone jack and the line-out jack.  But you
didn't test the surround/CLFE outputs from line-in/mic-in jacks, no?)

>  No outputs are audible, so far as I can tell.  The
> 'pavucontrol' streams still work, the meter goes up and down to the
> silent music.
> 
> On the good kernel (3.1.0-1) sound plays through the (separately
> powered) speakers plugged into the back of the PC case; when I plug the
> headphones in a different jack on the front of the case, the speakers
> turn off, and the headphone sound goes on.

Hm, so maybe the auto-mute feature is implemented in the hardware
itself?  Interesting.  The 3.1 driver doesn't provide the auto-mute in
software for your device.

> On the silent kernel (3.2.0-1), there's no sound from headphones or
> speaker, and the headphones being plugged and unplugged has no audible
> effect on either speakers or headphones.
> 
> > What happens if you turn off "Auto-Mute Mode" mixer enum?
> > % amixer -c0 set "Auto-Mute Mode" Disabled
> 
> On the good kernel (3.1.0-1), this happens:
> 
>   % amixer -c0 set "Auto-Mute Mode" Disabled ; echo $?
>   amixer: Unable to find simple control 'Auto-Mute Mode',0
> 
>   1
> 
> Haven't tried that 'amixer' command on the silent kernel (3.2.0-1).

The question above was only for 3.2 kernel.  It wasn't enabled for 3.1
kernel for your device unless you passed model=auto explicitly.

If the above doesn't change anything, try to set the pin-control of
each pin as same as 3.1 kernel:

hda-verb /dev/snd/hwC0D0 0x0e SET_PIN_WID 0x00
hda-verb /dev/snd/hwC0D0 0x0d SET_PIN_WID 0x24
hda-verb /dev/snd/hwC0D0 0x0c SET_PIN_WID 0x20
hda-verb /dev/snd/hwC0D0 0x0b SET_PIN_WID 0x40
hda-verb /dev/snd/hwC0D0 0x0f SET_PIN_WID 0xc0
hda-verb /dev/snd/hwC0D0 0x10 SET_PIN_WID 0x24
hda-verb /dev/snd/hwC0D0 0x1f SET_PIN_WID 0x00
hda-verb /dev/snd/hwC0D0 0x20 SET_PIN_WID 0x00
hda-verb /dev/snd/hwC0D0 0x11 SET_PIN_WID 0x20

One of the command may trigger something.  Don't change the plug while
you test this.  Also, keep "Auto-Mute" mode turned off.  Otherwise the
driver might reset the pin-control values again.

Last but not least, for testing the output, don't use PulseAudio but
use aplay or speaker-test with the raw ALSA access.
Run like
% aplay -Dplughw -vv somefile.wav

If PA complains, use pasuspender
% pasuspender -- aplay -Dplughw -vv somefile.wav


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658728: linux-image-3.2.0-1-amd64: No more sound

[Takashi Iwai]

At Sun, 5 Feb 2012 21:42:28 -0500,
A. Costa wrote:
> 
> On Sun, 5 Feb 2012 09:21:56 -0600
> Jonathan Nieder  wrote:
> 
> > Sorry for the lack of clarity.  These symptoms are indeed expected to
> > affect many laptops with an ALC861 codec, not just Asus laptops.  The
> > problem is that different machines use a different mechanism to turn
> > on or off sound completely.  The driver has a table that documents
> > this sort of thing for (1) all ASUS laptops (after the fix to
> > bug#657302), (2) Haier W18, (3) FSC Amilo Pi1505.
> > 
> > So, the next step is to work with upstream to get the pin routing
> > information for your laptop.  I'll send some hints on this in a
> > separate message.
> 
> It might not matter, but my current system, correctly identified by
> 'alsa-info.sh' as an "HP Compaq dx2200 MT", is a Desktop box, not a
> laptop.  The sound card is part of the mobo, however, which is somewhat
> laptop-like.  More here:
> 
>   Manuals (guides, supplements, addendums, etc)
>   HP Compaq dx2200 Microtower PC
>   
> http://h2.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?contentType=SupportManual&lang=en&cc=us&prodSeriesId=1844701&prodTypeId=12454
> 
> To fetch pin routing data via 'hda-verb' requires recompiling the
> kernel.  This week I haven't enough time to build a kernel.
> (Bandwidth=dialup.)  Pity there isn't a simpler method; even using a
> multitester on the mobo would be less hassle than rebuilding the kernel.
> 
> Searching the web for 'HP Compaq dx2200 MT "hda-verb"' finds some kernel 
> module patch notes from 2007:
> 
>   [ALSA] hda-codec - Add quirks for HP dx2200/dx2250
>   
>   HP dx2200 and dx2250 use Micro-Star International (MSI) motherboards
>   (models MS-7254 and MS-7297 respectively) with an ALC862 codec in
>   threestack configuration. Adding this quirk allows correct 5.1 sound
>   output in these systems.
>   
>   Signed-off-by: Claudio Matsuoka 
>   Signed-off-by: Takashi Iwai 
>   Signed-off-by: Jaroslav Kysela  
>   
> http://www.codebrowse.net/history/linux-3.0/sound/pci/hda/patch_realtek.c
> 
> Sound on this box with my previous stock Debian kernels worked.  Today
> I reverted to 'linux-image-3.1.0-1-686-pae', under which the
> sound still works fine.  Attached are the outputs of 'alsa-info.sh' for
> the the downgraded (good sound 3.1.0-1) kernel, and the newer (no sound
> working 3.2.0-1) kernel.
> 
> As advised I've CC:'d this email upstream, for whom the relevant Debian
> bug reports can be found here:
> 
>   
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657302&archived=False&mbox=no
>   
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658728&archived=False&mbox=no

No sound from which output exactly?
What happens if you turn off "Auto-Mute Mode" mixer enum?
% amixer -c0 set "Auto-Mute Mode" Disabled

This is the control to turn on/off the automatic mute of the speakers
via line-out or headphone jack plugs.  It's possible that this doesn't
work expectedly when the hardware implementation doesn't follow the
standard.

Looking through both alsa-info.sh outputs, your case doesn't seem like
a NID-0x0f VREF issue like ASUS laptops.  Even 3.1.x kernel shows 0xc0
(i.e. without VREF) for the pin-control of NID 0x0f.  The problem is
likely different.



thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#641946: [PATCH 1/2] fm801: Fix double free in case of error in tuner detection

[Takashi Iwai]

At Thu, 22 Sep 2011 14:38:58 +0100,
Ben Hutchings wrote:
> 
> Commit 9676001559fce06e37c7dc230ab275f605556176
> ("ALSA: fm801: add error handling if auto-detect fails") added
> incorrect error handling.
> 
> Once we have successfully called snd_device_new(), the cleanup
> function fm801_free() will automatically be called by snd_card_free()
> and we must *not* also call fm801_free() directly.
> 
> Reported-by: Hor Jiun Shyong 
> References: http://bugs.debian.org/641946
> Signed-off-by: Ben Hutchings 
> Cc: sta...@kernel.org [v3.0+]

Thanks, applied both patches now.


Takashi

> ---
>  sound/pci/fm801.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/pci/fm801.c b/sound/pci/fm801.c
> index a7ec703..0dd8963 100644
> --- a/sound/pci/fm801.c
> +++ b/sound/pci/fm801.c
> @@ -1236,7 +1236,6 @@ static int __devinit snd_fm801_create(struct snd_card 
> *card,
>   (tea575x_tuner & TUNER_TYPE_MASK) < 4) {
>   if (snd_tea575x_init(&chip->tea)) {
>   snd_printk(KERN_ERR "TEA575x radio not found\n");
> - snd_fm801_free(chip);
>   return -ENODEV;
>   }
>   } else if ((tea575x_tuner & TUNER_TYPE_MASK) == 0) {
> @@ -1251,7 +1250,6 @@ static int __devinit snd_fm801_create(struct snd_card 
> *card,
>   }
>   if (tea575x_tuner == 4) {
>   snd_printk(KERN_ERR "TEA575x radio not found\n");
> - snd_fm801_free(chip);
>   return -ENODEV;
>   }
>   }
> -- 
> 1.7.5.4
> 
> 
> 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635362: Realtek ALC889: HDA Intel and kernel 3.0 gives choppy sound

[Takashi Iwai]

At Thu, 28 Jul 2011 15:03:43 +0200,
Colomban Wendling wrote:
> 
> Le 27/07/2011 16:50, Takashi Iwai a écrit :
> > [...]
> > 
> > Thanks.  Could you try the patch below against 3.0 tree?
> > 
> > [...]
> 
> It works just fine, now waiting forward Debian to patch their tree :)
> Thanks a lot for all the good work!

Good to hear.  The patch was tagged to stable-kernel, so it'll be
likely included in 3.0.1 kernel.


thanks,

Takashi



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635362: Realtek ALC889: HDA Intel and kernel 3.0 gives choppy sound

[Takashi Iwai]

At Wed, 27 Jul 2011 16:09:50 +0200,
Colomban Wendling wrote:
> 
> Le 27/07/2011 15:07, Takashi Iwai a écrit :
> > At Wed, 27 Jul 2011 14:53:55 +0200,
> > Colomban Wendling wrote:
> >>
> >> Le 27/07/2011 13:20, Takashi Iwai a écrit :
> >>> At Wed, 27 Jul 2011 13:14:41 +0200,
> >>> Colomban Wendling wrote:
> >>>>
> >>>>> Also, you can replace the files in sound/pci/hda/* from 2.6.39 kernel
> >>>>> tree.  If this fixes the problem, it's a sound driver bug.  If not,
> >>>>> it's anything else, e.g. the problem in more core side, e.g. IOMMU
> >>>>> like above or the timer change, etc.
> >>>>
> >>>> Hey, that was a great idea! I reverse-patched sound/pci/hda of 3.0 with
> >>>> 2.6.39.3, and it fixes the problem! :)
> >>>
> >>> OK, then try to replace only sound/pci/hda/hda_intel.c and keep the
> >>> rest.  What happens?
> >>
> >> Doesn't work, that sound is choppy again.
> > 
> > OK, then keep hda_intel.c as 3.0 and replace the rest.
> > If this works, please give alsa-info.sh output (run with --no-upload
> > option).
> 
> It works! Attached is the alsa-info.sh output on this working version:
> 3.0 with 2.6.39.3 sound/pci/hda, but with 3.0's sound/pci/hda/hda_intel.c

Thanks.  Could you try the patch below against 3.0 tree?


Takashi

---
From: Takashi Iwai 
Subject: [PATCH] ALSA: hda - Fix duplicated DAC assignments for Realtek

Copying hp_pins and speaker_pins from line_out_pins may confuse the
parser, and it can lead to duplicated initializations for the same pin
with a wrong DAC assignment.  The problem appears in 3.0 kernel code.

Signed-off-by: Takashi Iwai 
---
 sound/pci/hda/patch_realtek.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 0383dd8..e125c60 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -895,13 +895,15 @@ static void alc_init_auto_hp(struct hda_codec *codec)
if (present == 3)
spec->automute_hp_lo = 1; /* both HP and LO automute */
 
-   if (!cfg->speaker_pins[0]) {
+   if (!cfg->speaker_pins[0] &&
+   cfg->line_out_type == AUTO_PIN_SPEAKER_OUT) {
memcpy(cfg->speaker_pins, cfg->line_out_pins,
   sizeof(cfg->speaker_pins));
cfg->speaker_outs = cfg->line_outs;
}
 
-   if (!cfg->hp_pins[0]) {
+   if (!cfg->hp_pins[0] &&
+   cfg->line_out_type == AUTO_PIN_HP_OUT) {
memcpy(cfg->hp_pins, cfg->line_out_pins,
   sizeof(cfg->hp_pins));
cfg->hp_outs = cfg->line_outs;
@@ -920,6 +922,7 @@ static void alc_init_auto_hp(struct hda_codec *codec)
spec->automute_mode = ALC_AUTOMUTE_PIN;
}
if (spec->automute && cfg->line_out_pins[0] &&
+   cfg->speaker_pins[0] &&
cfg->line_out_pins[0] != cfg->hp_pins[0] &&
cfg->line_out_pins[0] != cfg->speaker_pins[0]) {
for (i = 0; i < cfg->line_outs; i++) {
-- 
1.7.6




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635362: Realtek ALC889: HDA Intel and kernel 3.0 gives choppy sound

[Takashi Iwai]

At Wed, 27 Jul 2011 14:53:55 +0200,
Colomban Wendling wrote:
> 
> Le 27/07/2011 13:20, Takashi Iwai a écrit :
> > At Wed, 27 Jul 2011 13:14:41 +0200,
> > Colomban Wendling wrote:
> >>
> >>> Also, you can replace the files in sound/pci/hda/* from 2.6.39 kernel
> >>> tree.  If this fixes the problem, it's a sound driver bug.  If not,
> >>> it's anything else, e.g. the problem in more core side, e.g. IOMMU
> >>> like above or the timer change, etc.
> >>
> >> Hey, that was a great idea! I reverse-patched sound/pci/hda of 3.0 with
> >> 2.6.39.3, and it fixes the problem! :)
> > 
> > OK, then try to replace only sound/pci/hda/hda_intel.c and keep the
> > rest.  What happens?
> 
> Doesn't work, that sound is choppy again.

OK, then keep hda_intel.c as 3.0 and replace the rest.
If this works, please give alsa-info.sh output (run with --no-upload
option).


thanks,

Takashi



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635362: Realtek ALC889: HDA Intel and kernel 3.0 gives choppy sound

[Takashi Iwai]

At Wed, 27 Jul 2011 13:14:41 +0200,
Colomban Wendling wrote:
> 
> > Also, you can replace the files in sound/pci/hda/* from 2.6.39 kernel
> > tree.  If this fixes the problem, it's a sound driver bug.  If not,
> > it's anything else, e.g. the problem in more core side, e.g. IOMMU
> > like above or the timer change, etc.
> 
> Hey, that was a great idea! I reverse-patched sound/pci/hda of 3.0 with
> 2.6.39.3, and it fixes the problem! :)

OK, then try to replace only sound/pci/hda/hda_intel.c and keep the
rest.  What happens?


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635362: Realtek ALC889: HDA Intel and kernel 3.0 gives choppy sound

[Takashi Iwai]

At Tue, 26 Jul 2011 23:14:47 +0200,
Colomban Wendling wrote:
> 
> Hi,
> 
> Following a bug report started in Debian BTS, in bug 635362 [1], I was
> asked to post here after testing upstream kernels and reproducing the bug.
> 
> So, here's the problem: my HDA audio chip [2] started to output very
> choppy sound with Linux kernel 3.0, while it worked perfectly well in
> previous versions -- latest two I used being 2.6.38 and 2.6.39 from
> Debian. Please note that simply booting on 2.6.39 works as usual, so
> it's IMHO definitely a driver regression.

Do you have 2.6.39 kernel messages?  I see the warnings in your
dmesg below in 3.0* kernels.  Did you get it with the working kernel
as well?

> [0.00] [ cut here ]
> [0.00] WARNING: at drivers/pci/dmar.c:634 
> warn_invalid_dmar+0x77/0x85()
> [0.00] Hardware name: MS-7636
> [0.00] Your BIOS is broken; DMAR reported at address fed93000 returns 
> all ones!
> [0.00] BIOS vendor: American Megatrends Inc.; Ver: V1.1; Product 
> Version: 1.0
> [0.00] Modules linked in:
> [0.00] Pid: 0, comm: swapper Not tainted 3.0.0 #4
> [0.00] Call Trace:
> [0.00]  [] ? warn_slowpath_common+0x78/0x8c
> [0.00]  [] ? warn_slowpath_fmt_taint+0x3d/0x42
> [0.00]  [] ? __pte+0x7/0x8
> [0.00]  [] ? __early_set_fixmap+0x89/0x8d
> [0.00]  [] ? __pte+0x7/0x8
> [0.00]  [] ? __early_set_fixmap+0x89/0x8d
> [0.00]  [] ? __pte+0x7/0x8
> [0.00]  [] ? warn_invalid_dmar+0x77/0x85
> [0.00]  [] ? early_iounmap+0xc5/0x114
> [0.00]  [] ? check_zero_address+0xb0/0xeb
> [0.00]  [] ? bad_to_user+0x620/0x620
> [0.00]  [] ? detect_intel_iommu+0x11/0xa6
> [0.00]  [] ? pci_iommu_alloc+0x3f/0x67
> [0.00]  [] ? mem_init+0x14/0xe5
> [0.00]  [] ? start_kernel+0x1d0/0x3c8
> [0.00]  [] ? early_idt_handlers+0x140/0x140
> [0.00]  [] ? x86_64_start_kernel+0x104/0x111
> [0.00] ---[ end trace a7919e7f17c0a725 ]---


Also, you can replace the files in sound/pci/hda/* from 2.6.39 kernel
tree.  If this fixes the problem, it's a sound driver bug.  If not,
it's anything else, e.g. the problem in more core side, e.g. IOMMU
like above or the timer change, etc.


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#631963: [PATCH] ALSA: hda - Disable automute feature by default

[Takashi Iwai]

At Thu, 14 Jul 2011 14:59:32 +0100,
Ben Hutchings wrote:
> 
> On Thu, 2011-07-14 at 10:01 +0200, Takashi Iwai wrote:
> > [I resend this again since it didn't get out due to domain problem of
> >  alsa-project.org.  If you've already seen the mail, please disregard.]
> > 
> > At Thu, 14 Jul 2011 03:07:51 +0100,
> > Ben Hutchings wrote:
> > > 
> > > The default behaviour should be the same as before this feature
> > > was introduced, to avoid user confusion.
> > > 
> > > Reported-by: Toni Mueller 
> > > References: http://bugs.debian.org/631963
> > > Signed-off-by: Ben Hutchings 
> > > ---
> > > The code is rather inconsistent in whether 'mode' means the behaviour or
> > > mechanism of automute.  I didn't touch that but you might want to
> > > consider some renaming.
> > 
> > Sorry, I can't take this.
> > 
> > First, the fix is touching a wrong place.  There are several flags to
> > control the auto-mute behavior.  spec->automute is a flag to control
> > the all auto-mute feature including the headphone jack.  For the
> > line-out jack, it's spec->automute_lines flag.
> 
> OK.
> 
> > Secondly, this is a fix of long-standing bug.  With this change, the
> > driver finally behaves consistently in a way seen in other OS.
> [...]
> 
> But why would Linux users know or care how it behaves in the other OS?

Why not?

This change also makes the behavior consistent even within Linux, now
behaving same as other HD-audio codec drivers.


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#631963: [PATCH] ALSA: hda - Disable automute feature by default

[Takashi Iwai]

[I resend this again since it didn't get out due to domain problem of
 alsa-project.org.  If you've already seen the mail, please disregard.]

At Thu, 14 Jul 2011 03:07:51 +0100,
Ben Hutchings wrote:
> 
> The default behaviour should be the same as before this feature
> was introduced, to avoid user confusion.
> 
> Reported-by: Toni Mueller 
> References: http://bugs.debian.org/631963
> Signed-off-by: Ben Hutchings 
> ---
> The code is rather inconsistent in whether 'mode' means the behaviour or
> mechanism of automute.  I didn't touch that but you might want to
> consider some renaming.

Sorry, I can't take this.

First, the fix is touching a wrong place.  There are several flags to
control the auto-mute behavior.  spec->automute is a flag to control
the all auto-mute feature including the headphone jack.  For the
line-out jack, it's spec->automute_lines flag.

Secondly, this is a fix of long-standing bug.  With this change, the
driver finally behaves consistently in a way seen in other OS.


thanks,

Takashi

> 
> Ben.
> 
>  sound/pci/hda/patch_realtek.c |   74 
> ++---
>  1 files changed, 3 insertions(+), 71 deletions(-)
> 
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index b48fb43..1247a04 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -306,7 +306,7 @@ struct alc_multi_io {
>  };
>  
>  enum {
> - ALC_AUTOMUTE_PIN,   /* change the pin control */
> + ALC_AUTOMUTE_PIN = 1,   /* change the pin control */
>   ALC_AUTOMUTE_AMP,   /* mute/unmute the pin AMP */
>   ALC_AUTOMUTE_MIXER, /* mute/unmute mixer widget AMP */
>  };
> @@ -1599,10 +1599,9 @@ static void alc_init_auto_hp(struct hda_codec *codec)
>   snd_hda_codec_write_cache(codec, nid, 0,
> AC_VERB_SET_UNSOLICITED_ENABLE,
> AC_USRSP_EN | ALC880_HP_EVENT);
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_PIN;
>   }
> - if (spec->automute && cfg->line_out_pins[0] &&
> + if (spec->automute_mode && cfg->line_out_pins[0] &&
>   cfg->line_out_pins[0] != cfg->hp_pins[0] &&
>   cfg->line_out_pins[0] != cfg->speaker_pins[0]) {
>   for (i = 0; i < cfg->line_outs; i++) {
> @@ -1619,7 +1618,7 @@ static void alc_init_auto_hp(struct hda_codec *codec)
>   spec->automute_lines = spec->detect_line;
>   }
>  
> - if (spec->automute) {
> + if (spec->automute_mode) {
>   /* create a control for automute mode */
>   alc_add_automute_mode_enum(codec);
>   spec->unsol_event = alc_sku_unsol_event;
> @@ -2241,7 +2240,6 @@ static void alc889_automute_setup(struct hda_codec 
> *codec)
>   spec->autocfg.speaker_pins[2] = 0x17;
>   spec->autocfg.speaker_pins[3] = 0x19;
>   spec->autocfg.speaker_pins[4] = 0x1a;
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_AMP;
>  }
>  
> @@ -2259,7 +2257,6 @@ static void alc888_fujitsu_xa3530_setup(struct 
> hda_codec *codec)
>   spec->autocfg.hp_pins[1] = 0x1b; /* hp */
>   spec->autocfg.speaker_pins[0] = 0x14; /* speaker */
>   spec->autocfg.speaker_pins[1] = 0x15; /* bass */
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_AMP;
>  }
>  
> @@ -2543,7 +2540,6 @@ static void alc888_acer_aspire_4930g_setup(struct 
> hda_codec *codec)
>   spec->autocfg.speaker_pins[0] = 0x14;
>   spec->autocfg.speaker_pins[1] = 0x16;
>   spec->autocfg.speaker_pins[2] = 0x17;
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_AMP;
>  }
>  
> @@ -2555,7 +2551,6 @@ static void alc888_acer_aspire_6530g_setup(struct 
> hda_codec *codec)
>   spec->autocfg.speaker_pins[0] = 0x14;
>   spec->autocfg.speaker_pins[1] = 0x16;
>   spec->autocfg.speaker_pins[2] = 0x17;
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_AMP;
>  }
>  
> @@ -2567,7 +2562,6 @@ static void alc888_acer_aspire_7730g_setup(struct 
> hda_codec *codec)
>   spec->autocfg.speaker_pins[0] = 0x14;
>   spec->autocfg.speaker_pins[1] = 0x16;
>   spec->autocfg.speaker_pins[2] = 0x17;
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_AMP;
>  }
>  
> @@ -2579,7 +2573,6 @@ static void alc889_acer_aspire_8930g_setup(struct 
> hda_codec *codec)
>   spec->autocfg.speaker_pins[0] = 0x14;
>   spec->autocfg.speaker_pins[1] = 0x16;
>   spec->autocfg.speaker_pins[2] = 0x1b;
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_AMP;
>  }
>  
> @@ -3667,7 +3660,6 @@ static void alc880_uniwill_setup(struct hda_codec 
> *codec)
>   spec->autocfg.hp_pins[0] = 0x14;
>   spec->autocfg.speaker_pins[0] = 0x15;
>   spec->autocfg.speaker_pins[0] = 0x16;
> - spec->automute = 1;
>   spec->automute_mode = ALC_AUTOMUTE_AMP;
>  }
>  
> @@ -3699,7 +3691,6 @@ static void alc880_uniw

Bug#631963: linux-image-3.0.0-rc4-686-pae: no sound out the rear plugs

[Takashi Iwai]

At Wed, 29 Jun 2011 20:45:02 +0200,
Toni Mueller wrote:
> 
> Hi,
> 
> On Wed, 29.06.2011 at 07:21:33 +0200, Takashi Iwai  wrote:
> > I'd definitely need alsa-info.sh outputs on both working and
> > non-working kernels, i.e. on 2.6.38 and 3.0-rc4.
> 
> this first post is for the non-working kernel. The other kernel's
> information will follow tomorrow.

I guess this must be the new feature, "Auto-Mute Mode".
When this is enabled, the line-outs are muted automatically when the
headphone jack is plugged.
In your case, turn this mixer enum off.


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#631963: linux-image-3.0.0-rc4-686-pae: no sound out the rear plugs

[Takashi Iwai]

At Wed, 29 Jun 2011 04:58:53 +0100,
Ben Hutchings wrote:
> 
> On Tue, 2011-06-28 at 19:24 +0200, Toni Mueller wrote:
> > Package: linux-2.6
> > Version: 3.0.0~rc4-1~experimental.1
> > Severity: normal
> > Tags: upstream
> > 
> > 
> > Hi,
> > 
> > when using this kernel, I hear no sound using the speakers, only using
> > the headphones, plugged in at the front.
> > 
> > With 2.6.38 (dmesg attached), the speakers get fed, too.
> [...]
> > 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) 
> > [1002:4383]
> > Subsystem: ASUSTeK Computer Inc. Device [1043:841b]
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> > Stepping- SERR- FastB2B- DisINTx-
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- 
> > SERR-  > Latency: 64, Cache Line Size: 64 bytes
> > Interrupt: pin A routed to IRQ 16
> > Region 0: Memory at fe8f (64-bit, non-prefetchable) [size=16K]
> > Capabilities: 
> > Kernel driver in use: HDA Intel
> [...]
> 
> Takashi, this looks like a regression in control parsing in the realtek
> codec.  The kernel logs are at  but I
> don't think they'll tell you much.

I'd definitely need alsa-info.sh outputs on both working and
non-working kernels, i.e. on 2.6.38 and 3.0-rc4.

> Toni, can you provide the output of 'amixer -c 0 controls' under 2.6.38
> and 3.0-rc4?

alsa-info.sh outputs contain already these.
Toni, could you give alsa-info.sh outputs of the above kernels?


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

[Takashi Iwai]

At Mon, 04 Apr 2011 10:42:57 +0200,
Svante Signell wrote:
> 
> On Thu, 2011-03-31 at 00:42 +0200, Svante Signell wrote:
> > On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote:
> > > Svante Signell wrote:
> > > > Code: f4 01 00 00 ef 31 f6 48 89 df e8 15 dd ff ff 85 c0
> > > > 0f 88 2b 03 00 00 48 89 ef e8 ee 11 b9 e0 8b 7b 40 e8 9f 25 a7 e0 48 8b
> > > > 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
> > > 
> > >5:   31 f6   xor%esi,%esi
> > >7:   48 89 dfmov%rbx,%rdi
> > >a:   e8 15 dd ff ff  callq  0xdd24
> > >f:   85 c0   test   %eax,%eax
> > >   11:   0f 88 2b 03 00 00   js 0x342
> > >   17:   48 89 efmov%rbp,%rdi
> > >   1a:   e8 ee 11 b9 e0  callq  0xe0b9120d
> > >   1f:   8b 7b 40mov0x40(%rbx),%edi
> > >   22:   e8 9f 25 a7 e0  callq  0xe0a725c6
> > >   27:   48 8b 43 38 mov0x38(%rbx),%rax
> > >   2b:   66 8b 10mov(%rax),%dx <-- crash here
> > >   2e:   66 89 14 24 mov%dx,(%rsp)
> > >   32:   8b 43 14mov0x14(%rbx),%eax
> > >   35:   83 e8 03sub$0x3,%eax
> > >   38:   83 f8 01cmp$0x1,%eax
> > >   3b:   77 32   ja 0x6f
> > >   3d:   31 d2   xor%edx,%edx
> > > 
> > > This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is
> > > 0xc90011c08000 which does look like a valid pointer, but isn't.
> > 
> > Thank you Clemens! Maybe your input is sufficient to solve this problem.
> > I have now installed the debug version of the kernel, the objdump output
> > is attached (please let me know if you are missing something).sorry, I
> > don't know where to find the relevant information in this file, but that
> > is all I have (still very large). (Does not include the error messages
> > on stderr, maybe something is still missing.)
> 
> Anything happening here with respect to this bug? How can I help
> further? Booting with 2.6.32 all the time does not feel lika a good
> solution in long term.

The point where it Oops implies that the problem isn't in the sound
driver but rather in a breakage in a deeper level, either PCI core,
x86 mm or ACPI/BIOS.

Any chance to bisect the kernel?


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#613979: [alsa-devel] Problems with snd_hda_intel in Linux kernel 2.6.38

[Takashi Iwai]

At Wed, 30 Mar 2011 12:25:44 +0200,
Svante Signell wrote:
> 
> On Tue, 2011-03-29 at 13:10 +0200, Takashi Iwai wrote:
> > At Tue, 29 Mar 2011 12:58:16 +0200,
> > Svante Signell wrote:
> > > 
> > > On Tue, 2011-03-29 at 12:31 +0200, Takashi Iwai wrote:
> > > > At Tue, 29 Mar 2011 12:24:40 +0200,
> > > > Svante Signell wrote:
> ...
> > > > But let's check the Oops first as below.
> > 
> > > > Also, please try to decode the line from the code shown in the Oops.
> > > > It's a bit too little information to analyze, unfortunately.
> ...
> > As mentioned, you can decode the binary dump in Oops to guess which
> > line of the source code corresponds to the Oops point.
> > Use gdb or objdump to figure out the disassembled code.
> > For example,
> > 
> > % objdump -D -l /lib/modules/$(uname 
> > -r)/kernel/sound/pci/hda/snd-hda-intel.ko
> > 
> > Then look for azx_probe.  Calculate the position from the offset
> > Oops gave, compare the hex codes with the data show in "Code" section
> > of Oops.
> > objdump with -l will show the source code line as well, so you'll see
> > now more exactly where it was triggered.
> 
> Below is the kernel Oops and the objdump output related to azx_probe.
> Unfortunately I don't know where to find the Oops offset!

This is shown in below:

> [4.632005] RIP: 0010:[]  []
> azx_probe+0x3ad/0x870 [snd_hda_intel]

The offset is 0x3ad.  As azx_probe() in the disassembled code begins
with 0x1fd, it points to 0x5aa (0x1fd + 0x3ad).  You can see the
disassembled code matches with the dump in "Code:" in Oops.

However, you objdump output doesn't give the line number.  Did you
install the corresponding debug package?  Usually this is stripped in
the main package and provided as an add-on.


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#596478: [PATCH] ALSA: emux: Add trivial compat ioctl handler

[Takashi Iwai]

At Sun, 12 Sep 2010 02:41:47 +0100,
Ben Hutchings wrote:
> 
> Reported-by: Carmen Cru 
> Signed-off-by: Ben Hutchings 
> ---
> This is compile-tested only.

Thanks, applied now.


Takashi

> 
> Ben.
> 
>  sound/synth/emux/emux_hwdep.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/sound/synth/emux/emux_hwdep.c b/sound/synth/emux/emux_hwdep.c
> index ff0b2a8..5ae1eae 100644
> --- a/sound/synth/emux/emux_hwdep.c
> +++ b/sound/synth/emux/emux_hwdep.c
> @@ -128,6 +128,9 @@ snd_emux_init_hwdep(struct snd_emux *emu)
>   strcpy(hw->name, SNDRV_EMUX_HWDEP_NAME);
>   hw->iface = SNDRV_HWDEP_IFACE_EMUX_WAVETABLE;
>   hw->ops.ioctl = snd_emux_hwdep_ioctl;
> + /* The ioctl parameter types are compatible between 32- and
> +  * 64-bit architectures, so use the same function. */
> + hw->ops.ioctl_compat = snd_emux_hwdep_ioctl;
>   hw->exclusive = 1;
>   hw->private_data = emu;
>   if ((err = snd_card_register(emu->card)) < 0)
> -- 
> 1.7.1
> 
> 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#536896: linux-image-2.6.26-2-amd64: audio popping with gstreamer using apps when using amd64 kernel and i386 userspace

[Takashi Iwai]

At Sun, 11 Apr 2010 21:25:16 +0100,
Ben Hutchings wrote:
> 
> [1  ]
> [Earlier messages can be found at http://bugs.debian.org/536896 ]
> 
> On Mon, 2010-04-12 at 01:08 +0800, James Andrewartha wrote:
> > On Thu, 25 Feb 2010, Moritz Muehlenhoff wrote:
> > 
> > > On Tue, Jul 14, 2009 at 09:57:54PM +0800, James Andrewartha wrote:
> > > > Package: linux-image-2.6.26-2-amd64
> > > > Version: 2.6.26-17
> > > > Severity: normal
> > > > 
> > > > All audio from gstreamer-using apps (eg Totem and Banshee) pops when I 
> > > > use a
> > > > 2.6.{25,26,28,30} amd64 kernel and i386 userspace. 
> > > > 2.6.24-etchnhalf.1-amd64
> > > > does not have this problem, nor does 2.6.26-2-686. It doesn't occur 
> > > > when using
> > > > non-gstreamer apps like mplayer or mpd, nor with various gst-launch 
> > > > pipelines
> > > > suggested by #gstreamer like gst-launch playbin 
> > > > uri=file:///home/trs80/a.mp3
> > > 
> > > Hi,
> > > The next release of Debian (6.0, code name Squeeze) will be based
> > > on 2.6.32. Please test the current 2.6.32 from unstable/testing and tell
> > > us whether the problem persists. If so, we should report it upstream
> > > to the kernel.org developers.
> > > 
> > > The 2.6.32 kernel is available from packages.debian.org and can
> > > be installed in both Debian stable, testing and unstable
> > > installations.
> > 
> > I've bisected it, and the bad patch is 
> > 130755108ba03461f69da990e54e02a254accd23:
> 
> Thanks for taking the time to do this.
> 
> > Author: Takashi Iwai   2008-01-09 02:08:14
> > Committer: Jaroslav Kysela   2008-02-01 01:29:47
> > Parent: d948035a928400ae127c873fbf771389bee18949 ([ALSA] Remove PCM 
> > xfer_align sw params)
> > 
> > [ALSA] PCM - clean up snd_pcm_lib_read/write
> > 
> > Introduce a common helper function for snd_pcm_lib_read and 
> > snd_pcm_lib_write
> > for cleaning up the code.
> > 
> > Signed-off-by: Takashi Iwai 
> > Signed-off-by: Jaroslav Kysela 
> > 
> > I don't know anything about this code, but I'm happy to deal with upstream 
> > if you'd prefer me to.
> 
> The above commit is supposed to be cleanup, but it has at least one
> semantic change: snd_pcm_mmap_control::avail_min no longer applies to
> non-blocking file handles.  I don't know whether this is was an
> intentional or unintentional change, but it wasn't commented.  I also
> don't know whether this can explain the popping, but I expect that it
> has changed the timing of audio I/O.

The above change is essentially a fix of the buggy behavior for
non-blocking access.  avail_min is the definition for wake-up
behavior, and it doesn't define the blocking behavior.
But, it's possible that this changes the timing, indeed.  If so, it
implies that the app expects somehow wrongly.


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#573243: Front Mic Boost mixer control missing on 2.6.33

[Takashi Iwai]

At Tue, 09 Mar 2010 23:52:03 -0500,
Anthony DeRobertis wrote:
> 
> On 03/09/2010 09:30 PM, maximilian attems wrote:
> > please sent output of alsa-info.sh of 2.6.32 and 2.6.3
> Attached. I couldn't find an alsa-info.sh in any Debian package, so I 
> grabbed the one from here: 
> http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=utils/alsa-info.sh;hb=63f682cd3ca18967acdb426de8548c050a16c6f3

Try model=auto option.


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#536340: [Linux-2.6.30-1-amd64] No sound out of the front jack

[Takashi Iwai]

At Fri, 19 Feb 2010 12:31:49 +0100,
Marco Mattiolo wrote:
> 
> In data giovedì 18 febbraio 2010 17:38:58, maximilian attems ha scritto:
> : > On Thu, Feb 18, 2010 at 05:35:34PM +0100, Takashi Iwai wrote:
> > > Thanks.  Do you really need model=dell-bios option even with the very
> > > latest alsa-driver (e.g. 2.6.33-rc8)?
> > >
> > > If the latest alsa-driver still doesn't work without model option,
> > > please give alsa-info.sh outputs both with and without model=dell-bios
> > > option to compare.  This is needed to understand what is really
> > > missing on your device.
> > 
> > here you'll find a prebuild 2.6.33-rc8 image deb:
> > http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.33-rc8-amd64_2.6.33~
> > rc8-1~experimental.1_amd64.deb
> >  http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.33-rc8-amd64_2.6.33
> > ~rc8-1~experimental.1_amd64.deb.sha1sum.asc
> > 
> > thanks for your feedback.
> > 
> OK, I've got the test. First, thank you max for the debs.
> 
> I've made the test in console-mode, due to lack of kernel headers (and nVidia 
> drivers), so I used alsamixer in place of kmix and moc in place of kaffeine.
> 
> The front jack works on 2.6.33 with model=dell-bios option.
> The front jack doesn't work on 2.6.33 without model specification for 
> snd_hda_intel module.

Thanks.  Just wondering whether model=3stack works better.
Other Intel mobo use this quirk instead.

> Don't know if it's important, but when changing linux to 2.6.33, I came 
> across 
> these warning messages on boot:
> [...]
> Setting up ALSA...warning: 'alsactl restore' failed with error message 
> 'Unknown hardware: "HDA-Intel" "Sigmatel STAC9227" 
> "HDA:3847618,8086a201,00100201" "0x8086" "0xa201"
> Hardware is initialised using a guess method

This is rather a problem of alsactl.  You can ignore it.


thanks,

Takashi



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#536340: [Linux-2.6.30-1-amd64] No sound out of the front jack

[Takashi Iwai]

At Wed, 17 Feb 2010 19:54:05 +0100,
Marco Mattiolo wrote:
> 
> In data mercoledì 17 febbraio 2010 14:47:56, maximilian attems ha scritto:
> > 
> > I'm a bit confused by the mess of newlines in your bug report
> > http://bugs.debian.org/536340
> > 
> > could you please rerun this below and post the output.
> > so that the dell quirk can be added in the hda driver for your box:
> > 
> > alsa-info.sh --no-upload
> > 
> Of course, the report is attached.
> But please note: mine is an assembled pc, not a Dell one!

Thanks.  Do you really need model=dell-bios option even with the very
latest alsa-driver (e.g. 2.6.33-rc8)?

If the latest alsa-driver still doesn't work without model option,
please give alsa-info.sh outputs both with and without model=dell-bios
option to compare.  This is needed to understand what is really
missing on your device.
 

thanks,

Takashi



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#547994: [alsa-devel] [Pkg-alsa-devel] Bug#547994: snd-hda-intel and MSI

[Takashi Iwai]

At Thu, 24 Sep 2009 03:04:51 -0700 (PDT),
Dan Chen wrote:
> 
> > Dan, your from-address and sign-off address are different in the patch.
> > Could you unify?
> 
> Indeed, here's a new patch.

Thanks, applied now.


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#547994: [alsa-devel] [Pkg-alsa-devel] Bug#547994: snd-hda-intel and MSI

[Takashi Iwai]

At Wed, 23 Sep 2009 17:28:38 -0700 (PDT),
Dan Chen wrote:
> 
> Attached, please find a patch against current sound-2.6.git HEAD resolving 
> this issue.

Dan, your from-address and sign-off address are different in the patch.
Could you unify?


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#547994: [alsa-devel] snd-hda-intel and MSI

[Takashi Iwai]

At Wed, 23 Sep 2009 16:33:06 +0200,
Elimar Riesebieter wrote:
> 
> Hi folks,
> 
> are there any contradictions to enable-msi=1 by default?

MSI is broken on some platforms.  IIRC, almost all non-Intel platforms
didn't work until the recent ones.  So, it can't be enabled blindly as
default, unfortunately.

> There are
> users with chips like an
> 
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio 
> Controller (rev 03)
> Subsystem: Hewlett-Packard Company Device 30f7
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 33
> Region 0: Memory at dc50 (64-bit, non-prefetchable) [size=16K]
> Capabilities: 
> Kernel driver in use: HDA Intel
> 
> which only works with MSI. And it is somewhat hard to find the appropriate
> Documantation in HD-Audio.txt.

A patch is always welcome.

> 2nd it will be very hard for Distributers to
> maintain modul options by chip ID's.

It's not a question for distributors but the upstream maintainers 
to maintain the quirk table :)


thanks,

Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#544607: [alsa-devel] [PATCH] Bug#544607: /usr/share/alsa/init/default missing closing brace for format in 5 cases

[Takashi Iwai]

At Sat, 5 Sep 2009 02:01:03 +0200,
Elimar Riesebieter wrote:
> 
> [1  ]
> [1.1  ]
> [1.1.1  ]
> * Jaroslav Kysela [090902 14:34 +0200]
> > On Wed, 2 Sep 2009, Elimar Riesebieter wrote:
> > 
> > >forward 544607 alsa-de...@alsa-project.org
> > 
> > >>-ENV{has_pmaster_vol}=="true",CTL{values)="100%",GOTO="headphone0_end"
> > >>+ENV{has_pmaster_vol}=="true",CTL{values}="100%",GOTO="headphone0_end"
> 
> It is not only line 52. We have 4 more c+p errors. See attached
> patch.

It's (blindly) in my last commit that I forgot.  Pushed now.


Takashi


> 
> Elimar
> 
> -- 
>   We all know Linux is great... it does infinite loops in 5 seconds.
> -- Linus Torvalds
> [1.1.2 alsactl_brace.patch ]
> # Fix wrong enclosed values with braces
> # -- Elimar Riesebieter   Fri, 04 Sep 2009 22:15:12 +0200
> Index: alsa-utils-1.0.21/alsactl/init/default
> ===
> --- alsa-utils-1.0.21.orig/alsactl/init/default   2009-08-31 
> 17:13:36.0 +0200
> +++ alsa-utils-1.0.21/alsactl/init/default2009-09-04 22:19:32.0 
> +0200
> @@ -39,7 +39,7 @@
>  CTL{name}="Front Playback Volume",PROGRAM!="__ctl_search",GOTO="front0_end"
>  # if master volume control is present, turn front volume to max
>  ENV{has_pmaster_vol}=="true",CTL{values}="0dB",RESULT=="0",GOTO="front0_end"
> -ENV{has_pmaster_vol}=="true",CTL{values)="100%",GOTO="front0_end"
> +ENV{has_pmaster_vol}=="true",CTL{values}="100%",GOTO="front0_end"
>  CTL{values}="$env{pvolume}",RESULT!="0",CTL{values}="$env{ppercent}"
>  LABEL="front0_end"
>  CTL{name}="Front Playback Switch",PROGRAM=="__ctl_search", \
> @@ -49,7 +49,7 @@
>  CTL{name}="Headphone Playback 
> Volume",PROGRAM!="__ctl_search",GOTO="headphone0_end"
>  # if master volume control is present, turn headphone volume to max
>  
> ENV{has_pmaster_vol}=="true",CTL{values}="0dB",RESULT=="0",GOTO="headphone0_end"
> -ENV{has_pmaster_vol}=="true",CTL{values)="100%",GOTO="headphone0_end"
> +ENV{has_pmaster_vol}=="true",CTL{values}="100%",GOTO="headphone0_end"
>  CTL{values}="$env{pvolume}",RESULT!="0",CTL{values}="$env{ppercent}"
>  LABEL="headphone0_end"
>  CTL{name}="Headphone Playback Switch",PROGRAM=="__ctl_search", \
> @@ -72,7 +72,7 @@
>   CTL{name}="PCM Volume",PROGRAM!="__ctl_search", GOTO="pcm0_end"
>  # if master volume control is present, turn PCM volume to max
>  ENV{has_pmaster_vol}=="true",CTL{values}="0dB",RESULT=="0",GOTO="pcm0_end"
> -ENV{has_pmaster_vol}=="true",CTL{values)="100%",GOTO="pcm0_end"
> +ENV{has_pmaster_vol}=="true",CTL{values}="100%",GOTO="pcm0_end"
>  # exception - some HDA codecs have shifted dB range
>  
> CTL{dBmin}=="-34.50dB",CTL{dBmax}=="12.00dB",CTL{values}="0dB",GOTO="pcm0_end"
>  CTL{dBmin}=="-30.00dB",CTL{dBmax}=="0dB",CTL{values}="0dB",GOTO="pcm0_end"
> @@ -86,7 +86,7 @@
>CTL{name}="PCM Volume",PROGRAM!="__ctl_search",GOTO="pcm1_end"
>  # if master volume control is present, turn PCM volume to max
>  ENV{has_pmaster_vol}=="true",CTL{values}="0dB",RESULT=="0",GOTO="pcm1_end"
> -ENV{has_pmaster_vol}=="true",CTL{values)="100%",GOTO="pcm1_end"
> +ENV{has_pmaster_vol}=="true",CTL{values}="100%",GOTO="pcm1_end"
>  # exception - some HDA codecs have shifted dB range
>  
> CTL{dBmin}=="-34.50dB",CTL{dBmax}=="12.00dB",CTL{values}="0dB",GOTO="pcm1_end"
>  CTL{dBmin}=="-30.00dB",CTL{dBmax}=="0dB",CTL{values}="0dB",GOTO="pcm1_end"
> @@ -125,7 +125,7 @@
>  CTL{name}="CD Playback Volume",PROGRAM!="__ctl_search", GOTO="cd0_end"
>  # if master volume control is present, turn CD volume to max
>  ENV{has_pmaster_vol}=="true",CTL{values}="0dB",RESULT=="0",GOTO="cd0_end"
> -ENV{has_pmaster_vol}=="true",CTL{values)="100%",GOTO="cd0_end"
> +ENV{has_pmaster_vol}=="true",CTL{values}="100%",GOTO="cd0_end"
>  # exception - some HDA codecs have shifted dB range
>  CTL{dBmin}=="-34.50dB",CTL{dBmax}=="12.00dB",CTL{values}="0dB",GOTO="cd0_end"
>  CTL{dBmin}=="-30.00dB",CTL{dBmax}=="0dB",CTL{values}="0dB",GOTO="cd0_end"
> [1.2 Digital signature ]
> 
> [2  ]
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#539454: [alsa-devel] [Pkg-alsa-devel] Bug#539454: libasound2: Division by zero in pcm_rate.c when period_size->min == 0

[Takashi Iwai]

At Thu, 6 Aug 2009 21:40:04 +0200,
Elimar Riesebieter wrote:
> 
> forwarded 539454 alsa-de...@alsa-project.org
> tags 539454 + patch
> 
> thanks
> 
> Hi,
> 
> this is Debian bug 539454. It would be better to fix it in general.
> Patching the Debian Package isn't a reasonable solution.

Thanks, applied now to GIT tree.


Takashi

> 
> Thanks
> Elimar
> 
> 
> * John Lindgren [090731 22:29 -0400]
> > Package: libasound2
> > Version: 1.0.20-2
> > Severity: important
> > Tags: patch
> > 
> > 
> > System: Dell Inspiron 1200
> > Card: Intel ICH6
> > Chip: SigmaTel STAC9752,53
> > 
> > 
> > Steps to reproduce:
> > 
> > 1. Disable dmix: mv /usr/share/alsa/cards/ICH4.conf 
> > /usr/share/alsa/cards/ICH4.conf.0
> > 2. Restart ALSA: /etc/rcS.d/S50alsa-utils restart
> > 3. Clear Audacity configuration: rm -r ~/.audacity*
> > 4. Run Audacity 1.3.7-3 in Valgrind: valgrind --tool=none audacity
> > 5. Choose "OK" in the "Audacity First Run" dialog.
> > 
> > 
> > Valgrind output:
> > 
> > ==26237== Process terminating with default action of signal 8 (SIGFPE)
> > ==26237==  Integer divide by zero at address 0x64D1CD56
> > ==26237==at 0x4CAD600: snd_pcm_rate_hw_refine_cchange (pcm_rate.c:189)
> > ==26237==by 0x4C97B2E: snd1_pcm_hw_refine_slave (pcm_params.c:2182)
> > ==26237==by 0x4CAD7D5: snd_pcm_rate_hw_refine (pcm_rate.c:222)
> > ==26237==by 0x4C96015: snd_pcm_hw_refine (pcm_params.c:2264)
> > ==26237==by 0x4CA116B: snd1_pcm_generic_hw_refine (pcm_generic.c:98)
> > ==26237==by 0x4C97B0D: snd1_pcm_hw_refine_slave (pcm_params.c:2158)
> > ==26237==by 0x4CC0E25: snd_pcm_lfloat_hw_refine (pcm_lfloat.c:261)
> > ==26237==by 0x4C96015: snd_pcm_hw_refine (pcm_params.c:2264)
> > ==26237==by 0x4C99068: sndrv_pcm_hw_params (pcm_params.c:2290)
> > ==26237==by 0x4CB209C: snd_pcm_plug_hw_params (pcm_plug.c:1045)
> > ==26237==by 0x4C9921D: sndrv_pcm_hw_params (pcm_params.c:2299)
> > ==26237==by 0x4C947B0: snd_pcm_hw_params (pcm.c:822)
> > 
> > 
> > Diagnosis:
> > 
> > pcm_rate.c:189 reads:
> > 
> > if ((buffer_size->min / period_size->min) * period_size->min == 
> > buffer_size->min) {
> > 
> > When using the ICH4 driver without dmix, period_size->min == 0. Handle
> > this by changing pcm_rate.c:189 to:
> > 
> > if (period_size->min > 0 && (buffer_size->min / period_size->min) * 
> > period_size->min == buffer_size->min) {
> > 
> > With this change, Audacity starts without problems.
> 
> Patch against native 1.0.20:
> 
> diff -Naurd a/src/pcm/pcm_rate.c b/src/pcm/pcm_rate.c
> --- a/src/pcm/pcm_rate.c  2009-05-06 09:07:23.0 +0200
> +++ b/src/pcm/pcm_rate.c  2009-08-06 21:34:23.0 +0200
> @@ -186,7 +186,7 @@
>   if (!snd_interval_checkempty(period_size) &&
>   period_size->openmin && period_size->openmax &&
>   period_size->min + 1 == period_size->max) {
> - if ((buffer_size->min / period_size->min) * 
> period_size->min == buffer_size->min) {
> + if (period_size->min > 0 && (buffer_size->min / 
> period_size->min) * period_size->min == buffer_size->min) {
>   snd_interval_set_value(period_size, 
> period_size->min);
>   } else if ((buffer_size->max / period_size->max) * 
> period_size->max == buffer_size->max) {
>   snd_interval_set_value(period_size, 
> period_size->max);
> 
> 
> -- 
>   Experience is something you don't get until 
>   just after you need it!
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#517241: [alsa-devel] Laptop (Samsung Q45) speakers unmute when master channel is unmuted even with headphones connected

[Takashi Iwai]

At Fri, 19 Jun 2009 11:56:29 +0100,
Sam Morris wrote:
> 
> On Thu, 2009-05-07 at 17:11 +0200, Takashi Iwai wrote:
> > At Tue, 05 May 2009 11:58:39 +0100,
> > Sam Morris wrote:
> > > 
> > > On Tue, 2009-05-05 at 12:47 +0200, Takashi Iwai wrote:
> > > > At Sat, 2 May 2009 13:14:42 +0100,
> > > > Sam Morris wrote:
> > > > > 
> > > > > Since Linux 2.6.28 and through to 2.6.30-rc4, the hda-intel driver 
> > > > > has had a
> > > > > bug on my laptop (a Samsung Q45).
> > > > > 
> > > > > If I connect my headphones, the laptop's internal speakers are 
> > > > > muted--fine. But 
> > > > > if I then mute and unmute the master mixer channel, the speakers come 
> > > > > back to
> > > > > life, even though the headphones are still connected.
> > > > 
> > > > Could you run alsa-info.sh with --no-upload option, and attach the
> > > > generated file?
> > > 
> > > Here you go!
> > 
> > Thanks.
> > 
> > What if you use model=auto option?
> 
> This is fixed in 2.6.30, but only if I use the model=auto option. :)

What about with the later version, e.g. Linus git tree?
Or you can use sound git tree
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

I think this was already fixed there.


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#517241: [alsa-devel] Laptop (Samsung Q45) speakers unmute when master channel is unmuted even with headphones connected

[Takashi Iwai]

At Tue, 05 May 2009 11:58:39 +0100,
Sam Morris wrote:
> 
> On Tue, 2009-05-05 at 12:47 +0200, Takashi Iwai wrote:
> > At Sat, 2 May 2009 13:14:42 +0100,
> > Sam Morris wrote:
> > > 
> > > Since Linux 2.6.28 and through to 2.6.30-rc4, the hda-intel driver has 
> > > had a
> > > bug on my laptop (a Samsung Q45).
> > > 
> > > If I connect my headphones, the laptop's internal speakers are 
> > > muted--fine. But 
> > > if I then mute and unmute the master mixer channel, the speakers come 
> > > back to
> > > life, even though the headphones are still connected.
> > 
> > Could you run alsa-info.sh with --no-upload option, and attach the
> > generated file?
> 
> Here you go!

Thanks.

What if you use model=auto option?

Also it may be better to try the latest sound git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git


Takashi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#517241: [alsa-devel] Laptop (Samsung Q45) speakers unmute when master channel is unmuted even with headphones connected

[Takashi Iwai]

At Sat, 2 May 2009 13:14:42 +0100,
Sam Morris wrote:
> 
> Since Linux 2.6.28 and through to 2.6.30-rc4, the hda-intel driver has had a
> bug on my laptop (a Samsung Q45).
> 
> If I connect my headphones, the laptop's internal speakers are muted--fine. 
> But 
> if I then mute and unmute the master mixer channel, the speakers come back to
> life, even though the headphones are still connected.

Could you run alsa-info.sh with --no-upload option, and attach the
generated file?


thanks,

Takashi

> 
> Please keep 517241-forwar...@bugs.debian.org CC'd in follow-ups.
> 
> -- 
> Sam Morris
> https://robots.org.uk/
>  
> PGP key id 1024D/5EA01078
> 3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#436723: [alsa-devel] Bug#436723: Playing sound hands on powerbook3, 5 with 2.6.21-2 kernel

[Takashi Iwai]

At Mon, 14 Jan 2008 01:06:41 +0100,
maximilian attems wrote:
> 
> [ adding alsa upstream on cc ]
> 
> On Mon, Jan 14, 2008 at 12:21:11AM +0100, [EMAIL PROTECTED] wrote:
> > 
> > Please have a look at
> > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/87652/comments/48
> > and the corresponding patch to see wether this patch solves this sound
> > issue.
> 
> woow, i thought to fire up "try newer kernel", but your patch still
> applies to current linus git:
>  ~/src/linux-2.6$ patch -p0 --dry-run < ~/pmac.c.diff 
>  patching file sound/ppc/pmac.c
>  Hunk #5 succeeded at 868 (offset -24 lines).
>  Hunk #6 succeeded at 1207 (offset -47 lines).
> 
> so bringing that to upstream alsa radar.

Thanks for report.  I'm willing to apply it, but I'd need a proper
changelog and a sign-off to merge to the upstream.
Please post a patch to alsa-devel ML with them.


Takashi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438118: [alsa-devel] [Pkg-alsa-devel] Bug#438118: alsa-utils: aplay non-blocking mode isn't working

[Takashi Iwai]

At Fri, 14 Dec 2007 11:53:11 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Fri, 14 Dec 2007, Anders Boström wrote:
> 
> > >>>>> "TI" == Takashi Iwai <[EMAIL PROTECTED]> writes:
> > 
> >  TI> OK, thanks, I see the problem now.
> >  >> 
> >  TI> I don't remember whether it's a feature or a bug.  The drain ioctl
> >  TI> rejects the non-block mode.
> >  >> 
> >  >> I can understand the idea here, that in non-blocking mode, no call
> >  >> should block, ever. But on the other hand, if you call the drain
> >  >> ioctl, you probably expect it to work, even in non-blocking mode. Why
> >  >> would you otherwise call it?
> > 
> >  TI> Yes, that's my opinion, too.  This particular ioctl is to block the
> >  TI> operation, so it should be allowed as long as it's called.
> > 
> >  TI> But I vaguely remember that we discussed about it, and the current
> >  TI> form is the result of that.  Namely, we can call
> >  TI> snd_pcm_nonblock(FALSE) explicitly before calling snd_pcm_drain().
> > 
> >  TI> Though, I prefer fixing the behavior in the core side to allow the
> >  TI> blocking with this call...  Any reasonable objections in mind?
> > 
> > Any progress in including a solotion to this bug in mainstream
> > alsa & linux kernel? Has anything been done? The patch works fine for
> > me...
> 
> I think that this proposal breaks basic posix rules.

AFAIK, O_NONBLOCK doesn't define the behavior of each ioctl on POSIX
at all.  Some standard POSIX-defined ioctls block even with O_NONBLOCK
indeed.

> Application should 
> change blocking state itself. And non-blocking snd_pcm_drain() still makes 
> sense - it will return state of stream (-EAGAIN - unfinished) or reset PCM 
> state to SETUP in case when all data are played.

Well, this can be kept as is, but it's a bit weird (and silly)
behavior.  Anyway, we'll need fix this bug in our own codes in
alsa-utils first :)


Takashi

Bug#450805: [alsa-devel] [Pkg-alsa-devel] Bug#450805: alsa-tools-gui: hdspmixer initializes only first Hammerfall DSP card

[Takashi Iwai]

At Tue, 13 Nov 2007 19:56:00 +0100,
Elimar Riesebieter wrote:
> 
> forwarded 450805 [EMAIL PROTECTED]
> tags 450805 pending patch

Yes, the patch looks useful.  Now applied to ALSA HG tree.
Thanks!


Takashi

> 
> Thanks
> 
> Hi ALSA developers,
> 
> does it make sense to apply the patch to HEAD? I don't have a
> Hammerfall handy and can not test it.
> 
> Thanks for cooperation.
> 
> Elimar
> 
> 
> On Sun, 11 Nov 2007 the mental interface of
> Frank Heckenbach told:
> 
> Package: alsa-tools-gui
> Version: 1.0.13-1
> Severity: normal
> Tags: patch
> 
> 
> We are using Hammerfall DSP cards. After booting, their audio output
> remains silent until hdspmixer is started. No interaction in the GUI
> of hdspmixer is necessary to unmute the first HDSP card; however,
> further cards are only unmuted when activating the respective GUI
> page ("2", "3"). Apparently, hdspmixer does some automatic
> initialization of the card when activating the page.
> 
> Since we'd like to have a fully automatic startup, the following
> patch activates the page for each existing card on startup, thereby
> initializing them. There are surely more elegant solutions, but this
> patch is tested and solves the problem for us.
> 
> --- alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.h.orig  
> 2007-04-16 19:49:22.0 +0200
> +++ alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.h   2007-04-16 
> 19:50:51.0 +0200
> @@ -37,6 +37,7 @@
>  int card;
>  HDSPMixerWindow *basew;
>  HDSPMixerCardSelector(int x, int y, int w, int h, int card);
> +void ActivateCard (int i);
>  void draw();
>  int handle(int e);
>  };
> --- alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.cxx.orig
> 2007-04-16 19:49:23.0 +0200
> +++ alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.cxx 2007-04-16 
> 19:53:45.0 +0200
> @@ -45,27 +45,25 @@
>  }
>  }
>  
> +void HDSPMixerCardSelector::ActivateCard (int i)
> +{
> +  card = i + 1;
> +  basew->current_card = i;
> +  basew->cards[i]->setMode (basew->cards[i]->getSpeed ());
> +  redraw ();
> +}
> +
>  int HDSPMixerCardSelector::handle(int e)
>  {
>  int xpos = Fl::event_x()-x();
>  switch (e) {
>   case FL_PUSH:
> - if (xpos < 13 && card != 1) {
> - card = 1;
> - basew->current_card = 0;
> - basew->cards[0]->setMode(basew->cards[0]->getSpeed());
> - redraw();
> - } else if (xpos >= 24 && xpos < 37 && card != 2 && basew->cards[1] 
> != NULL) {
> - card = 2;
> - basew->current_card = 1;
> - basew->cards[1]->setMode(basew->cards[1]->getSpeed());
> - redraw();
> - } else if (xpos >= 48 && card != 3 && basew->cards[2] != NULL) {
> - card = 3;
> - basew->current_card = 2;
> - basew->cards[2]->setMode(basew->cards[2]->getSpeed());
> - redraw();
> - }
> + if (xpos < 13 && card != 1)
> +   ActivateCard (0);
> + else if (xpos >= 24 && xpos < 37 && card != 2 && basew->cards[1] != 
> NULL)
> +   ActivateCard (1);
> + else if (xpos >= 48 && card != 3 && basew->cards[2] != NULL)
> +   ActivateCard (2);
>   return 1;
>   default:
>   return Fl_Widget::handle(e);
> --- alsa-tools-1.0.13/hdspmixer/src/HDSPMixerWindow.cxx.orig  2007-04-16 
> 19:41:21.0 +0200
> +++ alsa-tools-1.0.13/hdspmixer/src/HDSPMixerWindow.cxx   2007-04-16 
> 19:55:13.0 +0200
> @@ -700,6 +701,9 @@
>  Fl::atclose = atclose_cb;
>  Fl::add_handler(handler_cb);
>  Fl::add_timeout(0.030, readregisters_cb, this);
> +i = 0;
> +while (cards[i] != NULL)
> +  inputs->buttons->cardselector->ActivateCard (i++);
>  }
>  
>  int HDSPMixerWindow::handle(int e) 
> 
> -- 
>   Experience is something you don't get until 
>   just after you need it!
> ___
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#429326: [alsa-devel] [Pkg-alsa-devel] Bug#429326: Bug#437827: libasound2: Sound creaks badly when playing DVDs or OGG files

[Takashi Iwai]

At Sun, 14 Oct 2007 23:37:58 +0200,
Elimar Riesebieter wrote:
> 
> forwarded 429326 [EMAIL PROTECTED]
> 
> thanks
> 
> On Sun, 14 Oct 2007 the mental interface of
> Loïc Minier told:
> 
> > On Sun, Oct 14, 2007, Elimar Riesebieter wrote:
> > > From my point of view it is not reasonable to patch Debian packages,
> > > which of course will break 32bit only sound cards. So we've to find
> > > a way to force a solution directly on alsa-devel. Who will forward
> > > the _Debian_bug to [EMAIL PROTECTED] ?
> > 
> >  I don't understand your remark about patching the Debian package?  Why
> >  would reverting the bit shift macros break anything?
> > 
> >  The attached patch for alsa-lib should be enough to fix this, upstream
> >  should revert the broken change in the bit shifts.
> 
> Yeah, we can provide it. But shouldn't it be a solution for all ALSA
> users?
> 
> This is Debian #429326. As well reported as
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3360.
> 
> We have to look for a general solution as the distributors don't
> need to patch sources.

Hm, basically the possible overflow is only the case for 32 -> any bit
down conversion, right?  Then let's keep shift_down() for other
conversions, at least.  It's good for sound quality.

We can add a check in shift_down() for 32bit version to not to add if
it's greater or equal (1<<31) - (1<<(bits-1)) - 1 although I'm not
sure whether it's worth to try...


Takashi

> > Alsa #3360; GNOME #436192; LP #116990; Mandriva #33908; Revert HG r2264
> > (changeset 23c4c0f5de40) as the bit shifts overflow when the volume is high
> > for 32 bits to 16 bits resampling
> > 
> > diff -r 23c4c0f5de40 -r 883ae69471d2 src/pcm/plugin_ops.h
> > --- a/src/pcm/plugin_ops.h  Fri Mar 09 17:06:23 2007 +0100
> > +++ b/src/pcm/plugin_ops.h  Fri Mar 09 15:30:38 2007 +0100
> > @@ -85,8 +85,6 @@ static inline u_int32_t sx24s(u_int32_t 
> >  #define _put_triple(ptr,val) _put_triple_be(ptr,val)
> >  #define _put_triple_s(ptr,val) _put_triple_le(ptr,val)
> >  #endif
> > -
> > -#define shift_down(val, bits) (((val) + (1 << ((bits) - 1))) >> (bits))
> >  
> >  #ifdef COPY_LABELS
> >  static void *copy_labels[5] = {
> > @@ -258,14 +256,14 @@ conv_xxx1_009x: as_u32(dst) = sx24s((u_i
> >  conv_xxx1_009x: as_u32(dst) = sx24s((u_int32_t)(as_u8c(src) ^ 0x80) << 8); 
> > goto CONV_END;
> >  conv_xxx1_9000: as_u32(dst) = (u_int32_t)(as_u8c(src) ^ 0x80) << 24; goto 
> > CONV_END;
> >  conv_xxx1_0009: as_u32(dst) = (u_int32_t)(as_u8c(src) ^ 0x80); goto 
> > CONV_END;
> > -conv_xx12_xxx1: as_u8(dst) = shift_down(as_u16c(src), 8); goto CONV_END;
> > +conv_xx12_xxx1: as_u8(dst) = as_u16c(src) >> 8; goto CONV_END;
> >  conv_xx12_xx12: as_u16(dst) = as_u16c(src); goto CONV_END;
> >  conv_xx12_xx21: as_u16(dst) = bswap_16(as_u16c(src)); goto CONV_END;
> >  conv_xx12_x120: as_u32(dst) = sx24((u_int32_t)as_u16c(src) << 8); goto 
> > CONV_END;
> >  conv_xx12_021x: as_u32(dst) = sx24s((u_int32_t)bswap_16(as_u16c(src)) << 
> > 8); goto CONV_END;
> >  conv_xx12_1200: as_u32(dst) = (u_int32_t)as_u16c(src) << 16; goto CONV_END;
> >  conv_xx12_0021: as_u32(dst) = (u_int32_t)bswap_16(as_u16c(src)); goto 
> > CONV_END;
> > -conv_xx12_xxx9: as_u8(dst) = shift_down(as_u16c(src), 8) ^ 0x80; goto 
> > CONV_END;
> > +conv_xx12_xxx9: as_u8(dst) = (as_u16c(src) >> 8) ^ 0x80; goto CONV_END;
> >  conv_xx12_xx92: as_u16(dst) = as_u16c(src) ^ 0x8000; goto CONV_END;
> >  conv_xx12_xx29: as_u16(dst) = bswap_16(as_u16c(src)) ^ 0x80; goto CONV_END;
> >  conv_xx12_x920: as_u32(dst) = sx24((u_int32_t)(as_u16c(src) ^ 0x8000) << 
> > 8); goto CONV_END;
> > @@ -284,57 +282,57 @@ conv_xx12_01Ax: as_u32(dst) = sx24s((u_i
> >  conv_xx12_01Ax: as_u32(dst) = sx24s((u_int32_t)(as_u16c(src) ^ 0x80) << 
> > 8); goto CONV_END;
> >  conv_xx12_A100: as_u32(dst) = (u_int32_t)bswap_16(as_u16c(src) ^ 0x80) << 
> > 16; goto CONV_END;
> >  conv_xx12_001A: as_u32(dst) = (u_int32_t)(as_u16c(src) ^ 0x80); goto 
> > CONV_END;
> > -conv_x123_xxx1: as_u8(dst) = shift_down(as_u32c(src), 16); goto CONV_END;
> > -conv_x123_xx12: as_u16(dst) = shift_down(as_u32c(src), 8); goto CONV_END;
> > -conv_x123_xx21: as_u16(dst) = bswap_16(shift_down(as_u32c(src), 8)); goto 
> > CONV_END;
> > +conv_x123_xxx1: as_u8(dst) = as_u32c(src) >> 16; goto CONV_END;
> > +conv_x123_xx12: as_u16(dst) = as_u32c(src) >> 8; goto CONV_END;
> > +conv_x123_xx21: as_u16(dst) = bswap_16(as_u32c(src) >> 8); goto CONV_END;
> >  conv_x123_x123: as_u32(dst) = sx24(as_u32c(src)); goto CONV_END;
> >  conv_x123_321x: as_u32(dst) = sx24s(bswap_32(as_u32c(src))); goto CONV_END;
> >  conv_x123_1230: as_u32(dst) = as_u32c(src) << 8; goto CONV_END;
> > -conv_x123_0321: as_u32(dst) = shift_down(bswap_32(as_u32c(src)), 8); goto 
> > CONV_END;
> > - conv_x123_xxx9: as_u8(dst) = shift_down(as_u32c(src), 16) ^ 0x80; goto 
> > CONV_END;
> > -conv_x123_xx92: as_u16(dst) = shift_down(as_u32c(src), 8) ^ 0x8000; goto 
> > CONV_END;
> > -conv_x123_xx29: as_u16(dst) = bswap_16(shift_down(as_u32c(src), 8)) ^ 
> 

Bug#438118: [alsa-devel] [Pkg-alsa-devel] Bug#438118: alsa-utils: aplay non-blocking mode isn't working

[Takashi Iwai]

At Thu, 27 Sep 2007 14:16:29 +0200 (CEST),
Anders Boström wrote:
> 
> >>>>> "TI" == Takashi Iwai <[EMAIL PROTECTED]> writes:
> 
>  TI> At Tue, 18 Sep 2007 09:41:48 +0200 (CEST),
>  TI> Anders Boström wrote:
>  >> 
>  >> >>>>> "TI" == Takashi Iwai <[EMAIL PROTECTED]> writes:
>  >> 
>  >> >> can one please have a lokk at this? aplay -N isn't working for the
>  >> >> OP.
>  >> 
>  TI> Cannot reproduce here.  Could you _post_ more details?
>  >> 
>  >> OK, I've tested more, and discovered that the problem seems to be that
>  >> the end of the sound is cut in non-blocking mode. And if I play a very
>  >> short sound-file, I can't hear anything. Blocking mode works fine.
>  >> 
>  >> When using non-blocking mode, an strace contains "ioctl(4, 0x4144,
>  >> 0x2b9f785d8000)= -1 EAGAIN (Resource temporarily
>  >> unavailable)". Blocking mode never contains the EAGAIN response.
>  >> 
>  >> I attach two files. When playing halt.au, I can only hear the start,
>  >> about as much as "ha". When playing metal.au, I can't hear anything.
> 
>  TI> OK, thanks, I see the problem now.
> 
>  TI> I don't remember whether it's a feature or a bug.  The drain ioctl
>  TI> rejects the non-block mode.
> 
> I can understand the idea here, that in non-blocking mode, no call
> should block, ever. But on the other hand, if you call the drain
> ioctl, you probably expect it to work, even in non-blocking mode. Why
> would you otherwise call it?

Yes, that's my opinion, too.  This particular ioctl is to block the
operation, so it should be allowed as long as it's called.

But I vaguely remember that we discussed about it, and the current
form is the result of that.  Namely, we can call
snd_pcm_nonblock(FALSE) explicitly before calling snd_pcm_drain().

Though, I prefer fixing the behavior in the core side to allow the
blocking with this call...  Any reasonable objections in mind?


Takashi

Bug#436502: [alsa-devel] [Pkg-alsa-devel] Bug#436502: alsa-tools -> usx2yloader

[Takashi Iwai]

At Mon, 17 Sep 2007 17:17:29 +0200,
I wrote:
> 
> At Thu, 13 Sep 2007 02:23:36 -0600,
> Michael Bourgeous wrote:
> > 
> > On 9/12/07, Elimar Riesebieter <[EMAIL PROTECTED]> wrote:
> > >
> > > Attached is a patch for the Makefiles and an udev rule which should
> > > work anyway. I don't have TASCAM US-122 usb hardware handy, so
> > > I would be very pleased if someone could test it.
> > >
> > > Thanks
> > >
> > > Elimar
> > >
> > 
> > I can't remember for sure, but the included rules file might have
> > problems loading the us428control program.  I think there might have
> > been problems I encountered with using the tascam_fpga script directly
> > from udev, since us428control doesn't self-daemonize.  I'll attach the
> > .rules file that I use, which might be useful as an example to fix the
> > .rules file provided already if it's found that there are problems
> > with udev and the existing tascam_fpga script.  As I recall, since
> > us428control was still holding on to its stdout, udev would hang and
> > not load any devices after the US-428.
> > 
> > A better option might be a patch to us428control to add a daemonize
> > switch (which, of course, could be as simple as fclose()-ing stdin,
> > stdout, and stderr, and dealing with any I/O functions accordingly).
> 
> Yeah, I'll add the daemonize option soon.  (The patch is already on my
> local tree but I forgot my laptop at home :)

... or an easy solution would be to use startproc (or start_daemon) to
wrap us428control.  And you can call killproc for ACTION=="remove",
too.

Anyway, an untested patch is below.


Takashi

diff -r e82775d19938 us428control/us428control.cc
--- a/us428control/us428control.cc  Mon Jun 04 15:16:24 2007 +0200
+++ b/us428control/us428control.cc  Tue Sep 18 17:42:19 2007 +0200
@@ -63,9 +63,16 @@ static void usage(void)
 {
printf("Tascam US-428 Control\n");
printf("version %s\n", VERSION);
-   printf("usage: "PROGNAME" [-v verbosity_level 0..2] [-c card] [-D 
device] [-u usb-device] [-m mode]\n");
-   printf("mode is one of (us224, us428, mixxx)\n");
-}
+   fputs("usage: "PROGNAME" [-options]\n"
+ "   -v levelspecify verbosity level (0..2)\n"
+ "   -c card specify card number\n"
+ "   -D device   specify device string\n"
+ "   -u device   specify USB device name\n"
+ "   -m mode specify running mode: us224, us428, or mixxx\n"
+ "   -d  daemonize\n",
+ stdout);
+}
+
 /*
  * check the name id of the given hwdep handle
  */
@@ -86,7 +93,34 @@ static int check_hwinfo(snd_hwdep_t *hw,
return 0; /* ok */
 }
 
-int US428Control(const char* DevName, int mode, int y)
+static void daemonize(void)
+{
+   pid_t pid, sid;
+
+   if (getppid() == 1)
+   return; /* already a daemon */
+
+   pid = fork();
+   if (pid < 0)
+   exit(1);
+   if (pid > 0)
+   exit(0);
+
+   umask(0);
+   sid = setsid();
+   if (sid < 0)
+   exit(1);
+
+   if (chdir("/") < 0)
+   exit(1);
+
+   /* Redirect standard files to /dev/null */
+   freopen("/dev/null", "r", stdin);
+   freopen("/dev/null", "w", stdout);
+   freopen("/dev/null", "w", stderr);
+}
+
+static int US428Control(const char* DevName, int mode, int y, int to_daemon)
 {
snd_hwdep_t *hw;
int err;
@@ -109,6 +143,9 @@ int US428Control(const char* DevName, in
 
if (verbose > 0)
fprintf(stderr, PROGNAME ": US-X2Y-compatible card found on 
hwdep %s\n", DevName);
+
+   if (to_daemon)
+   daemonize();
 
Midi.CreatePorts();
 
@@ -167,14 +204,18 @@ int main (int argc, char *argv[])
int y = 8;
int mode = 0;
int card = -1;
+   int to_daemon = 0;
char*device_name = NULL,
*usb_device_name = getenv("DEVICE");
char name[64];
 
-   while ((c = getopt(argc, argv, "c:D:u:v:m:")) != -1) {
+   while ((c = getopt(argc, argv, "cd:D:u:v:m:")) != -1) {
switch (c) {
case 'c':
card = atoi(optarg);
+   break;
+   case 'd':
+   to_daemon = 1;
break;
case 'D':
device_name = optarg;
@@ -214,18 +255,18 @@ int main (int argc, char *argv[])
}
}
if (device_name) {
-   return US428Control(device_name, mode, y) != 0;
+   return US428Control(device_name, mode, y, to_daemon) != 0;
}
if (card >= 0) {
sprintf(name, "hw:%d", card);
-   return US428Control(name, mode, y) != 0;
+   return US428Control(name, mode, y, to_daemon) != 0;
}
 
/* probe the all cards */
for (c = 0; c < SND_CARDS; c++) {
//  verbose-

Bug#438118: [alsa-devel] [Pkg-alsa-devel] Bug#438118: alsa-utils: aplay non-blocking mode isn't working

[Takashi Iwai]

At Tue, 18 Sep 2007 09:41:48 +0200 (CEST),
Anders Boström wrote:
> 
> >>>>> "TI" == Takashi Iwai <[EMAIL PROTECTED]> writes:
> 
> Hi!
> 
>  >> Hi all,
>  >> 
>  >> can one please have a lokk at this? aplay -N isn't working for the
>  >> OP.
> 
>  TI> Cannot reproduce here.  Could you _post_ more details?
> 
> OK, I've tested more, and discovered that the problem seems to be that
> the end of the sound is cut in non-blocking mode. And if I play a very
> short sound-file, I can't hear anything. Blocking mode works fine.
> 
> When using non-blocking mode, an strace contains "ioctl(4, 0x4144,
> 0x2b9f785d8000)= -1 EAGAIN (Resource temporarily
> unavailable)". Blocking mode never contains the EAGAIN response.
> 
> I attach two files. When playing halt.au, I can only hear the start,
> about as much as "ha". When playing metal.au, I can't hear anything.

OK, thanks, I see the problem now.

I don't remember whether it's a feature or a bug.  The drain ioctl
rejects the non-block mode.

Anyway, a simple patch is below.  Let me know if it works.


Takashi

diff -r 0028e39ead78 core/pcm_native.c
--- a/core/pcm_native.c Tue Sep 18 00:52:38 2007 +0200
+++ b/core/pcm_native.c Tue Sep 18 17:44:31 2007 +0200
@@ -1368,8 +1368,6 @@ static int snd_pcm_prepare(struct snd_pc
 
 static int snd_pcm_pre_drain_init(struct snd_pcm_substream *substream, int 
state)
 {
-   if (substream->f_flags & O_NONBLOCK)
-   return -EAGAIN;
substream->runtime->trigger_master = substream;
return 0;
 }

Bug#438118: [alsa-devel] [Pkg-alsa-devel] Bug#438118: alsa-utils: aplay non-blocking mode isn't working

[Takashi Iwai]

At Tue, 11 Sep 2007 18:08:11 +0200,
Elimar Riesebieter wrote:
> 
> forwarded 438118 [EMAIL PROTECTED]
> 
> stop
> 
> Hi all,
> 
> can one please have a lokk at this? aplay -N isn't working for the
> OP.

Cannot reproduce here.  Could you _post_ more details?


thanks,

Takashi


> On Thu, 16 Aug 2007 the mental interface of
> Anders Boström told:
> 
> > > "ER" == Elimar Riesebieter <[EMAIL PROTECTED]> writes:
> > 
> >  >> strace aplay -N :
> >  >> 
> >  >> ...
> >  >> open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) 
> > = -1 ENOENT (No such file or directory)
> > 
> >  ER> This file is provided by
> >  ER> libasound2-plugins: 
> > /usr/lib/alsa-lib/libasound_module_rate_speexrate.so
> > 
> >  ER> Please install libasound2-plugins and try again.
> > 
> > Thanks for the suggestion.
> > 
> > Unfortunately, it didn't solve my problem, no sound when non-blocking
> > mode is used. New strace:
> > 
> > strace aplay -N :
> > ...
> > open("/usr/lib/alsa-lib/libasound_module_rate_speexrate.so", O_RDONLY) = 5
> > read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\22\0"..., 832) = 
> > 832
> > fstat(5, {st_mode=S_IFREG|0644, st_size=20848, ...}) = 0
> > mmap(NULL, 2116136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
> > 0x2b9f792fe000
> > mprotect(0x2b9f79302000, 2097152, PROT_NONE) = 0
> > mmap(0x2b9f79502000, 4096, PROT_READ|PROT_WRITE, 
> > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x4000) = 0x2b9f79502000
> > close(5)= 0
> > ioctl(4, 0xc2604110, 0x7fff3269dec0)= 0
> > ioctl(4, 0xc2604110, 0x7fff3269dec0)= 0
> > ioctl(4, 0xc2604110, 0x7fff3269de00)= 0
> > ioctl(4, 0xc2604110, 0x7fff3269de00)= 0
> > ioctl(4, 0xc2604110, 0x7fff3269ddd0)= 0
> > ioctl(4, 0xc2604110, 0x7fff3269ddc0)= 0
> > ioctl(4, 0xc2604111, 0x7fff3269ddc0)= 0
> > ioctl(4, 0xc0884113, 0x7fff3269dd10)= 0
> > ioctl(4, 0x80184132, 0x7fff3269dc70)= 0
> > mmap(NULL, 49152, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x2b9f79503000
> > ioctl(4, 0xc0884113, 0x624e88)  = 0
> > ioctl(4, 0x4140, 0) = 0
> > ioctl(4, 0xc0884113, 0x624e88)  = 0
> > read(3, "\377eO\333\337\370\344}\335_\377\330^l\356\361`j\336_l"..., 1001) 
> > = 1001
> > read(3, "n{u^\342zl~e~_[\365_y\362_\363\350\337n[\347nmi`\367y\344"..., 
> > 604) = 604
> > ioctl(4, 0x4144, 0x2b9f785d8000)= -1 EAGAIN (Resource temporarily 
> > unavailable)
> > close(3)= 0
> > ioctl(4, 0x4143, 0x3)   = 0
> > munmap(0x2b9f79503000, 49152)   = 0
> > ioctl(4, 0x4112, 0) = 0
> > close(4)= 0
> > munmap(0x2b9f785d7000, 4096)= 0
> > munmap(0x2b9f785d8000, 4096)= 0
> > munmap(0x2b9f792fe000, 2116136) = 0
> > exit_group(0)   = ?
> 
> I have no idea, so forwarded to alsa-dev then.
> 
> THX in advance
> 
> Elimar
> 
> 
> -- 
>   Experience is something you don't get until 
>   just after you need it!

Bug#436502: [alsa-devel] [Pkg-alsa-devel] Bug#436502: alsa-tools -> usx2yloader

[Takashi Iwai]

At Thu, 13 Sep 2007 02:23:36 -0600,
Michael Bourgeous wrote:
> 
> On 9/12/07, Elimar Riesebieter <[EMAIL PROTECTED]> wrote:
> >
> > Attached is a patch for the Makefiles and an udev rule which should
> > work anyway. I don't have TASCAM US-122 usb hardware handy, so
> > I would be very pleased if someone could test it.
> >
> > Thanks
> >
> > Elimar
> >
> 
> I can't remember for sure, but the included rules file might have
> problems loading the us428control program.  I think there might have
> been problems I encountered with using the tascam_fpga script directly
> from udev, since us428control doesn't self-daemonize.  I'll attach the
> .rules file that I use, which might be useful as an example to fix the
> .rules file provided already if it's found that there are problems
> with udev and the existing tascam_fpga script.  As I recall, since
> us428control was still holding on to its stdout, udev would hang and
> not load any devices after the US-428.
> 
> A better option might be a patch to us428control to add a daemonize
> switch (which, of course, could be as simple as fclose()-ing stdin,
> stdout, and stderr, and dealing with any I/O functions accordingly).

Yeah, I'll add the daemonize option soon.  (The patch is already on my
local tree but I forgot my laptop at home :)


Takashi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#436330: vkeybd: FTBFS: error: linux/awe_voice.h: No such file or directory

[Takashi Iwai]

At Tue, 07 Aug 2007 11:21:58 +0100,
Daniel James wrote:
> 
> Hi Lucas,
> 
> > During a rebuild of all packages in sid, your package failed to build on 
> > i386.
> 
> > oper_awe.c: In function 'seq_open':
> > oper_awe.c:146: error: 'SAMPLE_TYPE_AWE32' undeclared (first use in this 
> > function)
> 
> In the Makefile from the original source package, it says:
> 
> # device selections -- multiple avaialble
> # to disable the device, set value 0 (do not comment out!)
> #
> USE_AWE = 1
> 
> I believe this relates to proprietary sequencer support for the 
> seriously obsolete Sound Blaster AWE32 ISA sound card, dating from 1994:
> 
> http://en.wikipedia.org/wiki/Sound_Blaster_AWE32
> 
> According to the oldest entry on this changelog:
> 
> http://packages.debian.org/changelogs/pool/main/v/vkeybd/vkeybd_0.1.17a-2/changelog
> 
> vkeybd was split from the awe package, which was removed from sid in 
> 2002, along with the OSS kernel drivers.
> 
> Although the AWE32 is supported by ALSA now, I think it's quite safe to 
> change the Makefile to read USE_AWE=0 and update the description of the 
> package to remove the reference to AWE32 support.
> 
> The alternative would be to make the linux-source-2.6.* package a build 
> dependency of this vkeybd package; I don't know if that's acceptable in 
> Debian policy terms. It would keep the retro sound hardware enthusiasts 
> happy :-)

FYI, the fixed package 1.0.17b was already released...


Takashi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#430833: [alsa-devel] [Pkg-alsa-devel] Bug#430833: libasound2: PCM plugin `lfloat' not built

[Takashi Iwai]

At Wed, 27 Jun 2007 22:16:00 +0200,
Elimar Riesebieter wrote:
> 
> forwarded 430833 [EMAIL PROTECTED]
> 
> -- 
> 
> On Wed, 27 Jun 2007 the mental interface of
> Mark Wooding told:
> 
> > Package: libasound2
> > Version: 1.0.14a-1
> > Severity: normal
> > Tags: patch
> > 
> > The PCM plugin `lfloat' isn't compiled into libasound.  In particular,
> > this prevents the `plug' plugin from doing linear<->float conversion,
> > and in turn this means that hardly any ALSA clients can use the JACK
> > plugin from libasound2-plugins, because JACK uses FLOAT_LE format
> > throughout.
> > 
> > The reason for this is quite simple: the configure script is broken!  In
> > particular, the sense of the `softfloat' check used to decide whether to
> > disable the plugin is wrong!  (That's aside from the question of whether
> > it's sensible to fail to build the thing just because it might be slow.)
> > 
> 
> We should solve this in general. It's not a Debian specific wish so
> forwarded upstream.

Yep, now committed to ALSA HG tree.

Thanks!


Takashi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#319789: [Alsa-devel] via82C686 MPU detection problem

[Takashi Iwai]

At Tue, 1 Nov 2005 15:06:05 +0900,
Horms wrote:
> 
> Hi Vincent,
> 
> sorry for the inaction on this problem for so long. I breifly played
> around with on my via box, but the sound chip is the older
> VT8233/A/8235/8237, so I don't get anywhere. I'm forwarding it to the
> alsa maintainers for consideration, I suspect its just a problem of
> identifying your card.

MPU401 on VT823x isn't supported by via82xx driver.
Use snd-mpu401 driver separately.


Takashi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]