Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262393AbVADWvD (ORCPT ); Tue, 4 Jan 2005 17:51:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261732AbVADWuU (ORCPT ); Tue, 4 Jan 2005 17:50:20 -0500 Received: from dfw-gate4.raytheon.com ([199.46.199.233]:35224 "EHLO dfw-gate4.raytheon.com") by vger.kernel.org with ESMTP id S262417AbVADWr6 (ORCPT ); Tue, 4 Jan 2005 17:47:58 -0500 Subject: Re: 2.6.10-mm1: ALSA ac97 compile error with CONFIG_PM=n To: Adrian Bunk Cc: Andrew Morton , alsa-devel@alsa-project.org, Adrian Bunk , lkml , perex@suse.cz, Takashi Iwai X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Mark_H_Johnson@raytheon.com Date: Tue, 4 Jan 2005 13:25:40 -0600 X-MIMETrack: Serialize by Router on RTSHOU-DS01/RTS/Raytheon/US(Release 6.5.2|June 01, 2004) at 01/04/2005 01:25:50 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=09BBE5ECDFFB089E8f9e8a93df938690918c09BBE5ECDFFB089E" Content-Disposition: inline X-SPAM: 0.00 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7195 Lines: 137 --0__=09BBE5ECDFFB089E8f9e8a93df938690918c09BBE5ECDFFB089E Content-type: text/plain; charset=US-ASCII 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 Mark H Johnson To: Adrian Bunk 01/04/2005 11:01 cc: Mark_H_Johnson@RAYTHEON.COM, Andrew Morton , lkml AM , perex@suse.cz, Takashi Iwai , 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. --0__=09BBE5ECDFFB089E8f9e8a93df938690918c09BBE5ECDFFB089E Content-type: application/octet-stream; name="ac97-fix-nopm.patch" Content-Disposition: attachment; filename="ac97-fix-nopm.patch" Content-transfer-encoding: base64 LS0tIGtlcm5lbC0yLjYuMTBtbTEvc291bmQvcGNpL2FjOTcvYWM5N19jb2RlYy5jLm9yaWcJMjAw NS0wMS0wNCAwNzo0MDoyNy4wMDAwMDAwMDAgLTA2MDAKKysrIGtlcm5lbC0yLjYuMTBtbTEvc291 bmQvcGNpL2FjOTcvYWM5N19jb2RlYy5jCTIwMDUtMDEtMDQgMTA6NDg6MjEuMDAwMDAwMDAwIC0w NjAwCkBAIC0yMjAxLDE4ICsyMjAxLDYgQEAKIH0KIAogCi0jaWZkZWYgQ09ORklHX1BNCi0vKioK LSAqIHNuZF9hYzk3X3N1c3BlbmQgLSBHZW5lcmFsIHN1c3BlbmQgZnVuY3Rpb24gZm9yIEFDOTcg Y29kZWMKLSAqIEBhYzk3OiB0aGUgYWM5NyBpbnN0YW5jZQotICoKLSAqIFN1c3BlbmRzIHRoZSBj b2RlYywgcG93ZXIgZG93biB0aGUgY2hpcC4KLSAqLwotdm9pZCBzbmRfYWM5N19zdXNwZW5kKGFj OTdfdCAqYWM5NykKLXsKLQlzbmRfYWM5N19wb3dlcmRvd24oYWM5Nyk7Ci19Ci0KIC8qCiAgKiBy ZXN0b3JlIGFjOTcgc3RhdHVzCiAgKi8KQEAgLTIyNTMsNiArMjI0MSwxOCBAQAogCX0KIH0KIAor I2lmZGVmIENPTkZJR19QTQorLyoqCisgKiBzbmRfYWM5N19zdXNwZW5kIC0gR2VuZXJhbCBzdXNw ZW5kIGZ1bmN0aW9uIGZvciBBQzk3IGNvZGVjCisgKiBAYWM5NzogdGhlIGFjOTcgaW5zdGFuY2UK KyAqCisgKiBTdXNwZW5kcyB0aGUgY29kZWMsIHBvd2VyIGRvd24gdGhlIGNoaXAuCisgKi8KK3Zv aWQgc25kX2FjOTdfc3VzcGVuZChhYzk3X3QgKmFjOTcpCit7CisJc25kX2FjOTdfcG93ZXJkb3du KGFjOTcpOworfQorCiAvKioKICAqIHNuZF9hYzk3X3Jlc3VtZSAtIEdlbmVyYWwgcmVzdW1lIGZ1 bmN0aW9uIGZvciBBQzk3IGNvZGVjCiAgKiBAYWM5NzogdGhlIGFjOTcgaW5zdGFuY2UK --0__=09BBE5ECDFFB089E8f9e8a93df938690918c09BBE5ECDFFB089E-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/