Re: pcsp weirdness/report (yes, even with libasound 1.0.16 revert)

Re: pcsp weirdness/report (yes, even with libasound 1.0.16 revert)

[Stas Sergeev]

Hi.

Andreas Mohr wrote:
> Immediately tried playback, and nothing worked properly.
> Sound is __EXTREMELY__ silent, about 15 times more silent than the
> normal terminal beep.
Sorry for the silly question but...
do you have the Master volume at
maximum?

> insmod with nforce_wa=1, no success either.
nforce_wa is only needed if your
speaker is completely silent otherwise.
So you don't need it.

> Debug output is (val has astonishingly uniform values):
> input: PC Speaker as /class/input/input12
> PCSP: lpj=4012338, min_div=32, res=1
> PCSP: open called
> PCSP: prepare called, size=32768 psize=2048 f=16 f1=16
> PCSP: trigger called
> PCSP: start_playing called
> timer_cnt 32 val 128 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 27 val 111 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 35 val 141 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 28 val 115 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 27 val 111 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 32 val 128 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 36 val 145 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 32 val 130 CUR_DIV 64 chip->treble 0 chip->max_treble 1
> timer_cnt 30 val 123 CUR_DIV 64 chip->treble 0 chip->max_treble 1
Only timer_cnt and val may change.
Others are from the mixer controls.
Well, whatever should change, seems
changing. :)

> BTW, since it has been frequently mentioned that sound device reordering is
> an issue:
> why not make that hard-coded in the driver itself??
I was thinking about that too - I don't
know an answer. Added alsa-devel to CC
because of that question.

> If this is safe to do (setting it to a "max" value or to e.g. 10,
> and all/most ALSA users still evaluate things properly), then one should
> probably do it.
Hopefully someone else can comment on that.

> And mixer controls in gamix are very confusing, too.
> E.g. when clicking on the BaseFRQ enum box, I get _two_ 18643 entries listed.
I've seen this too, but I think this is
a bug in that mixer gui. It doesn't seem
to handle the ENUMERATED values right,
IIRC. alsamixer works right.

> And I'm still not sure (haven't investigated fully)
> why that other setting is called "treble".
Where? In the GUI or in the code?
It shouldn't be called as such in
the GUI, and for the code... well, I
don't know, that was too long ago. :)

> All in all very confusing.
> All I'd want is enable playback, enable standard beep, master playback
> volume and having the base frequency displayed(/changeable).
Could you please see if there are any
problems with alsamixer first? If not,
then the problems are likely in the
mixer you use.

> Oh, and maybe oversampling configuration (how many samples to average,
> for reduced timer load, see e.g.
> http://kerneltrap.org/mailarchive/linux-activists/1993/4/13/29718 ).
They seem to be talking about a simple
downsampling to reduce the data transfer.
I beleive they talk about downsampling in
the player, not in the driver.
You can't reduce the PWM freq. Making it
below 18KHz would just whistle.

> Oh, and why does the code order I/O sequence as
>                         outb_p(chip->val61, 0x61);
>                         outb_p(timer_cnt, 0x42);
>                         outb(chip->val61 ^ 1, 0x61);
> instead of
>                         outb_p(chip->val61, 0x61);
>                         outb(chip->val61 ^ 1, 0x61);
>                         outb_p(timer_cnt, 0x42);
> as mentioned at some other sites? Is there any reason or maybe it just
> doesn't matter?
I think it doesn't matter, and I did
it that way to increase the delays
between the port 0x61 writes. I have
no proof that it helps or hurts.

> Kconfig description should perhaps also be updated to prominently but
> shortly display the fact that this driver provides full playback,
> not just simple beeps (e.g. mention "digital sound driver" or so).
It says something about a "primitive
sound card", but I see no problems
improving the text.

> Thanks a lot for providing a rather important puzzle piece for
> Linux usability!
:)
Ok, the problems should be solved, the
texts should be improved, the users should
upgrade, etc. And in a mean time, the
warning I put there, is hopefully strong
enough. :)
If not, we can always depend that driver
on CONFIG_BROKEN... but I'd like to hear
more opinions about that option.
Hmm, actually, why not? We can always
un-depend it later. Thoughts?

Re: pcsp weirdness/report (yes, even with libasound 1.0.16 revert)

[Andreas Mohr]

Hi,

On Sat, May 17, 2008 at 01:52:53AM +0400, Stas Sergeev wrote:
> Hi.
> 
> Andreas Mohr wrote:
> > Immediately tried playback, and nothing worked properly.
> > Sound is __EXTREMELY__ silent, about 15 times more silent than the
> > normal terminal beep.
> Sorry for the silly question but...
> do you have the Master volume at
> maximum?

Uh, well... NO.

Hold on... well, of course I definitely had, but - I didn't have swvol
configured (as done by your sample asound.conf.gz / .asoundrc).

Now sound is a lot better, but it's still a wee bit too silent
(piezo...).

And of course I don't quite like the fact that I'm burning 50%
user-space on my Athlon!!!
(probably caused by tasklet, and probably by excessive ALSA handling
there as well).
Do we really have to do ALSA housekeeping during every timer cycle??
Not a single standard soundcard does this, it only triggers a sound
interrupt whenever a period elapsed and _then_ calls
snd_pcm_period_elapsed().
Thus I'm strongly suspecting that we're severely overhandling things
here, but I didn't really look into it.

Anyway, 50% user-space is really excessive, I'm quite sure that
configuring my azt3328 card to fire 20000 hardware sequencer timer interrupts
per second burned about 15% CPU (sys) only! (on this very same machine,
and on a drastically older/worse kernel version already, around 2.6.15ish!)
Thus it'd seem we have a lot of overhead in this handler which one
should try to reduce, by trying to find a solution for the locking issue
and by reducing ALSA handling.

> > insmod with nforce_wa=1, no success either.
> nforce_wa is only needed if your
> speaker is completely silent otherwise.
> So you don't need it.

Yup, and with it sound deteriorated, as mentioned in the driver.

> > And mixer controls in gamix are very confusing, too.
> > E.g. when clicking on the BaseFRQ enum box, I get _two_ 18643 entries listed.
> I've seen this too, but I think this is
> a bug in that mixer gui. It doesn't seem
> to handle the ENUMERATED values right,
> IIRC. alsamixer works right.

gamix doesn't seem to handle a whole lot of things right (that's not the
first time that I'm hitting a problem there).
But OTOH all those bazillions of stupid little mixer apps out there
really aren't any better... (rather worse).

> > And I'm still not sure (haven't investigated fully)
> > why that other setting is called "treble".
> Where? In the GUI or in the code?
> It shouldn't be called as such in
> the GUI, and for the code... well, I
> don't know, that was too long ago. :)

Code. It just seemed to me that treble is something entirely different
than the thing used by the driver.

> > Oh, and why does the code order I/O sequence as
> >                         outb_p(chip->val61, 0x61);
> >                         outb_p(timer_cnt, 0x42);
> >                         outb(chip->val61 ^ 1, 0x61);
> > instead of
> >                         outb_p(chip->val61, 0x61);
> >                         outb(chip->val61 ^ 1, 0x61);
> >                         outb_p(timer_cnt, 0x42);
> > as mentioned at some other sites? Is there any reason or maybe it just
> > doesn't matter?
> I think it doesn't matter, and I did
> it that way to increase the delays
> between the port 0x61 writes. I have
> no proof that it helps or hurts.

But that doesn't happen to be the reason for the nforce breakage, right?

For me it works fine either way.

> > Thanks a lot for providing a rather important puzzle piece for
> > Linux usability!
> :)
> Ok, the problems should be solved, the
> texts should be improved, the users should
> upgrade, etc. And in a mean time, the
> warning I put there, is hopefully strong
> enough. :)
> If not, we can always depend that driver
> on CONFIG_BROKEN... but I'd like to hear
> more opinions about that option.
> Hmm, actually, why not? We can always
> un-depend it later. Thoughts?

I'm tending against CONFIG_BROKEN. The driver isn't really broken,
and it doesn't obscure regular speaker use (right?), and fixing of the nagging
usability issues (weird .asoundrc additions required, gamix problems,
high CPU use...) will happen much faster by spitting into the face
of our users, not by going out of their way :)
(since CONFIG_BROKEN would cause the driver to be invisible on pretty much
every standard distro setup)

Thanks,

Andreas Mohr

-- 
GNU/Linux. It's not the software that's free, it's you.

Re: pcsp weirdness/report (yes, even with libasound 1.0.16 revert)

[Stas Sergeev]

Hello.

Andreas Mohr wrote:
> Hold on... well, of course I definitely had, but - I didn't have swvol
> configured (as done by your sample asound.conf.gz / .asoundrc).
Why? Do you have an updated the PC-Speaker.conf
from alsa-lib hg (same that I posted to LKML)?
That should be enough to get softvol working
"out of the box".
But there is a small caveat to that. After
you load the driver module, you won't get
softvol configured immediately. Running the
mixer doesn't help, too. You need to play
some sound, and then softvol gets configured
so you can start mixer and change volume.
I never investigated that, but its an alsa-lib
bug most certainly. Running alsamixer without
playing any sound first, should be sufficient
to get softvol running. If this is what got you
trapped into, then I'll appreciate if you report
that to the right place. :)

> Now sound is a lot better, but it's still a wee bit too silent
> (piezo...).
Of course you can adjust the softvol config
and increase an amplification, but...

> And of course I don't quite like the fact that I'm burning 50%
> user-space on my Athlon!!!
What Athlon?
Have you tried setting the sampling rate
to 18KHz in alsamixer? Does that change
anything?
I am pretty sure there are the unhappy
asound.conf configurations that look
innocent but burns up your whole CPU.
I had them myself while trying to create
a good config for the driver.
Could you please remove all the custom
/etc/asound.conf, .asoundrc etc, and
only use the PC-Speaker.conf of alsa-lib hg?
I was testing that driver since 486DX4 120
(not in alsa version but an OSS), and it
didn't lead to any significant CPU load.

> (probably caused by tasklet,
AFAIK tasklet is a very light-weight technique.
And hopefully it'll be nuked from the driver
soon. :) It is only used once per playback
btw, so shouldn't hurt the CPU load at all.

> and probably by excessive ALSA handling
> there as well).
I suspect the excessive _user-space_ alsa
handling. That's what happened to me a few
times too.

> Do we really have to do ALSA housekeeping during every timer cycle??
There is only a small housekeeping per
every cycle. Most of it is a... well...
a locking mess. :) The rest is to take
the next byte from DMA buffer, write a
timer counter and advance a playback
pointer. Shouldn't be anything more.

> Not a single standard soundcard does this, it only triggers a sound
> interrupt whenever a period elapsed and _then_ calls
> snd_pcm_period_elapsed().
snd_pcm_period_elapsed() should only be
called when the period(s) has elapsed. If
not - its a bug. snd-pcsp is not an exception.

> Thus I'm strongly suspecting that we're severely overhandling things
> here, but I didn't really look into it.
Its rather messy right now because of
the locking stuff. But I don't think it
really does something redundant by mistake.

> Thus it'd seem we have a lot of overhead in this handler which one
If it is really a callback problem, then
perhaps the hrtimer code itself can
generate an overhead. Maybe you can try
an empty callback to check that out.

> gamix doesn't seem to handle a whole lot of things right (that's not the
> first time that I'm hitting a problem there).
Undoubtedly, you have already reported
it to the right people. :)
And I have to report the same problem
about the gnome-volume-control prog...

> Code. It just seemed to me that treble is something entirely different
> than the thing used by the driver.
OK, I'll rename it soon then.
Or you can do that yourself. :)

>>> Oh, and why does the code order I/O sequence as
>>>                         outb_p(chip->val61, 0x61);
>>>                         outb_p(timer_cnt, 0x42);
>>>                         outb(chip->val61 ^ 1, 0x61);
>>> instead of
>>>                         outb_p(chip->val61, 0x61);
>>>                         outb(chip->val61 ^ 1, 0x61);
>>>                         outb_p(timer_cnt, 0x42);
>>> as mentioned at some other sites? Is there any reason or maybe it just
>>> doesn't matter?
>> I think it doesn't matter, and I did
>> it that way to increase the delays
>> between the port 0x61 writes. I have
>> no proof that it helps or hurts.
> But that doesn't happen to be the reason for the nforce breakage, right?
No, and that's exactly what I did when
first heard about an nforce problem.
This was very long ago. I was hoping
an extra delays could help, but they
reportedly did not. I left it though,
but the first _p is of course now redundant.
Now I have the nforces everywhere
(actually, I don't have the non-nforce
boards any more), and I wasn't able to
find the right fix. Also note that all
the old DOS players are broken on nforce
just as well.