Re: ICH sound after suspend/resume
/-- Kevin Oberman wrote: | Re: kern/55395 | | I see a patch to ich.c back on the 15th to Correctly reset ich[3-5] | sound cards on resume., but I am still not able to properly use my | sound card after a resume because the card starts clocking at the wrong | rate, about 52K instead of the correct 48,000. | | There is nothing in the tying it to any PR, but it looks like it's | trying to do the right thing on resume. | | As before, the sysctl for the sampling rate has no effect. | | Any ideas what I might try? Kevin All I can suggest is going through the ICH sound docs. Intel write both register descriptions and programmers guide for their h/w. You might also look at the ALSA driver. I believe the speed problem most likely lies in the AC97 resets. I know I promised to look into this, but I've been struck by a shortage of time lately and don't see the situation improving in the near future. I'm very close to calling it a day with the commit bit. - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent sound change still broken?
David Xu wrote: | | I tried to backout ac97.c revision 1.43, now my sound card works again, | If someone wants more information, please tell me. David Could you revert to head and check that the mixer ogain is non-zero (say 100 :-)? On some codecs ogain provides the traditional functionality of vol. I appreciate this is not ideal. Thanks - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent changes to AC97 files breaks sound
/-- Lars Eggert wrote: | This is a cryptographically signed message in MIME format. | | --ms080500030203050209080702 | Content-Type: text/plain; charset=us-ascii; format=flowed | Content-Transfer-Encoding: 7bit | | Hi, | | Rudolf Cejka wrote: | Glenn Johnson wrote (2003/08/21): | | sound no longer works. I reverted to the previous versions of these | files to get sound back. | | I might have the same issue. Does no longer work means silence? Then I | do. (Just got this box, so I don't know whether this was recently broken | or not.) Here's my hardware: | | pcm0: SiS 7012 port 0x9000-0x907f,0x9400-0x94ff irq 15 at device 2.7 | on pci0 | pcm0: Avance Logic ALC650 AC97 Codec | | Could you do ALC650 register dump? If you look into | ftp://ftp.FreeBSD.cz/pub/FreeBSD-local/ich/ , you can see small | how-to in DEBUG sections. | | Would the dump work/help for the SiS chip as well? Lars First off, apologies for the breakage. Before investing any time doing a register dump, can you just check whether your mixer now has an ogain control and that it is non-zero. Thanks - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent changes to AC97 files breaks sound
/-- Kevin Oberman wrote: | From: Orion Hodson [EMAIL PROTECTED] | Date: Fri, 22 Aug 2003 13:38:22 -0700 | Sender: [EMAIL PROTECTED] | | /-- Lars Eggert wrote: | | This is a cryptographically signed message in MIME format. | | | | --ms080500030203050209080702 | | Content-Type: text/plain; charset=us-ascii; format=flowed | | Content-Transfer-Encoding: 7bit | | | | Hi, | | | | Rudolf Cejka wrote: | | Glenn Johnson wrote (2003/08/21): | | | | sound no longer works. I reverted to the previous versions of these | | files to get sound back. | | | | I might have the same issue. Does no longer work means silence? Then I | | do. (Just got this box, so I don't know whether this was recently broken | | or not.) Here's my hardware: | | | | pcm0: SiS 7012 port 0x9000-0x907f,0x9400-0x94ff irq 15 at device 2.7 | | on pci0 | | pcm0: Avance Logic ALC650 AC97 Codec | | | | Could you do ALC650 register dump? If you look into | | ftp://ftp.FreeBSD.cz/pub/FreeBSD-local/ich/ , you can see small | how-to in DEBUG sections. | | | | Would the dump work/help for the SiS chip as well? | | Lars | | First off, apologies for the breakage. Before investing any time doing a | register dump, can you just check whether your mixer now has an ogain contr | ol | and that it is non-zero. | | Yes, ogain (output gain?) has replaced volume and it works fine. (I | think my claim about xmms may have been bogus. Sorry!) Good stuff. This I understand and will correct tomorrow. Thanks - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent changes to AC97 files breaks sound
/-- Lars Eggert wrote: | What's weird is that everything looks like it should be playing - no | weird messages, no jumpy progress bar, etc. I'll double-check my cabling | again. | | One more thing: This board has a bunch of connectors, including regular | analog out and SPDIF. Right now, things are hooked up to the analog - is | it maybe playng out of the SPDIF? (Does that even work yet under FreeBSD?) Thanks for the info. I'm looking at the diff and not seeing what's happened here. I'll have to think some more, check the specs, and get back to you. - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR in pcm
/-- Kris Kennaway wrote: | | LORs in the pcm system are reported quite regularly, but I haven't | seen anyone working on the problem. Is there anyone who can look at | the locking code used in this system and fix the problems? Perhaps | this should be added to the 5.2 TODO list. | =20 I'm unaware of anybody chasing this though I'm not very closely involved with [EMAIL PROTECTED] these days. Last I knew cg was focusing his energies on a new freebsd sound architecture to better cater for modern audio h/w. If somebody was interested in taking this issue on, it would be of immediate benefit to the project. Regards - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Correct PCI suspend and resume operations [ was Re: cirrus ich3 doesn't work after suspend to disk ]
/-- Mark Santcroos wrote: | | I did some checking with pciconf before and after suspend and come up with | the following fix: | | # set nambar | pciconf -w -b pci0:31:5 0x11 0xd8 | # set nabmbar: | pciconf -w -b pci0:31:5 0x14 0x81 | pciconf -w -b pci0:31:5 0x15 0xdc | # set pcicmd: | pciconf -w -b pci0:31:5 0x4 0x5 It looks like the pci configuration space state has been lost during the suspend and resume. This may be because the bus has removed power from the devices attached to it on suspend. I've been through a cross section of drivers this morning and some explicitly save and restore the PCI configuration state space and others don't. The former seems like the safest path in most cases. AFAICT, we don't common code for handling this and maybe there should be some rather than have each driver replicate this behaviour. - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:No sound in -current?
Scott R. writes: | I just updated my system last night around 8 PM PST and today I have no | sound. XMMS says it's playing music and I can see that it thinks it's | playing something, but I am hearing nothing. Same deal with RealPlayer | and every other app I try. No crackles, pops or *anything*. Just dead | silence. Is this a known issue? Sound was working fine with my | previous system from a couple of weeks ago. Scott A fix for this was committed this morning (PST). Please let me know if you experience any audio problems after the next update. Thanks - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AC97 sound problems with current
/-- Scott Long wrote: | Orion Hodson wrote: | There is a calibration step in the driver to determine the clock rate of th | e | AC97 link. What you are seeing is the calibration step failing and setting | a | bogus ac97 link rate. I took a cursory look a couple of weeks back and it | smelt like the timecounter initialization point changed, but haven't gotten | | around to looking closer and fixing the driver. | | If this were true then I'd be very concerned. Let me know what you | find. For what it's worth, my ICH3 setup is still working fine when | loaded at boot, though my kernel is about 2 weeks old. It's definitely nothing to do with the timecounter - quick test on other h/w along similar lines. I don't access to an ich board to test on - it's probably obvious, but I'm not seeing it just now with visual inspection... - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA82c686a sound problem
Fred The via82c686.c code changed this week to implement the cold reset described in the AC97 r2.3 spec since there are some boards where the former initialization does not work. It may be your board is reporting it's ready, but it requires a reset. Can you apply the attached patch to the head version of via82c686.c and let me know if it works on your h/w and what the additional dmesg information is? The patch forces a cold reset and sets an additional enabled bit in the AC97 link control register during the reset (there's not enough info in the spec to know whether this bit should be set during the reset, it works elsewhere). Thanks - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AC97 sound problems with current
Kevin Oberman writes: | | After upgrading my laptop from STABLE to CURRENT on 3/14 I have been | having problems with GnomeMeeting. Often the sound is badly broken with | 'spurts' of sound with silent gaps in between. This was never the case | with STABLE. Other times it's fine. | | When I looked at my dmesg output I noticed some changes between STABLE | and CURRENT for the pcm0 device. Under STABLE I only got two messages: | pcm0: Intel 82801CA (ICH3) port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at device 31.5 on pci0 | pcm0: Analog Devices AD1881A ac97 codec | Under CURRENT I get a third: | | pcm0: measured ac97 link rate at 51200 Hz There is a calibration step in the driver to determine the clock rate of the AC97 link. What you are seeing is the calibration step failing and setting a bogus ac97 link rate. I took a cursory look a couple of weeks back and it smelt like the timecounter initialization point changed, but haven't gotten around to looking closer and fixing the driver. It's on the todo list... I've also been wondering if it's possible to ditch the calibration entirely, but this is an involved AC97 question and I don't have easy access to the relevant h/w and it's a different q. Anyway, whilst it remains broken you can set the ac97 clock rate by hand. The sysctl variable hw.snd.pcmX.ac97rate exists specifically for times when the calibration test fails (X = 0 if no other cards installed). Depending on which clock source is being used by the codec you'll want to set the variable to 48000 or around 55913. YMMV, but kldloading the driver rather than having it compiled into the kernel will probably result in the correct calibration. - Orion ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: audio playback slow
Wade Majors writes: | I just setup FreeBSD 5.0-CURRENT as of last night on my system. I setup | the pcm driver and it detected my onboard VIA audio (at least | partially), however playback is at about half speed. I am basically | running GENERIC with the debug options commented out and device pcm added. | | I suspect it might be because of the AC97 Codec message, but I do get | playback, just slowed down. Wade. The AC97 codec message is unrelated, it's just a missing/mis-entered codec id, it's an ALC101. This should now be fixed in the repository. I believe the speed problem lies with the driver mis-reporting of capabilities of the chipset when the ac97 codec does not support on-chip sample rate conversion which the ALC101 does not. Again, this should now fixed in the repository. If you can update and let me know. Should it fail, can you set 'sysctl hw.snd.verbose=3', 'cat /dev/sndstat' while playing the offending audio, and send me the output. Thanks - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re:Witness problem with sound
Yuriy wrote: | Mar 4 14:56:27 port2 kernel:=20 | /usr/src/sys/vm/uma_core.c:1330: could sleep with | pcm0:play:0 locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 | this problem is in last (1.27-1.28) changes in = | /usr/src/sys/dev/sound/pcm/feeder.c (if I remember correctly) | You can revert to previous version (1.27) if you don't want to see = | witness messages. The code just got reverted. Reverting this code is not ideal, but really a more fundamental fix is required and neither state of the feeder files helps. By reverting the code it'll generate less email, and in the meantime we can hopefully sort out a more fundamental fix. Regards - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound problem: ac97 codec invalid or not present
Hugo Having 'device pcm' in the kernel is all you should need for you VT82C686 (kldload'ing sound drivers requires pcm support not be compiled into the kernel. The are two portions to the sound h/w you have, the pcm component, ie the VT82C686, and the AC97 codec that controls the mixer and routing of the audio within the h/w. The AC97 code does not detect your AC97 codec so you end up with a pcm component with no ac97 mixer. Does you BIOS have an onboard sound setting? If this is not enabled then might explain what you see. Failing that can you post the complete output of dmesg and set 'sysctl hw.snd.verbose=3' and post the output of 'cat '/dev/sndstat'? Thanks - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VIA8235 audio support
The VIA8233/8235 audio driver has undergone another revision in an attempt to provide support for the VIA8235. The code is in -CURRENT as of 5 minutes ago. Several people have reported quiet/inaudible sound on P4 boards with this southbridge. If you have a VIA8235 based board, I'd be interested to know if it works for you as several people have reported quiet/near-silent operation with this chipset and I do not have the relevant h/w. The new code paths are used by the h/w that I do have access to (VIA8233C) so testing this code is low risk: the worst case is no sound :-) If you have a suitable board, but are not running -CURRENT. Let me know what version of FreeBSD you'd like it for and I'll do the relevant work for some small number of requests since I really want to resolve this issue. Thanks - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Asus A7N8X Deluxe, nForce2 chipset, integrated AC97 audio
/-- Mikko S. Hyvarinen wrote: | ... | With this patch the on-board AC97 audio controller and Realtek Semiconductor | ALC650 CODEC work as far as I can test; tested with headphones in line-out | and playing two albums of MP3 audio with mpg123. | ... MSH The patches have been applied to current and will follow to stable in a few days. Cheers - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mutex pcm0:play:0 not owned at ../../../kern/kern_mutex.c:339
/-- Jun Kuriyama wrote: | At Sun, 18 Aug 2002 07:17:07 -0700 (PDT), | Orion Hodson wrote: |Modified files: | sys/dev/sound/pcmdsp.c |Log: |Apply reference counting patch. Fixes problem of two applications |opening the device, eg one read only and one write only, and the |reference count being non-zero when both exit rendering device |permanently busy. | | After this, I got a panic around sound. With r1.54 of dsp.c, it looks | fine. I'll try to deal with this promptly now, if I can't fix it in the next couple of hours (pretty tired now), then I'll back it out. I'm in the process of drafting a note to cg as it would be good to do something about the audio locking warnings. If it doesn't bust his outstanding mixer mega commit I'm interested in fixing this rsn. Thanks - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fast playback with Intel 82801BA (ICH2)
/-- Alfred Perlstein wrote: | -current compiled today mp3s play too fast, any ideas on how to | diagnose this? | | pcm0: Intel 82801BA (ICH2) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device | 31.5 on pci0 | pcm0: measured ac97 link rate at 44061 Hz You can set a sysctl to set the ac97 link rate. I don't recall offhand what it is (hw.snd.pcm0.ac97rate?) - sysctl -a | grep ac97 will find it. There is a calibration test in the ich code since various mfrs do funny things with the clock. I'd be interested to know what boot -v output is and what ac97 link rate works. This is the second box reported failing on this recently. - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Making DMA buffer resizeable depending on audio speed/format
Maxim The sound driver interface provides the application writer the choice to set the buffering they require. This patch has obvious implications for the ordering of ioctl's that we may not want to introduce. I suspect (not insist :-) the two specific fixes you report are caused by: - mss maximum buffer size is too small (4096 bytes ~ 23 ms of CD quality audio). Your patch helps because you increase the default buffering to 16384 bytes. - digger relies on a sound library that does not always set the blocksize (there are paths in the SDL audio code where this is the case, eg esd). Your patch helps because it sets the default buffer size smaller. Increasing the default buffering is certainly an option we should consider. However, any application that wants low latency should talk to the sound device directly and use the existing ioctls to get this. AFAIK, these work very well, mail [EMAIL PROTECTED] if there are specific examples where this is not the case. Kind Regards - Orion In message [EMAIL PROTECTED],Maxim Sobolev writes: This is a multi-part message in MIME format. --192.168.1.100.0.526.1000539647.245.19907 Content-Type: text/plain Hi there, I want to get your comments on the attached patch, which makes sound driver resizing its DMA buffer according to the currently selected audio speed/format. This is necessary because most audio hardware supports wide range of speeds/formats, which makes it hard to define one buffer size that will satisfy all supported formats and providing minimal latency for the formats with low datarates, while good skip protection for formats with high datarates. For example 4096 bytes used now in most drivers doesn't protect data playing on 44kHz from skipping when there is some kernel activity going on (for example output on console or switching between consoles), while at the same time this size means 0.5s latency for games that use 8kHz/8 bit audio formats, which is a quite noticeable delay. Attached patch fixes some maximal buffer size, which is necessary for proper registering with the DMA subsystem, while scales this buffer down when format with lower datarate is selected. I'm running this patch for a month on my -current system with OPL3-SA hardware and so far it works like a charm - mpg123 no longer skips when I'm scrolling in the editor running on console, while audio delay in digger (22kHz, 8 bit, mono) is absolutely unnoticeable. This patch only improves mss driver, but it should be relatively easy to modify other drivers as well (I do not have a hardware to test changes on). Thank you in advance! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
