- Alsa-devel - mailman.alsa-project.org

[alsa-devel] Questions on locking, snd-usb-caiaq
by Mark Hills 18 Oct '09

18 Oct '09

I fixed some race issues in snd-usb-caiaq, but have some questions on the interface between the driver and ALSA. First fix is a lock in pointer(), which caused snd_pcm_update_hw_ptr_pos() to report an out of range buffer position (even though it was sucessfully corrected to zero). Second is a lock as part of trigger(). On testing, this appears to fix an issue where white noise could sometimes be transferred by the driver. According to the documentation, trigger() and pointer() are called with local interrupts disabled. This means they should really be non-irqsave locks? (http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s08.html) Even for callbacks documented as atomic, if read_completed() and write_completed() can be called at any time interrupts are enabled (eg. on another CPU) it seems that additional locking my be required. Candidates are: snd_usb_caiaq_substream_open snd_usb_caiaq_substream_close snd_usb_caiaq_pcm_hw_free snd_usb_caiaq_pcm_prepare Are there any guarantees on these functions which mean the lock is not required? To lock in prepare() would (I think) require demoting a spin_lock_irqsave() to a spin_lock() to send initialisation commands. If so, what is the best design for this? Thanks, -- Mark diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c index 121af06..c659f81 100644 --- a/sound/usb/caiaq/audio.c +++ b/sound/usb/caiaq/audio.c @@ -62,10 +62,15 @@ static void activate_substream(struct snd_usb_caiaqdev *dev, struct snd_pcm_substream *sub) { + unsigned long flags; + spin_lock_irqsave(&dev->spinlock, flags); + if (sub->stream == SNDRV_PCM_STREAM_PLAYBACK) dev->sub_playback[sub->number] = sub; else dev->sub_capture[sub->number] = sub; + + spin_unlock_irqrestore(&dev->spinlock, flags); } static void @@ -269,16 +274,23 @@ snd_usb_caiaq_pcm_pointer(struct snd_pcm_substream *sub) { int index = sub->number; struct snd_usb_caiaqdev *dev = snd_pcm_substream_chip(sub); + unsigned long flags; + snd_pcm_uframes_t ptr; + + spin_lock_irqsave(&dev->spinlock, flags); if (dev->input_panic || dev->output_panic) - return SNDRV_PCM_POS_XRUN; + ptr = SNDRV_PCM_POS_XRUN; if (sub->stream == SNDRV_PCM_STREAM_PLAYBACK) - return bytes_to_frames(sub->runtime, + ptr = bytes_to_frames(sub->runtime, dev->audio_out_buf_pos[index]); else - return bytes_to_frames(sub->runtime, + ptr = bytes_to_frames(sub->runtime, dev->audio_in_buf_pos[index]); + + spin_unlock_irqrestore(&dev->spinlock, flags); + return ptr; } /* operators for both playback and capture */

3 12

[alsa-devel] How to close ALSA device nodes?
by Rémi Denis-Courmont 18 Oct '09

18 Oct '09

Hello, I'm getting a bug report against VLC media player whereby ALSA sound output stops working when the screensaver is inhibited. It turns out that VLC is leaking any file descriptor open through ALSA-lib into child processes. The exact same issue was already raised by mplayer... 6 years ago: http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06249.html In other cases (V4L, OSS, DVB, DVD, sockets, even regular files...), VLC would open the device nodes with O_CLOEXEC flag (if supported by kernel and libc) and fallback to setting FD_CLOEXEC via fcntl(). Then the descriptor is automatically, and in the earlier case, thread-safely, closed whenever VLC - forks and- execs. With ALSA-lib, I cannot figure any way to achieve that... From the earlier thread, I reckon that ALSA developers consider that this is an upper-layer issue. Maybe so, but then how is the upper-layer supposed to find which file descriptors ALSA-lib has opened - if any? Conversely, if ALSA- lib won't tell while file descriptors it is using, what could possibly be the use case for not closing those on exec? Best regards, -- Rémi Denis-Courmont http://www.remlab.net/

2 1

[alsa-devel] alsa-driver compile error (1.0.21 and latest snapshot)
by Stephen Stocker 18 Oct '09

18 Oct '09

Hi, Using Slackware and gcc 3.3.6, I'm getting the following error compiling the alsa-driver for intel8x0. This is on a 2.4.24-ck1 kernel, if that helps. make[1]: Entering directory `/home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/pc i' gcc -D__KERNEL__ -DMODULE=1 -I/home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/i nclude -I/usr/src/linux-2.4.24-ck1/include -O2 -mpreferred-stack-boundary=2 -ma rch=i586 -DLINUX -Wall -Wstrict-prototypes -fomit-frame-pointer -Wno-trigraphs - O2 -fno-strict-aliasing -fno-common -pipe -DALSA_BUILD -nostdinc -iwithprefix in clude -DMODVERSIONS -include /usr/src/linux-2.4.24-ck1/include/linux/modversions .h -DKBUILD_BASENAME=intel8x0 -c -o intel8x0.o intel8x0.c In file included from intel8x0.c:39: /home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/include/sound/ac97_codec.h: In function `snd_ac97_dev_add_pdata': /home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/include/sound/ac97_codec.h:651: error: structure has no member named `platform_data' intel8x0.c: At top level: pci_iomap_compat.c:62: warning: `ioport_unmap' defined but not used intel8x0.c:103: warning: `enable' defined but not used intel8x0.c:105: warning: `joystick' defined but not used make[1]: *** [intel8x0.o] Error 1 make[1]: Leaving directory `/home/lpar/alsa-driver-1.0.21.1.g098ab.13.g15db1/pci ' make: *** [compile] Error 1 Thanks in advance for any help you can offer. :) Steve -- Hope, Despair and the Triumph of Life http://www.hdtl.org Abuse Prevention/Survivor Support

1 0

[alsa-devel] [patch] snd-pcsp: fix nforce_wa
by Stas Sergeev 17 Oct '09

17 Oct '09

Hi. In this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi… the nforce workaround (nforce_wa option) was broken, because the introduced "pointer_update" variable was forgotten to use. Also, the "ns" became u64 in some places and "long" in others, which is not the same, AFAIK. I revert that to u64-everywhere. Also, the log says: --- With the callback mode HRTIMER_CB_IRQSAFE_UNLOCK, the start of the stream with zero delay doesn't work. --- but the attached patch, that reverts to the "zero-delay start", works for me... So, while I like the cleanups made, I wonder what was the reason behind that changes? How can I reproduce the breakage of the zero-delay start? Oh, and it would be nice to CC me the changes in that driver, if possible. :)

1 0

Re: [alsa-devel] Issue with creative Xfi PCIe ca0110-IBG
by Philippe 17 Oct '09

17 Oct '09

Takashi Iwai <tiwai <at> suse.de> writes: > > At Wed, 14 Oct 2009 18:03:15 +0200, > Guillem Solà wrote: > > > > Takashi Iwai wrote: > > > At Tue, 13 Oct 2009 18:59:23 +0200, > > > Guillem Solà wrote: > > > > > >> Takashi Iwai wrote: > > >> > > >>> At Tue, 13 Oct 2009 17:01:35 +0200, > > >>> Guillem Solà wrote: > > >>> > > >>> > > >>>> Takashi Iwai wrote: > > >>>> > > >>>> > > >>>>> At Tue, 13 Oct 2009 16:12:47 +0200, > > >>>>> Guillem Solà wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>> Takashi Iwai wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> At Tue, 13 Oct 2009 14:10:44 +0200, > > >>>>>>> Guillem Solà wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>>> Takashi Iwai wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> It shows the address 1. So, my patch doesn't work, as it assumes > > >>>>>>>>> address 0. Replace it with 1, and pass probe_mask=0x02. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Takashi > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> Yeah great, it's working again! > > >>>>>>>> > > >>>>>>>> I did modprobe snd-hda-intel probe_mask=0x03 instead of mask=0x02 to > > >>>>>>>> make it work > > >>>>>>>> > > >>>>>>>> and the patch let this way ( I changed both return 1 and addr=1) > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> Now the question is whether probe_mask=0x03 (or 0x02) works without > > >>>>>>> this patch. How is it? > > >>>>>>> > > >>>>>>> > > >>>>>>> thanks, > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> after few tests I can conclude that it could work with and without the > > >>>>>> patch. The same happens with modprobe snd-hda-intel probe_mask=0x03 or > > >>>>>> 0x02 both can work. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> OK, good to hear. > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> So it seems to be fickle because not all the times you modprobe the > > >>>>>> intel module it worked. > > >>>>>> > > >>>>>> > > >>>>> Do you mean it's still unstable even with probe_mask option, or it is > > >>>>> when without? > > >>>>> > > >>>>> If probe_mask fixes its fickleness (or flirtation :), the patch below > > >>>>> should help. It will set the default probe_mask for your device. > > >>>>> Give it a try. > > >>>>> > > >>>>> > > >>>>> Takashi > > >>>>> > > >>>> Hi, > > >>>> > > >>>> By fickle I mean that when modprobing hda-intel module sometimes it > > >>>> works fine and others cannot get audio although the system seems to > > >>>> always recognize the card, and yes, I'm always using probe_mask=0x02 option. > > >>>> > > >>>> Actually, about one of five times I can successfully load the module. As > > >>>> I said the first patch doesn't affect, it has been only the casualty > > >>>> that made me believe it did something. > > >>>> > > >>>> > > >>> Hm, then it's still puzzling what causes the problem in the recent > > >>> kernel. Or is it coincidence? > > >>> > > >>> > > >> Uff, really don't know what to say, when I thought I saw some light... > > >> I've been testing with 2.6.31-rc6 and 2.6.31 (final) with and without > > >> patches and maybe is only the probe_mask option what make it work sometimes. > > >> > > >> Perhaps I did bisect bad and wasn't > > >> deadff1665491afce124a8ff83f00f784161f660 first bad commit? > > >> > > > > > > Possible. But, before bisecting, we should be really sure which > > > release was really OK. Did 2.6.30 work without any problems? > > > > > > > > > > Hi, > > > > AFAIK in 2.6.30 ca0110 was not implemented. I see it start working in > > 2.6.31-rc3 and did a two weeks running test with 2.6.31-rc5. > > > > So I bisected from 2.6.31-rc6 to 2.6.31-rc5 > > OK. It's possible that a regression occurs at rc6 because of the > core HD-audio changes. But, I still wonder why the patch doesn't > change anything. > > At least, it'd be nice if you can reconfirm that rc5 is really working > stably. You can just copy sound/pci/hda/* over any newer kernels. > > Takashi > _______________________________________________ > Alsa-devel mailing list > Alsa-devel <at> alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > Hi, I have the same model of sound card and can't make it work. I saw that this conversation has stalled so I'm going to give informations about what I've tested. First thing, using one of the latest alsa-driver snapshots with a 2.6.31-gentoo-r2 kernel, I got this in dmesg when loading the snd-hda-intel driver : [ 111.287946] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 [ 111.287968] HDA Intel 0000:03:00.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 [ 111.567237] hda-intel: spurious response 0x0:0x0, last cmd=0x000000 [ 112.575093] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x107f0d00 [ 113.583158] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x107f0d00 And then, when I tried to play a sound a few times : [ 167.997029] hda_codec: rates == 0 (nid=0x12, val=0x0, ovrd=0) [ 173.053323] __ratelimit: 1 callbacks suppressed [ 174.124799] hda_codec: rates == 0 (nid=0x12, val=0x0, ovrd=0) [ 287.496606] hda_codec: rates == 0 (nid=0x12, val=0x0, ovrd=0) [ 287.496934] __ratelimit: 20 callbacks suppressed I made my tests with aplay and mplayer, they just stall and I don't get any sound. Today, after reading this thread I tried making it work with the 2.6.31 kernel from rc3 to rc6 (without gentoo patches), none of them worked. I compiled them with debug and this is the output of dmesg when I load the driver : [ 1778.639675] HDA Intel 0000:03:00.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 [ 1778.639778] ALSA sound/pci/hda/hda_intel.c:2334: chipset global capabilities = 0x3300 [ 1778.663717] ALSA sound/pci/hda/hda_intel.c:823: codec_mask = 0x2 [ 1778.663830] ALSA sound/pci/hda/hda_intel.c:1252: codec #1 probed OK [ 1778.695745] ALSA sound/pci/hda/hda_codec.c:3857: autoconfig: line_outs=4 (0xb/0xd/0xc/0xe/0x0) [ 1778.695753] ALSA sound/pci/hda/hda_codec.c:3861: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1778.695760] ALSA sound/pci/hda/hda_codec.c:3865: hp_outs=1 (0xf/0x0/0x0/0x0/0x0) [ 1778.695767] ALSA sound/pci/hda/hda_codec.c:3866: mono: mono_out=0x0 [ 1778.695772] ALSA sound/pci/hda/hda_codec.c:3869: dig-out=0x12/0x0 [ 1778.695777] ALSA sound/pci/hda/hda_codec.c:3877: inputs: mic=0x11, fmic=0x0, line=0x10, fline=0x0, cd=0x0, aux=0x0 [ 1778.695785] ALSA sound/pci/hda/hda_codec.c:3879: dig-in=0x13 And when I try to play a sound : [ 1845.100435] ALSA sound/pci/hda/hda_intel.c:1557: azx_pcm_prepare: bufsize=0x8000, format=0x13 [ 1845.100457] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x12 [ 1845.100466] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x2, stream=0x4, channel=0, format=0x13 [ 1845.108003] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x6, stream=0x4, channel=0, format=0x13 [ 1845.116000] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x4, stream=0x4, channel=2, format=0x13 [ 1845.124001] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x3, stream=0x4, channel=0, format=0x13 [ 1845.132001] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x5, stream=0x4, channel=0, format=0x13 [ 1851.730678] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x2 [ 1851.730691] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x4 [ 1851.730705] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x3 [ 1851.730717] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x5 [ 1851.730724] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x6 I tried using your patch Takashi, the driver wouldn't load until I put 1 in the address like Guillem did. But even with that sound doesn't work no matter the probe_mask setting I use. And a last note, I did my tests on the rc versions without rebooting, just removing the module and modprobing it again, but I don't think it matters. Here's my lspci -vvnn : 02:00.0 PCI bridge [0604]: Creative Labs Device [1102:7006] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=02, secondary=03, subordinate=03, sec-latency=32 Memory behind bridge: fdf00000-fdffffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Bridge: PM- B3+ Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Count=1/16 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [80] Subsystem: Creative Labs Device [1102:0010] Capabilities: [90] Express (v1) PCI/PCI-X Bridge, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ BrConfRtry- MaxPayload 512 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSVoil- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- 03:00.0 Audio device [0403]: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG [1102:0009] Subsystem: Creative Labs Device [1102:0018] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (500ns min, 5000ns max) Interrupt: pin A routed to IRQ 17 Region 0: Memory at fdffc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [dc] Power Management version 3 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Output from alsa-info : http://www.alsa-project.org/db/?f=473df043d8633b85a0a5319d2e7a73c4a13d2761 Hope this gives you some hint to solve our problem. Regards, Philippe

1 0

[alsa-devel] [PATCH] Fix codec_dai->ops NULL pointer bug for AC97 codec dai in soc-core
by Barry Song 16 Oct '09

16 Oct '09

AC97 codec DAIs don't register themselves eg.stac9766, wm9712, wm9713, wm9705.c, ad1980, then it loses to the chance to be given a null_dai_ops in snd_soc_register_dai if they have no ops. When functions like soc_pcm_open, soc_pcm_hw_params etc. access the ops field in these DAIs, panic will happen. Signed-off-by: Barry Song <21cnbao(a)gmail.com> --- sound/soc/soc-core.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index fa0da3c..6643d64 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -795,6 +795,9 @@ static int soc_resume(struct device *dev) #define soc_resume NULL #endif +static struct snd_soc_dai_ops null_dai_ops = { +}; + static void snd_soc_instantiate_card(struct snd_soc_card *card) { struct platform_device *pdev = container_of(card->dev, @@ -838,6 +841,12 @@ static void snd_soc_instantiate_card(struct snd_soc_card *card) ac97 = 1; } + for (i = 0; i < card->num_links; i++) { + if (card->dai_link[i].codec_dai->ac97_control && + (!card->dai_link[i].codec_dai->ops)) + card->dai_link[i].codec_dai->ops = &null_dai_ops; + } + /* If we have AC97 in the system then don't wait for the * codec. This will need revisiting if we have to handle * systems with mixed AC97 and non-AC97 parts. Only check for @@ -2332,9 +2341,6 @@ static int snd_soc_unregister_card(struct snd_soc_card *card) return 0; } -static struct snd_soc_dai_ops null_dai_ops = { -}; - /** * snd_soc_register_dai - Register a DAI with the ASoC core * -- 1.5.6.3

2 5

[alsa-devel] How can i contribute a new AsoC codec driver for the CS42L51 ?
by Eduardo Tagle 16 Oct '09

16 Oct '09

Just forgive me... I am new to this world of mailing-lists, so let me explain... I have written an ASoC codec driver for the Cirrus Logic CS42L51 audio Codec. It was just based on the publicly available datasheet from Cirrus Website. I really would like to know how to submit it to be included in the official ASoC source tree. I have tested it as much as possible, and seems to work reliably. What are the steps required to follow to submit this new ASoC driver ? Thanks in advance, Eduardo

2 1

[alsa-devel] [PATCH 0/30] ALSA: HDA VIA: patch series
by Logan Li 16 Oct '09

16 Oct '09

Following patch series mainly includes: - support VT1718S, VT2002P, VT1812S, VT1716S, ... - support smart 5.1 - add jack detection for VT1708 - power saving functions

4 13

[alsa-devel] beeps with incorrect frequency / volume
by Sébastien Hinderer 16 Oct '09

16 Oct '09

Dear ALSA Developers, The sound card of my laptop is a HDA Intel, chip Intel G45 DEVCTG The PC beeps do not work correctly. One problem is that the frequency of the beeps one can hear does not correspond to the required frequency. For instane the command beep 440 produces a beep whose frequency is not 440Hz The second problem is that, although there is a PC beep control provided in alsamixer, the control is not taken into account: the beep is loud no matter how the control is set. I think this problem has already been reported but can't find it in the bug tracking system. Could someone please help and tell me whether the problem can e solved or not and, if it can, how. Many thanks in advance for any help, Sébastien.

1 0

[alsa-devel] ASoC update for 2.6.32
by Mark Brown 15 Oct '09

15 Oct '09

The following changes since commit 6f775ba0154cdf10108071acc71f26c4efdb8d57: Mark Brown (1): Merge branch 'upstream/wm8350' into for-2.6.32 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.32 Eero Nurkkala (1): ASoC: Serialize access to dapm_power_widgets() sound/soc/soc-dapm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

1 0