artsd (kde sound daemon) is broken on current git for my system.

git-bisect reveals the following patch as the culprit:

commit e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e
Author: Stas Sergeev <stsp@aknet.ru>
Date:   Wed May 7 12:39:56 2008 +0200

    pcspkr: fix dependancies

    fix pcspkr dependancies: make the pcspkr platform
    drivers to depend on a platform device, and
    not the other way around.

    Signed-off-by: Stas Sergeev <stsp@aknet.ru>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Dmitry Torokhov <dtor@mail.ru>
    CC: Vojtech Pavlik <vojtech@suse.cz>
    CC: Michael Opdenacker <michael-lists@free-electrons.com>
    [fixed for 2.6.26-rc1 by tiwai]
40454985821df34702be8a65ede4440859b4ab85 M      sound

I've verified that reverting the above patch on current git fixes the
problem.
Here's the output of lscpi on my laptop (hp nx7010)

00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O
Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP
Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2
EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface
Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE
Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
SMBus Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM ...
[ message continues ]

Hello.

cat /proc/asound/cards
I guess you simply got the pc-speaker driver
loaded first and became your primary sound
driver, which is not what you want.
--

[ message continues ]

Hello.

 0 [pcsp           ]: PC-Speaker - pcsp
                      Internal PC-Speaker at port 0x61
 1 [I82801DBICH4   ]: ICH4 - Intel 82801DB-ICH4
                      Intel 82801DB-ICH4 with AD1981B at irq 10
 2 [Modem          ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
yes, that's true. Anyway in this case the sound server crashes with a
signal 6.
Passing -D dsp1 to artsd avoids the crash, but I can't hear sound coming out
from the speakers (this could be my fault, have to investigate a little
bit more).

Kind regards
R
--

[ message continues ]

Hello.

I can't say for sure why does the
crash happen, but what is known is
that you need a very recent alsa-lib
to get pc-speaker working properly.
And  even 1.0.16 is not modern enough
for that. :(
But that's not a big deal.
The attached config is only what's
needed. Put it into /usr/share/alsa/cards
and /etc/alsa/cards and maybe that
will help. There should be already
The easiest solution is
---
options snd-pcsp index=2
---
into /etc/modprobe.conf. It will
then not go ahead of 2 other drivers
of yours.
[ message continues ]

Hello.

With the supplied conf (and without the module option) artsd does not crash
anymore (no sound from pc speaker but that's not an issue, my alsa-lib is
I can confirm that this solved any issue I had with sound, which is now
working properly.

Kind regards,
R
--

[ message continues ]

Hello.

That's rather bad. :( With the proper
config and alsa-lib 1.0.16 it was supposed
to work...
Do the speaker beeps work?
Like those made by
---
echo -e "\a"
---
command.
Have you made sure that everything
is unmuted in alsamixer and the volume
is at maximum?
If everything fails, could you please
try the "nforce_wa=1" option to snd-pcsp?
Your chipset doesn't seem to be nforce,
but who knows, maybe the nforce workaround
Thanks for the info.
--

[ message continues ]

I believe so, but 'till now the speaker is not working.

Will try this ASAP an report.

Kind regards

R

--

[ message continues ]

In alsamixer i see:

Item: PC Speaker [Off]

and I cant' find a way to toggle it.
With kmix I can toggle the mute setting (alsamixer still sees it off), but
no sound comes out from the speaker.
I also tried

echo -e "\a"

without the module loaded (on old kernel), and the speaker is mute.


I tried also this but without success.
R

--

[ message continues ]

[Changed the subject since it's no real regression]

At Tue, 13 May 2008 17:41:21 +0200,

Could you run "alsactl -f somefile store" and show that file?

When snd-pcsp is built, the input pcspkr is excluded.  So, the beep
won't work unless snd-pcsp is loaded and activated.


thanks,

Takashi
--

[ message continues ]

Hello.

I tried this on 2.6.25 where:

roppedisano@poppero1:~$ grep PCSP /boot/config-2.6.25
roppedisano@poppero1:~$

So, if I'm not missing something, I think it should have worked

Kind regards
R
[ message continues ]

At Wed, 14 May 2008 07:35:19 +0200,

You turned off both "Master Playback Switch" and "PC Speaker Playback
Switch" of snd-pcsp driver.  Then it cannot work.

And, since you loaded the sound driver for on-board sound chip, you'll
likely have to adjust the mixer of that driver, too.  The beep can be
hooked to the on-board chip once after initialized.

But I'm wondering why "PC Speaker Playback Switch" and Volume don't
appear in the on-board driver.  Which codec (I suppose it's AC97) on

Weird.  If CONFIG_INPUT_PCSPKR isn't there, the box shouldn't beep at
all.  If it still beeps, it must be a bug...


thanks,

Takashi
--

[ message continues ]

I tried different switch combination with  alsamixer, but no still no
sound from the speaker...
yep.

00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
I can confirm that the box doesn't beep.

Kind regards

R
--

[ message continues ]

Hello.

Both no beeps and no PCM?
Please show us your current full
mixer config again.
Please don't forget to try the
options snd-pcsp nforce_wa=1
With the master volume at maximum?
Then I am almost out of ideas... :(
--

[ message continues ]

If it does not even beep when issuing Ctrl-G on the shell,
you probably need to modprobe pcspkr, if it is not built-in.
(At least this is with kernels a little less
recent than 2.6.25. )
--

[ message continues ]

At Fri, 16 May 2008 15:15:32 +0200 (CEST),

If snd-pcsp module is built, input pcspkr module won't be built...


Takashi
--

[ message continues ]

Previously, with Stas's standalone patch, one was able to switch
between (a) no speaker (b) beep/pcspkr (c) beep/pcspkr and
PCM/snd-pcsp, all by means of modprobe/rmmod.

Now, if pcspkr is deactivated when snd-pcsp is built... I would
not get any tone out of that piece of hardware.
Except if snd-pcsp itself contains beep code, and that would
be sort of redundant when it is already in pcspkr.
--

[ message continues ]

It does contain exactly that -- snd-pcsp also provides the old input 
driver when compiled.

Rene.
--

[ message continues ]

At Fri, 16 May 2008 17:18:36 +0200 (CEST),

Indeed snd-pcsp contains the input pcspkr code.  Yes, it's redundant,
but separating them isn't trivial.


Takashi
--

[ message continues ]

Hello.

But now you can get any such combination
It is redundant only if you _intend_
to use both drivers. But its usually
a bad idea to have multiple drivers
serving the single device simultaneously.
The other way of thinking about it,
is that you simply use a new driver
instead of an old one. The new one
does everything the old one did and
more. Since they can't be built together,
the redundancy is then only in a source
code.
I am not saying it is an ideal solution.
It is not, but for only a single reason -
people who need only beeps, may not
want to have the entire sound subsystem
loaded. So they want pcspkr to be at
least built. But getting these drivers
back together again, suddenly became
very problematic...
--

[ message continues ]

Hello.

I've played a little bit more with alsamixer and finally
managed to get both beep and PCM working;
nforce_wa does not make any difference with my hw.

I noticed that when I run

aplay -D plughw:2,0 /usr/share/sounds/KDE_Logout.wav

 I get a flood of:

[  417.338143] PCSP: playback_ptr inconsistent (4642 4661 18645)
[  417.338196] PCSP: playback_ptr inconsistent (4644 4661 18645)
[  417.338250] PCSP: playback_ptr inconsistent (4646 4661 18645)
[  417.338304] PCSP: playback_ptr inconsistent (4648 4661 18645)
[  417.338360] PCSP: playback_ptr inconsistent (4650 4661 18645)
[  417.338409] PCSP: playback_ptr inconsistent (4652 4661 18645)
[  417.338463] PCSP: playback_ptr inconsistent (4654 4661 18645)
[  417.338518] PCSP: playback_ptr inconsistent (4656 4661 18645)
...

Just in case you're still interested I'll attach the output of

alsactl -f alsactl-f3 store

Kind regards,
R

-- 
Roberto Oppedisano [RO2480-RIPE]
Infracom Network Application                   OSS and LIR Services
Tel. +39 045 8271518   Fax  +39 045 8271499   Cell. +39 348 7419534

[ message continues ]

Hello.

It turns out that the buffer size you
get, is not evenly devided by period size.
18645 % 4661 = 1.
That (wrongly) triggers the warning.
This may very well be an alsa bug, or
may not, but the code in the driver is
handling that properly, so there is no
need for such a verbose warning.

The attached patch shuts down the warning.
Takashi, could you please apply?
[ message continues ]

At Sat, 17 May 2008 19:50:42 +0400,

The right fix would be to add a hw_constraint to align the buffer
size.  The simplest way is to add the following in PCM open callback.

	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);


Takashi
--

[ message continues ]

Hello.

But what does this fix? That's only a
warning, the driver itself doesn't care
at all. The fix you propose, will need
more testing, at least a confirmation
from the reporter. I simply thought this
can't happen. Now you say its a perfectly
sane situation, and then there is nothing
to care about, just shut up the warning.
No?
--

[ message continues ]

At Sun, 18 May 2008 21:32:39 +0400,

Well, judging from your previous comment, I thought that it's no sane
situation for *your* driver.  But if the driver doesn't care in
practice, your fix should be fine.  I'll queue it on my tree. 

thanks,

Takashi
--

[ message continues ]

Hello.

Only by wrongly triggering a warning
that was supposed for the different
Thanks.
--

[ message continues ]

Hello.

Thats simple. Just press 'm' button.
There are also the M letters right
above the percentage value of the
control. That means Mute. By pressing
m, make sure no controls have M but
instead have O (not sure what does O
stand for).
You can also use F1 for help.
--

[ message continues ]