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

Re: [alsa-devel] [LAD] announcing envy24control, mudita (*) edition.
by Niels Mayer 04 Aug '10

04 Aug '10

On Wed, Aug 4, 2010 at 12:00 PM, Tim E. Real <termtech(a)rogers.com> wrote: > Something odd. Are you sure about those digital mixer ranges? Yep. > They now go down to only -48dB instead of -144dB. > Seems like 2/3 of the range is missing? Truncated. At least for my purposes, the original faders w/ 144dB dynamic range and linear mapping on the controls made the "business end" of the gain -- the top 20-30dB -- occur over far to few pixels to be controllable via mouse. At the same time the meters themselves go down to -48dB and there is the whole confusion about the scale-markings on the analog sliders versus the meters. Now there's none. And the "top end" of the slider is now more easily controllable by mouse. The MIDI control and other more fine-grained control (e.g. via , e.g. alsamixer-qt4, alsamixer, or other programs) is not affected. In this new 'mudita24' interface, the input is set "off" when then digital mixer input attenuator is moved below -48dB, but not via MIDI or other external control. Therefore if someone actually needs to mix an input at -48dB or lower, they can still use the MIDI controllers or a different mixer like alsamixer-qt4 to set those kind of levels. This seemed like a better compromise than wasting more than half the slider real-estate to changes that can't even be heard (unless you've got the volume turned way up). If this is particularly bothersome please let me know and I guess I'll add an option to give the full 0 to -144dB range back. However, if you're doing that kind of mixing, perhaps using a different mixer than the envy24's hardware mixer is more appropriate? > Also, the 'active' colour of the meters seems way too 'soft'? > Seems like just a slightly darker grey shade than the meter > background (although I know it's supposed to be blue). Yes, I see that this is very skin dependent and what is working for me isn't working for others. (Could you send a picture to show me what the coloration of your meters ends up like on your system?) Any suggestions on using a different built-in color so as to not worry about contrast or visibility issues? > This makes it very hard to see the meters in action. > A lighter shade of blue would make it look nice like a flourescent > type of display. Is there a known standard gnone name that can be applied to the foreground color? Alternately, how about options --meterfg and ---meterbg that allow you to specify the colors? > Also, sorry about this, I missed something in the ALSA dB reading > code I submitted: The index of the control: > > In volume.c: dac_volume_adjust() and adc_volume_adjust(), > remove the clear() and set an index like this: > > snd_ctl_elem_id_t *elem_id; > snd_ctl_elem_id_alloca(&elem_id); > //snd_ctl_elem_id_clear(elem_id); // TER: Removed > snd_ctl_elem_id_set_interface(elem_id, SND_CTL_ELEM_IFACE_MIXER); > snd_ctl_elem_id_set_name(elem_id, DAC_VOLUME_NAME); > snd_ctl_elem_id_set_index(elem_id, idx); // TER: Added > long db_gain = 0; > > And in mixer.c: mixer_volume_to_db() > remove the clear() and set an index: > > snd_ctl_elem_id_t *elem_id; > snd_ctl_elem_id_alloca(&elem_id); > //snd_ctl_elem_id_clear(elem_id); // TER: Removed > snd_ctl_elem_id_set_interface(elem_id, SND_CTL_ELEM_IFACE_MIXER); > > /* IEC958_MULTI_CAPTURE_VOLUME, for stream=19 or 20 gives incorrect > results, use HW_MULTI_CAPTURE_VOLUME for all */ > // Verified by TER. Those two controls have no dB values, but they should, > // they're just part of the same mixer ! > // snd_ctl_elem_id_set_name(elem_id, (stream <= 10) ? > // MULTI_PLAYBACK_VOLUME : (stream <= 18 ? HW_MULTI_CAPTURE_VOLUME : > // IEC958_MULTI_CAPTURE_VOLUME)); > snd_ctl_elem_id_set_name(elem_id, (stream <= 10) ? MULTI_PLAYBACK_VOLUME : > HW_MULTI_CAPTURE_VOLUME); > > // TER: First line is 'proper' way, but second line is corrected > // workaround for lack of dB values for IEC958 controls. > //snd_ctl_elem_id_set_index(elem_id, stream <= 18 ? (stream - 1) % 10 : > // (stream - 1) % 18 ); > snd_ctl_elem_id_set_index(elem_id, stream <= 18 ? (stream - 1) % 10 : 0 ); > I'll have to look into this one... seems like a 1.0.2 is inevitable... ----- > With the ice1712 digital mixer, it is not so crucial that we pay attention to > what ALSA tells us about those controls. > Setting an index with snd_ctl_elem_id_set_index() is not crucial. > After all, this app is specifically for ice1712 and nothing else, so we know > that it's always going to be an ice1712 chip, so we can take advantage > of this, and 'hard-code' the digital mixer scale markings and other things. > The ADC/DAC section however, is a different matter. > Here is where we must pay attention to ALSA because we don't know > what kind of codec chips may be used. > We can't even assume that all controls in a group have the same range so > to be safe we must use snd_ctl_elem_id_set_index(). > Granted, envy24control does use some card-specific code for some tricks, > but to support new cards with yet-unknown codecs, we must trust ALSA. > If we wanted utmost dB accuracy, we'd have to use card-specific code for > the AK4524 chip for example, due to the broken ALSA TLV functionality, > as Clements mentioned in another thread. > These are the approaches I'm using in my re-work of the scales and page snaps. We're all looking forward to these improvements. > And finally, a reminder (also to myself) to try to avoid using newer gtk > functions because this app is 'supposed' to be able to built with gtk-1. > Those 'built-in' GtkScale marker functions are new since 2.16, and likely the > app could not be built with gtk-1. > I guess bumping up to a minimum of gtk+-2.0 might be OK though, > as it is the year 2010... Anyone still using gtk+-1.x ? I think it makes sense to update the minimum to gtk+-2.0 .. I'm not sure what the ALSA folk think. Also my use of gtk_label_set_markup() is another one of these newer functions. -- Niels. http://nielsmayer.com

1 0

Re: [alsa-devel] Intel HDMI audio stops after 15 minutes
by Paul Menzel 04 Aug '10

04 Aug '10

Dear Shane, Am Mittwoch, den 04.08.2010, 10:35 -0700 schrieb Shane W: > On my Intel DG45 mainboard (Yamaha RX-v1800 receiver) I am > now only getting audio for about 15 minutes before it stops > and I have to restart the X server. Playing a movie with > audio works fine but playing an mp3 has the cutout. Is > there a new power saving mode or the like that has crept > in? from your message I am guessing that it worked before. If that was true, it would the developers if you told them the versions of the relevant components (ALSA, Linux, …). Thanks, Paul

1 0

Re: [alsa-devel] [PATCH 5/5] ASoC: fix uninitialized variable
by Mark Brown 04 Aug '10

04 Aug '10

On Wed, Aug 04, 2010 at 08:59:49AM -0400, Bill Pemberton wrote: > > No, just stomping over the variable to shut up the warning doesn't > > improve anything at all. You need to make sure that the compiler can > > actually follow the control flow to see that the data is always > > initialised rather than disabling the check and missing any actual > > issues. > I did, hence the comment in the commit that the variable is > initialized by fll_factors(). You're completely missing the point here. What I said was that you need to make sure that the *compiler* can actually follow the control flow. You've not done that, you've stomped over the warning to shut both this and any valid warnings related to the structure up.

1 0

[alsa-devel] [GIT PULL] Updates for 2.6.36
by Liam Girdwood 04 Aug '10

04 Aug '10

Hi Takashi, A last update for 2.6.36. Thanks Liam --- The following changes since commit 116bcd9cf22c00c22402c2a2be6ef8e81289a574: Axel Lin (1): ASoC: wm9081: fix resource reclaim in wm9081_register error path are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git for-2.6.36 Peter Ujfalusi (1): ASoC: TWL4030: Capture route runtime DAPM ordering fix sound/soc/codecs/twl4030.c | 48 +++++++++++--------------------------------- 1 files changed, 12 insertions(+), 36 deletions(-)

2 1

[alsa-devel] [PATCH] ASoC: TWL4030: Capture route runtime DAPM ordering fix
by Peter Ujfalusi 04 Aug '10

04 Aug '10

Fix the ordering problem in DAPM domain, when the user changes between digital and analog sources during active capture (or loopback) scenario. Before this patch, when the user changed from analog source to digital there were a short time, when the codec enabled analog mic bias (2.2 volts) instead of the correct digital mic bias (1.8 volts) to the digital microphones. This behaviour caused by the former implementation of selecting the correct type of bias. This was done at the POST_REG event of the DAPM_MUX_E("TXx Capture Route") widget. By moving the bias type selection as DAPM_SUPPLY and connecting it to the corresponding digimic widget the problematic situation can be avoided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- sound/soc/codecs/twl4030.c | 48 +++++++++++--------------------------------- 1 files changed, 12 insertions(+), 36 deletions(-) diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index d401c59..7b618bb 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -577,36 +577,6 @@ static const struct snd_kcontrol_new twl4030_dapm_dbypassv_control = TWL4030_REG_VSTPGA, 0, 0x29, 0, twl4030_dapm_dbypassv_tlv); -static int micpath_event(struct snd_soc_dapm_widget *w, - struct snd_kcontrol *kcontrol, int event) -{ - struct soc_enum *e = (struct soc_enum *)w->kcontrols->private_value; - unsigned char adcmicsel, micbias_ctl; - - adcmicsel = twl4030_read_reg_cache(w->codec, TWL4030_REG_ADCMICSEL); - micbias_ctl = twl4030_read_reg_cache(w->codec, TWL4030_REG_MICBIAS_CTL); - /* Prepare the bits for the given TX path: - * shift_l == 0: TX1 microphone path - * shift_l == 2: TX2 microphone path */ - if (e->shift_l) { - /* TX2 microphone path */ - if (adcmicsel & TWL4030_TX2IN_SEL) - micbias_ctl |= TWL4030_MICBIAS2_CTL; /* digimic */ - else - micbias_ctl &= ~TWL4030_MICBIAS2_CTL; - } else { - /* TX1 microphone path */ - if (adcmicsel & TWL4030_TX1IN_SEL) - micbias_ctl |= TWL4030_MICBIAS1_CTL; /* digimic */ - else - micbias_ctl &= ~TWL4030_MICBIAS1_CTL; - } - - twl4030_write(w->codec, TWL4030_REG_MICBIAS_CTL, micbias_ctl); - - return 0; -} - /* * Output PGA builder: * Handle the muting and unmuting of the given output (turning off the @@ -1430,12 +1400,10 @@ static const struct snd_soc_dapm_widget twl4030_dapm_widgets[] = { /* Analog/Digital mic path selection. TX1 Left/Right: either analog Left/Right or Digimic0 TX2 Left/Right: either analog Left/Right or Digimic1 */ - SND_SOC_DAPM_MUX_E("TX1 Capture Route", SND_SOC_NOPM, 0, 0, - &twl4030_dapm_micpathtx1_control, micpath_event, - SND_SOC_DAPM_POST_REG), - SND_SOC_DAPM_MUX_E("TX2 Capture Route", SND_SOC_NOPM, 0, 0, - &twl4030_dapm_micpathtx2_control, micpath_event, - SND_SOC_DAPM_POST_REG), + SND_SOC_DAPM_MUX("TX1 Capture Route", SND_SOC_NOPM, 0, 0, + &twl4030_dapm_micpathtx1_control), + SND_SOC_DAPM_MUX("TX2 Capture Route", SND_SOC_NOPM, 0, 0, + &twl4030_dapm_micpathtx2_control), /* Analog input mixers for the capture amplifiers */ SND_SOC_DAPM_MIXER("Analog Left", @@ -1459,6 +1427,11 @@ static const struct snd_soc_dapm_widget twl4030_dapm_widgets[] = { TWL4030_REG_ADCMICSEL, 3, 0, NULL, 0, digimic_event, SND_SOC_DAPM_POST_PMU), + SND_SOC_DAPM_SUPPLY("micbias1 select", TWL4030_REG_MICBIAS_CTL, 5, 0, + NULL, 0), + SND_SOC_DAPM_SUPPLY("micbias2 select", TWL4030_REG_MICBIAS_CTL, 6, 0, + NULL, 0), + SND_SOC_DAPM_MICBIAS("Mic Bias 1", TWL4030_REG_MICBIAS_CTL, 0, 0), SND_SOC_DAPM_MICBIAS("Mic Bias 2", TWL4030_REG_MICBIAS_CTL, 1, 0), SND_SOC_DAPM_MICBIAS("Headset Mic Bias", TWL4030_REG_MICBIAS_CTL, 2, 0), @@ -1590,6 +1563,9 @@ static const struct snd_soc_dapm_route intercon[] = { {"Digimic0 Enable", NULL, "DIGIMIC0"}, {"Digimic1 Enable", NULL, "DIGIMIC1"}, + {"DIGIMIC0", NULL, "micbias1 select"}, + {"DIGIMIC1", NULL, "micbias2 select"}, + /* TX1 Left capture path */ {"TX1 Capture Route", "Analog", "ADC Physical Left"}, {"TX1 Capture Route", "Digimic0", "Digimic0 Enable"}, -- 1.7.2

3 2

[alsa-devel] [PATCH] asoc/multi-component: fsl: add support for 36-bit physical addresses
by Timur Tabi 04 Aug '10

04 Aug '10

Update the DMA driver used by the Freescale MPC8610 HPCD audio driver to support 36-bit physical addresses, for both DMA buffers and the SSI registers. The DMA driver calls snd_dma_alloc_pages() to allocate the DMA buffers for playback and capture. This function is just a front-end for dma_alloc_coherent(). Currently, dma_alloc_coherent() only allocates buffers in low memory (it ignores GFP_HIGHMEM), so we never actually get a DMA buffer with a real 36-bit physical address. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- Liam, this patch should *not* be squashed into the rest of the changes for multi-component. sound/soc/fsl/fsl_dma.c | 77 +++++++++++++++++++++++++++++++---------------- 1 files changed, 51 insertions(+), 26 deletions(-) diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c index d09e194..4450f9d 100644 --- a/sound/soc/fsl/fsl_dma.c +++ b/sound/soc/fsl/fsl_dma.c @@ -175,13 +175,23 @@ static void fsl_dma_update_pointers(struct fsl_dma_private *dma_private) struct fsl_dma_link_descriptor *link = &dma_private->link[dma_private->current_link]; - /* Update our link descriptors to point to the next period */ - if (dma_private->substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - link->source_addr = - cpu_to_be32(dma_private->dma_buf_next); - else - link->dest_addr = - cpu_to_be32(dma_private->dma_buf_next); + /* Update our link descriptors to point to the next period. On a 36-bit + * system, we also need to update the ESAD bits. We also set (keep) the + * snoop bits. See the comments in fsl_dma_hw_params() about snooping. + */ + if (dma_private->substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + link->source_addr = cpu_to_be32(dma_private->dma_buf_next); +#ifdef CONFIG_PHYS_64BIT + link->source_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP | + upper_32_bits(dma_private->dma_buf_next)); +#endif + } else { + link->dest_addr = cpu_to_be32(dma_private->dma_buf_next); +#ifdef CONFIG_PHYS_64BIT + link->dest_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP | + upper_32_bits(dma_private->dma_buf_next)); +#endif + } /* Update our variables for next time */ dma_private->dma_buf_next += dma_private->period_size; @@ -273,11 +283,19 @@ static irqreturn_t fsl_dma_isr(int irq, void *dev_id) * This function is called when the codec driver calls snd_soc_new_pcms(), * once for each .dai_link in the machine driver's snd_soc_card * structure. + * + * snd_dma_alloc_pages() is just a front-end to dma_alloc_coherent(), which + * (currently) always allocates the DMA buffer in lowmem, even if GFP_HIGHMEM + * is specified. Therefore, any DMA buffers we allocate will always be in low + * memory, but we support for 36-bit physical addresses anyway. + * + * Regardless of where the memory is actually allocated, since the device can + * technically DMA to any 36-bit address, we do need to set the DMA mask to 36. */ static int fsl_dma_new(struct snd_card *card, struct snd_soc_dai *dai, struct snd_pcm *pcm) { - static u64 fsl_dma_dmamask = DMA_BIT_MASK(32); + static u64 fsl_dma_dmamask = DMA_BIT_MASK(36); int ret; if (!card->dev->dma_mask) @@ -609,12 +627,7 @@ static int fsl_dma_hw_params(struct snd_pcm_substream *substream, link->count = cpu_to_be32(period_size); - /* Even though the DMA controller supports 36-bit addressing, - * for simplicity we allow only 32-bit addresses for the audio - * buffer itself. This was enforced in fsl_dma_new() with the - * DMA mask. - * - * The snoop bit tells the DMA controller whether it should tell + /* The snoop bit tells the DMA controller whether it should tell * the ECM to snoop during a read or write to an address. For * audio, we use DMA to transfer data between memory and an I/O * device (the SSI's STX0 or SRX0 register). Snooping is only @@ -629,20 +642,24 @@ static int fsl_dma_hw_params(struct snd_pcm_substream *substream, * flush out the data for the previous period. So if you * increased period_bytes_min to a large enough size, you might * get more performance by not snooping, and you'll still be - * okay. + * okay. You'll need to update fsl_dma_update_pointers() also. */ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { link->source_addr = cpu_to_be32(temp_addr); - link->source_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP); + link->source_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP | + upper_32_bits(temp_addr)); link->dest_addr = cpu_to_be32(ssi_sxx_phys); - link->dest_attr = cpu_to_be32(CCSR_DMA_ATR_NOSNOOP); + link->dest_attr = cpu_to_be32(CCSR_DMA_ATR_NOSNOOP | + upper_32_bits(ssi_sxx_phys)); } else { link->source_addr = cpu_to_be32(ssi_sxx_phys); - link->source_attr = cpu_to_be32(CCSR_DMA_ATR_NOSNOOP); + link->source_attr = cpu_to_be32(CCSR_DMA_ATR_NOSNOOP | + upper_32_bits(ssi_sxx_phys)); link->dest_addr = cpu_to_be32(temp_addr); - link->dest_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP); + link->dest_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP | + upper_32_bits(temp_addr)); } temp_addr += period_size; @@ -673,10 +690,23 @@ static snd_pcm_uframes_t fsl_dma_pointer(struct snd_pcm_substream *substream) dma_addr_t position; snd_pcm_uframes_t frames; - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + /* Obtain the current DMA pointer, but don't read the ESAD bits if we + * only have 32-bit DMA addresses. This function is typically called + * in interrupt context, so we need to optimize it. + */ + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { position = in_be32(&dma_channel->sar); - else +#ifdef CONFIG_PHYS_64BIT + position |= (u64)(in_be32(&dma_channel->satr) & + CCSR_DMA_ATR_ESAD_MASK) << 32; +#endif + } else { position = in_be32(&dma_channel->dar); +#ifdef CONFIG_PHYS_64BIT + position |= (u64)(in_be32(&dma_channel->datr) & + CCSR_DMA_ATR_ESAD_MASK) << 32; +#endif + } /* * When capture is started, the SSI immediately starts to fill its FIFO. @@ -936,11 +966,6 @@ static void __exit fsl_soc_dma_exit(void) of_unregister_platform_driver(&fsl_soc_dma_driver); } -/* We want the DMA driver to be initialized before the SSI driver, so that - * when the SSI driver calls fsl_soc_dma_dai_from_node(), the DMA driver - * will already have been probed. The easiest way to do that is to make the - * __init function called via arch_initcall(). - */ module_init(fsl_soc_dma_init); module_exit(fsl_soc_dma_exit); -- 1.7.0.1

2 1

Re: [alsa-devel] Wrong channel order with multichannel HDMI on NVIDIA MCP7A
by Anssi Hannula 03 Aug '10

03 Aug '10

(restored CC) Kirjoitit tiistai, 3. elokuuta 2010 23:40:13: > On Tue, Aug 3, 2010 at 1:32 PM, Anssi Hannula <anssi.hannula(a)iki.fi> wrote: > > pl bossart kirjoitti tiistai, 3. elokuuta 2010 23:15:28: > >> > Well, this is one of my looong-standing TODOs. > >> > Originally I wanted to implement a new API to get/set the > >> > channel-mapping, mainly for HDMI. > >> > But, I've been recently too busy for other tasks (I can spend little > >> > time for ALSA), thus it's pending forever. > >> > >> You would only need an API to get the channel mapping. The HDMI sink > >> will report its speaker configuration through a CEA code (section 7.4 > >> of the spec), and if we parsed the EDID info we could present the > >> relevant channel order to user-space apps. > > > > I'm not sure I see how that will help with the problem of this thread, > > though, i.e. NVIDIA MCP7A hdmi codec apparently assuming audio being fed > > in windows channel order instead of alsa channel order. > > You can in theory specify the channel order in the InfoFrame (CA > field). If you had access to a register to program this, you would no > longer be tied to alsa or windows or whatever order. You would just > provide ALSA with the channels in the order you configured with the CA > code. The CA field is programmable, but the channel orders are predefined and no arbitrary channel formats are possible (see patch_hdmi.c or the related CEA spec). The nvhdmi MCP7x codec driver tries to specify a channel order by using the channel_id field in AC_VERB_SET_CHANNEL_STREAMID for the 4 slave digital converters, but it doesn't seem to have any effect (at least on hardware I have; confirmed by swapping the channel_ids around with no effect). -- Anssi Hannula

1 0

[alsa-devel] Wrong channel order with multichannel HDMI on MCP7A
by Anssi Hannula 03 Aug '10

03 Aug '10

Hi all! I have a motherboard with NVIDIA MCP7A HDMI audio. However, multichannel audio is not mapped properly into the HDMI order. On 5.1, I get RL in FC, RR in LFE, FC in RL, LFE in RR. Interestingly, this is not consistent with the ALSA channel order (FL FR RL RR FC LFE) being passed directly to HDMI (FL FR LFE FC RL RR). Instead it looks like there has been a waveformatex (FL FR FC LFE RL RR; windows?) => HDMI conversion instead of ALSA => HDMI. Same happens for 7.1. Is it possible to set the hardware to do an ALSA => HDMI conversion instead? If not, we should manually compensate for this somewhere, right? Somewhat relatedly, trying to output 4 channels results in silence only. Trying to output 3 or 5 channels triggers a timeout with I/O error, with the following in the kernel log: "ALSA pcm_lib.c:1757: playback write error (DMA or IRQ trouble?)" I used a git alsa-kmirror from few days ago on 2.6.35-rc4 for testing. Speaker-test and alsa-lib were 1.0.23. -- Anssi Hannula

4 12

[alsa-devel] Playback open error: Inappropriate ioctl for device
by John Simpson 03 Aug '10

03 Aug '10

On 7/13/10, Clemens Ladisch <clemens(a)ladisch.de> wrote: > John Simpson wrote: > > I've been trying to use the alsa-lib API, but I haven't been able to > > get anything to compile. > > > > ~/alsa/alsa-lib-1.0.22/test$ for f in *.c; do echo; cc $f 2>&1 | head -n2; done > > > ... > > Did I miss something? > > The makefile. > > If alsa-lib is installed correctly, the only option you need for your > own programs is -lasound. > > Ok, now I can compile several of the test programs, but I am still not able to generate sound. [1|user(a)Nokia-N810-43-7|~/alsa-lib-1.0.23/test]cc -lasound control.c -o control [1|user(a)Nokia-N810-43-7|~/alsa-lib-1.0.23/test]./control Soundcard #1: card - 0 id - 'EAC' driver - 'EAC' name - 'OMAP24xx EAC' longname - 'OMAP24xx EAC with codec TLV320AIC33' mixername - 'TLV320AIC33' components - '' PCM next device error: Inappropriate ioctl for device RAWMIDI next device error: Inappropriate ioctl for device [1|user(a)Nokia-N810-43-7|~/alsa-lib-1.0.23/test]cc -lasound pcm.c -o pcm [1|user(a)Nokia-N810-43-7|~/alsa-lib-1.0.23/test]./pcm Playback device is plughw:0,0 Stream parameters are 44100Hz, S16_LE, 1 channels Sine wave rate is 440.0000Hz Using transfer method: write Playback open error: Inappropriate ioctl for device [1|user(a)Nokia-N810-43-7|~/alsa-lib-1.0.23/test]cc -lasound pcm_min.c -o pcm_min [1|user(a)Nokia-N810-43-7|~/alsa-lib-1.0.23/test]./pcm_min Playback open error: Inappropriate ioctl for device I sure appreciate the help... I'm feeling a bit dense at the oment :-(

2 5

[alsa-devel] Regression 2.6.35: Intel N10/ICH 7 Family HDA (Realtek ALC662 rev1) beep broken
by Leandro Lucarella 03 Aug '10

03 Aug '10

Hi. I've upgraded from kernel 2.6.34 to 2.6.35 and the beep through the sound card stopped working. I found a very similar problem[1] (commit[2]). [1] http://lkml.org/lkml/2010/7/28/228 [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi… I've tried to manually enabling the beep with the steps in the e-mail thread I found: # echo -n 1 > /sys/class/sound/hwC0D2/subsystem_id # echo -n 1 > /sys/class/sound/hwC0D2/reconfig But it didn't work (the beep still goes through the pcspkr). I've tried to naively (I'm not a kernel hacker, so I was just guessing) add a new entry with the quirks beep_white_list by copying the entry for ASUS like this: diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 596ea2f..ca3ed12 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5183,6 +5183,7 @@ static void fillup_priv_adc_nids(struct hda_codec *codec, hda_nid_t *nid static struct snd_pci_quirk beep_white_list[] = { SND_PCI_QUIRK(0x1043, 0x829f, "ASUS", 1), + SND_PCI_QUIRK(0x8086, 0xd613, "INTEL", 1), {} }; But it didn't work either. Then I noticed, if I'm understanding the source code (sound/pci/hda/patch_realtek.c) and documentation (Documentation/sound/alsa/HD-Audio-Models.txt) right, that my card is not present in the models listing, but it worked fine in 2.6.34 (and previous) kernel(s). I would appreciate if somebody can give me some hints on how to get the beep back. Thank you. Here is some data about my card, please let me know (Cc me please) if you need any other information. # lspci -vvs00:1b.0 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 01) Subsystem: Intel Corporation Device d613 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: 64 bytes Interrupt: pin A routed to IRQ 44 Region 0: Memory at d0600000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee0f00c Data: 4181 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00 Status: NegoPending- InProgress- Capabilities: [130 v1] Root Complex Link Desc: PortNumber=0f ComponentID=00 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: 00000000fed1c000 Kernel driver in use: HDA Intel # cat /proc/asound/card0/codec#2 Codec: Realtek ALC662 rev1 Address: 2 Function Id: 0x1 Vendor Id: 0x10ec0662 Subsystem Id: 0x8086d613 Revision Id: 0x100101 No Modem Function Group found Default PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=2, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 Node 0x02 [Audio Output] wcaps 0x1d: Stereo Amp-Out Control: name="Front Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC662 rev1 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x19 0x19] Converter: stream=0, channel=0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x03 [Audio Output] wcaps 0x1d: Stereo Amp-Out Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x40 0x40] Converter: stream=0, channel=0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x04 [Audio Output] wcaps 0x1d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x19 0x19] Converter: stream=0, channel=0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="IEC958 Default PCM Playback Switch", index=0, device=0 Device: name="ALC662 rev1 Digital", type="SPDIF", device=1 Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0x160]: 44100 48000 96000 bits [0x1e]: 16 20 24 32 formats [0x1]: PCM Node 0x07 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x08 [Audio Input] wcaps 0x10011b: Stereo Amp-In Control: name="Capture Switch", index=1, device=0 Control: name="Capture Volume", index=1, device=0 Amp-In caps: ofs=0x09, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x89 0x89] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 1 0x23 Node 0x09 [Audio Input] wcaps 0x10011b: Stereo Amp-In Control: name="Capture Switch", index=0, device=0 Control: name="Capture Volume", index=0, device=0 Device: name="ALC662 rev1 Analog", type="Audio", device=0 Amp-In caps: ofs=0x09, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x15 0x15] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0x6]: 16 20 formats [0x1]: PCM Connection: 1 0x22 Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Front Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Front Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Line Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Line Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 9 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Front Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x02 0x0b Node 0x0d [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x03 0x0b Node 0x0e [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x04 0x0b Node 0x0f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x10 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x12 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001003c: IN OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x01014410: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x0c Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00010034: IN OUT EAPD Detect EAPD 0x2: EAPD Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x0d Node 0x16 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00000034: IN OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x0e Node 0x17 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Control: name="Mic Boost", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00001734: IN OUT Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x01a19830: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 1 0x0e Node 0x19 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Control: name="Front Mic Boost", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000173c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x02a19931: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0x1 Misc = NO_PRESENCE Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 2 0x0c* 0x0e Node 0x1a [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00000034: IN OUT Detect Pin Default 0x0181303f: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue DefAssociation = 0x3, Sequence = 0xf Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Connection: 1 0x0d Node 0x1b [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000173c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x0221451f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0xf Misc = NO_PRESENCE Pin-ctls: 0xc0: OUT HP VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 2 0x0c 0x0e* Node 0x1c [Pin Complex] wcaps 0x400001: Stereo Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x1d [Pin Complex] wcaps 0x400000: Mono Pincap 0x00000020: IN Pin Default 0x4004c601: [N/A] Line Out at Ext N/A Conn = RCA, Color = UNKNOWN DefAssociation = 0x0, Sequence = 0x1 Pin-ctls: 0x20: IN Node 0x1e [Pin Complex] wcaps 0x400300: Mono Digital Pincap 0x00000010: OUT Pin Default 0x99430120: [Fixed] SPDIF Out at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0x2, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x06 Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono Processing caps: benign=0, ncoeff=12 Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Input Source", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 10 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x0b Node 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Input Source", index=1, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 10 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x0b Node 0x24 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x25 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x26 [Vendor Defined Widget] wcaps 0xf00000: Mono -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Novocaine for the soul you better give me something to fill the hole before I sputter out

2 6