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

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

[Mark_H_Johnson]

[-- Attachment #1: Type: text/plain, Size: 5410 bytes --]

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@raytheon.com>


                                                                                                                                       
                      Mark H Johnson                                                                                                   
                                               To:      Adrian Bunk <bunk@stusta.de>                                                   
                      01/04/2005 11:01         cc:      Mark_H_Johnson@RAYTHEON.COM, Andrew Morton <akpm@osdl.org>, lkml               
                      AM                       <linux-kernel@vger.kernel.org>, perex@suse.cz, Takashi Iwai <tiwai@suse.de>,            
                                               alsa-devel@alsa-project.org                                                             
                                               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 #2: ac97-fix-nopm.patch --]
[-- Type: application/octet-stream, Size: 849 bytes --]

--- kernel-2.6.10mm1/sound/pci/ac97/ac97_codec.c.orig	2005-01-04 07:40:27.000000000 -0600
+++ kernel-2.6.10mm1/sound/pci/ac97/ac97_codec.c	2005-01-04 10:48:21.000000000 -0600
@@ -2201,18 +2201,6 @@
 }
 
 
-#ifdef CONFIG_PM
-/**
- * snd_ac97_suspend - General suspend function for AC97 codec
- * @ac97: the ac97 instance
- *
- * Suspends the codec, power down the chip.
- */
-void snd_ac97_suspend(ac97_t *ac97)
-{
-	snd_ac97_powerdown(ac97);
-}
-
 /*
  * restore ac97 status
  */
@@ -2253,6 +2241,18 @@
 	}
 }
 
+#ifdef CONFIG_PM
+/**
+ * snd_ac97_suspend - General suspend function for AC97 codec
+ * @ac97: the ac97 instance
+ *
+ * Suspends the codec, power down the chip.
+ */
+void snd_ac97_suspend(ac97_t *ac97)
+{
+	snd_ac97_powerdown(ac97);
+}
+
 /**
  * snd_ac97_resume - General resume function for AC97 codec
  * @ac97: the ac97 instance

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Takashi Iwai]

At Tue, 4 Jan 2005 13:25:40 -0600,
Mark_H_Johnson@raytheon.com wrote:
> 
> 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)?

It was already fixed in the recent ALSA tree.
So, just syncing bk-alsa patch would suffice.

> 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.

The default blocking behavior of OSS devices was changed recently.
When the device is in use, open returns -EBUSY immediately in the
latest version while it was blocked until released in the former
version.


> [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.

It's hard to tell.  The cause could be in the general interrupt
handling, the difference of HZ, the driver's interrupt setting, or
whatever.  This must depend on the hardware, anyway.


Takashi

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Andrew Morton]

Takashi Iwai <tiwai@suse.de> wrote:
>
> The default blocking behavior of OSS devices was changed recently.
>  When the device is in use, open returns -EBUSY immediately in the
>  latest version while it was blocked until released in the former
>  version.
> 

whoa.  That's a significant change in user-visible behaviour.  Why was this
done?

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Lee Revell]

On Wed, 2005-01-05 at 13:27 -0800, Andrew Morton wrote:
> Takashi Iwai <tiwai@suse.de> wrote:
> >
> > The default blocking behavior of OSS devices was changed recently.
> >  When the device is in use, open returns -EBUSY immediately in the
> >  latest version while it was blocked until released in the former
> >  version.
> > 
> 
> whoa.  That's a significant change in user-visible behaviour.  Why was this
> done?

http://sourceforge.net/mailarchive/message.php?msg_id=10011826

Lee

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Alan Cox]

On Mer, 2005-01-05 at 21:27, Andrew Morton wrote:
> Takashi Iwai <tiwai@suse.de> wrote:
> >
> > The default blocking behavior of OSS devices was changed recently.
> >  When the device is in use, open returns -EBUSY immediately in the
> >  latest version while it was blocked until released in the former
> >  version.
> > 
> 
> whoa.  That's a significant change in user-visible behaviour.  Why was this
> done?

It now emulates the later OSS PCI and other devices not 2.2 OSS. As such
its the right thing to have done for emulation of OSS IMHO. It also
works with more apps several of which hang on opening /dev/dsp0
expecting OSS -EBUSY responses.

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Mark_H_Johnson]

> At Tue, 4 Jan 2005 13:25:40 -0600,
> Mark_H_Johnson@raytheon.com wrote:
> > [snip - how to get to the problem]
> > 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.
>
> The default blocking behavior of OSS devices was changed recently.
> When the device is in use, open returns -EBUSY immediately in the
> latest version while it was blocked until released in the former
> version.
I suppose there was a "good reason" for changing the user level
interface in this way. Could you [or someone else] explain that and
if you would consider changing it back (to stop breaking old applications)?
Otherwise - is there some way (other than running lsmod and grep) to find
out if the interface is busy and which application is using it?

> > [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.
>
> It's hard to tell.  The cause could be in the general interrupt
> handling, the difference of HZ, the driver's interrupt setting, or
> whatever.  This must depend on the hardware, anyway.
Well, to a certain extent, I agree but let me repeat the symptoms
I am seeing [repeated below]
> >   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.
What you describe can certainly explain this first behavior. For example,
if the ALSA code waits for the next clock tick (1 msec resolution)
to return from the write() call, the behavior I see can be explained. I do
not necessarily LIKE this behavior (it makes the analysis of latency and
explanations to other people more difficult) but I understand it and when
this happens - the sound is OK.

> >   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.
This behavior on the other hand does not appear reasonable to me. The
latencytest application writes a series of audio fragments, each 1.45 msec
long.
It should never get an extended period (many seconds) where the loop doing
that
gets done at a 1.2 msec rate. What I hear from the speakers (the rapid
playback) does not sound right either. This looks like a bug to me that
needs to be corrected.

I can generally trigger it by running latencytest while reading (or
copying)
a large disk file with the kernels I have been building. Perhaps a long
latency
(> 1 audio fragment - 1.45 msec) is getting the ALSA code into a "hurry up"
mode
which it never leaves. That would explain the symptom but I certainly don't
know the code good enough to tell if that is feasible (or if something else
is causing the symptom).

--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Alan Cox]

On Mer, 2005-01-05 at 14:21, Mark_H_Johnson@raytheon.com wrote:
> > The default blocking behavior of OSS devices was changed recently.
> > When the device is in use, open returns -EBUSY immediately in the
> > latest version while it was blocked until released in the former
> > version.
> I suppose there was a "good reason" for changing the user level
> interface in this way. Could you [or someone else] explain that and
> if you would consider changing it back (to stop breaking old applications)?
> Otherwise - is there some way (other than running lsmod and grep) to find
> out if the interface is busy and which application is using it?

OSS itself changed behaviour over time (2.2 to 2.4) ALSA has merely
caught up with the newer OSS behaviour and the new behaviour is correct.

If you want to find out if the interface is busy open it. If you want to
do it portably open it with O_NDELAY.

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Lee Revell]

On Wed, 2005-01-05 at 14:56 +0000, Alan Cox wrote:
> On Mer, 2005-01-05 at 14:21, Mark_H_Johnson@raytheon.com wrote:
> > > The default blocking behavior of OSS devices was changed recently.
> > > When the device is in use, open returns -EBUSY immediately in the
> > > latest version while it was blocked until released in the former
> > > version.
> > I suppose there was a "good reason" for changing the user level
> > interface in this way. Could you [or someone else] explain that and
> > if you would consider changing it back (to stop breaking old applications)?
> > Otherwise - is there some way (other than running lsmod and grep) to find
> > out if the interface is busy and which application is using it?
> 
> OSS itself changed behaviour over time (2.2 to 2.4) ALSA has merely
> caught up with the newer OSS behaviour and the new behaviour is correct.
> 
> If you want to find out if the interface is busy open it. If you want to
> do it portably open it with O_NDELAY.
> 

And if you want to find out who is using it then try fuser /dev/dsp,
fuser /dev/snd/*, or lsof.

Lee

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Takashi Iwai]

At Wed, 5 Jan 2005 08:21:20 -0600,
Mark_H_Johnson@raytheon.com wrote:
> 
> > At Tue, 4 Jan 2005 13:25:40 -0600,
> > Mark_H_Johnson@raytheon.com wrote:
> > > [snip - how to get to the problem]
> > > 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.
> >
> > The default blocking behavior of OSS devices was changed recently.
> > When the device is in use, open returns -EBUSY immediately in the
> > latest version while it was blocked until released in the former
> > version.
> I suppose there was a "good reason" for changing the user level
> interface in this way. Could you [or someone else] explain that and
> if you would consider changing it back (to stop breaking old applications)?

It was discussed on alsa-devel in November.  Unfortunately, I can't
find ML archive any longer...

The blocking behavior of OSS is a feature which is nowehre defined.
Some OSS drivers open in the blocking mode and some don't.
So, apps shouldn't depend on this feature.

We had implemented OSS emulation in the blocking manner since we
intepreted the POSIX definition in that way.  But Linus pointed out
that it's a misreading.

BTW, you can enable the blocking mode again via module/boot option.
See OSS-Emulation.txt.


> > > [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.
> >
> > It's hard to tell.  The cause could be in the general interrupt
> > handling, the difference of HZ, the driver's interrupt setting, or
> > whatever.  This must depend on the hardware, anyway.
> Well, to a certain extent, I agree but let me repeat the symptoms
> I am seeing [repeated below]

Please provide the hardware details (I don't see your original post to
lkml).  Otherwise it'll be a vapor discusson...


Takashi

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Lee Revell]

On Wed, 2005-01-05 at 17:49 +0100, Takashi Iwai wrote:
> At Wed, 5 Jan 2005 08:21:20 -0600,
> Mark_H_Johnson@raytheon.com wrote:
> > 
> > > At Tue, 4 Jan 2005 13:25:40 -0600,
> > > Mark_H_Johnson@raytheon.com wrote:
> > > > [snip - how to get to the problem]
> > > > 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.
> > >
> > > The default blocking behavior of OSS devices was changed recently.
> > > When the device is in use, open returns -EBUSY immediately in the
> > > latest version while it was blocked until released in the former
> > > version.
> > I suppose there was a "good reason" for changing the user level
> > interface in this way. Could you [or someone else] explain that and
> > if you would consider changing it back (to stop breaking old applications)?
> 
> It was discussed on alsa-devel in November.  Unfortunately, I can't
> find ML archive any longer...
> 

Heh, if you want the excruciating details, here are some pointers.  It's
a long thread, and unfortunately the threading is a little broken.

Here's a link to the technical part:

http://sourceforge.net/mailarchive/message.php?msg_id=10008900

And here's the rant that started it:

http://sourceforge.net/mailarchive/message.php?msg_id=10014826

Lee

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Mark_H_Johnson]

> At Wed, 5 Jan 2005 08:21:20 -0600,
> Mark_H_Johnson@raytheon.com wrote:
[snip - back & forth on the blocking behavior]
> > I suppose there was a "good reason" for changing the user level
> > interface in this way. Could you [or someone else] explain that and
> > if you would consider changing it back (to stop breaking old
applications)?
>
> It was discussed on alsa-devel in November.  Unfortunately, I can't
> find ML archive any longer...
>
> The blocking behavior of OSS is a feature which is nowehre defined.
> Some OSS drivers open in the blocking mode and some don't.
> So, apps shouldn't depend on this feature.
>
> We had implemented OSS emulation in the blocking manner since we
> intepreted the POSIX definition in that way.  But Linus pointed out
> that it's a misreading.
>
> BTW, you can enable the blocking mode again via module/boot option.
> See OSS-Emulation.txt.
>
Thanks for the explanation and the suggested work around. Thanks
also to Lee Revell for his other suggestion (using fuser). I should
be able to work around this OK for now.

> > > [snip - rehash of symptoms]
> Please provide the hardware details (I don't see your original post to
> lkml).  Otherwise it'll be a vapor discusson...

Details provided separately. Basically it is a two CPU system (866 Mhz
Pentium III) with an Ensoniq sound card. I use this system primarily
for comparative tests of kernels (for RT latency) before moving a
kernel update to other system for more comprehensive tests.

  --Mark

Re: [Alsa-devel] Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n

[Mark_H_Johnson]

> And if you want to find out who is using it then try fuser /dev/dsp,
> fuser /dev/snd/*, or lsof.

Hmm. I figured out which application is "getting in my way" but am not
quite sure why I have a problem opening the audio / what I should do
about it.

On my system...

# fuser /dev/snd/* /dev/dsp
/dev/snd/pcmC0D0p:    2972  2972m
# ps -fe | grep 2972
u21305    2972  2936  0 10:15 ?        00:00:02 artsd -F 10 -S 4096 -a alsa
-s 60 -m artsmessage -c drkonqi -l 3 -f
root      4915  3407  0 11:08 pts/7    00:00:00 grep 2972
# fuser /dev/snd/* /dev/dsp
[I caused a console beep here using backspace]
# fuser /dev/snd/* /dev/dsp
/dev/snd/pcmC0D0p:    2972  2972m

OK, so artsd wakes up on some trigger and then waits around a while
expecting to get some more audio to process. I see it is a user of
/dev/snd/pcmC0D0p but not a user of /dev/dsp. Yet when I attempt to
open /dev/dsp, I get an error.

When I successfully run latencytest (and open /dev/dsp) I see...

# fuser /dev/snd/* /dev/dsp
/dev/dsp:             9156

which is the pid of latencytest.

Can someone please explain the relationship between these devices
and why access to one of these devices prevents access to another?
This is certainly confusing to me.

Thanks.
  --Mark