Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Mark_H_Johnson]

A follow up on this patch. This fixed my build / module load problem when
using CONFIG_PM=N on my system. The audio worked OK (except as noted
below). Do you want Andrew Morton to pick this up (or will you incorporate
the fix into another ALSA patch)?

I did have some other minor problems during my testing but I have seen
these before. Perhaps one of the ALSA developers could comment on the
correct / incorrect behavior of the audio system. The testing is done on a
Fedora Core 2 system with the 2.6.10-mm1 kernel (with the patch below). Let
me know if you need more information on the system configuration, and
.config.

[1] After system start up & log in, I do the sequence:
  su -
  (password entered)
  system-config-soundcard
  Simple mixer control 'PCM',0
    Capabilities: pvolume pswitch pswitch-joined
    Playback channels: Front Left - Front Right
    Limits: Playback 0 - 31
    Front Left: Playback 23 [74%] [on]
    Front Right: Playback 23 [74%] [on]
  sox: Can't open output file '/dev/dsp': Device or resource busy

At this point, I get the window asking if I heard the sound (I did not). If
I repeat the test after waiting a short period, it eventually succeeds.

I get basically the same error message from latencytest when it says...
  ERROR: open /dev/dsp: Device or resource busy
[even after I had a successful play of the test sound in
system-config-soundcard]

I realize this may be some KDE or GNOME background application hogging the
sound output, but it is extremely annoying since I never had this problem
with the 2.4 kernels I have used. Is that the likely cause or would
something else cause this problem?

[2] When running latencytest (from
http://www.gardena.net/benno/linux/audio/) the sound is not consistent
(like it was on 2.4 with OSS) and occasionally I hear "rapid playback"
where the repeating audio pattern is much faster than it should be. In
addition, the charts generated by latencytest show at least two different
patterns:
  a. The time between write() calls to the audio interface varies from
roughly 1.16 msec to 2.0 msec. If you add code to dump out the durations
you can see it is a sawtooth pattern, some periods it returns too quickly
and some periods it returns too slowly.
  b. The time between write() calls is roughly 1.2 msec. I believe this
behavior occurs at the same time the audio pattern repeats too quickly.
In all cases, the between write() calls should be 1.45 msec (the length of
the audio fragment) as I measured on a consistent basis with 2.4 kernels. I
can somewhat understand the behavior of (a) if the driver is queueing up
audio fragments in the write() call. I do not necessarily agree that the
audio driver should do that but I can understand why it may do that. The
behavior of (b) sounds broken to me.

Let me know if you want to see a copy of the charts - I should be able to
email (or post on an ftp site temporarily) to individuals who want to view
them [and compare with the 2.4 results].

--Mark H Johnson
  <mailto:Mark_H_Johnson@xxxxxxxxxxxx>


                                                                                                                                       
                      Mark H Johnson                                                                                                   
                                               To:      Adrian Bunk <bunk@xxxxxxxxx>                                                   
                      01/04/2005 11:01         cc:      Mark_H_Johnson@xxxxxxxxxxxx, Andrew Morton <akpm@xxxxxxxx>, lkml               
                      AM                       <linux-kernel@xxxxxxxxxxxxxxx>, perex@xxxxxxx, Takashi Iwai <tiwai@xxxxxxx>,            
                                               alsa-devel@xxxxxxxxxxxxxxxx                                                             
                                               Subject: Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n(Document link: Mark   
                                               the Maniac)                                                                             
                                                                                                                                       



>That's not the problem, since function and definition are in the same
>module.
>
>You didn't send your .config, but looking at the code it seems
>CONFIG_PM=n was the culprit.
Yes. CONFIG_PM=N in my .config.

>As a workaround, it should work after enabling the following option:
>  Power management options (ACPI, APM)
>    Power Management support
Hmm. I don't want to do that for my real time testing. I turned that off
to eliminate a class of possible latencies.

>This is only a workaround, I've Cc'ed the ALSA maintainers for a real
>fix.

How about the attached patch instead (which moves the #ifdef CONFIG_PM
and snd_ac97_suspend after the two functions I am having problems with).
Apparently the use of snd_ac97_restore_status and snd_ac97_restore_iec958
is in ac97_patch.c as well as in the power management code. I have not
run the code yet a quick build didn't find any problems with it. I have
a full build / test coming later today.

  --Mark

PS: On the other message you sent related to [add|del]_mtd_partitions
applies with the 2nd hunk failing (that code not present) but the first
hunk makes the build problem I had go away. Thanks.

Attachment: ac97-fix-nopm.patch
Description: Binary data