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

[alsa-devel] [PATCH] hda/patch_sigmatel.c Panasonic CF-74 speaker output
by Kyler Laird 29 Feb '08

29 Feb '08

This patch causes ALSA to send sound to the speakers of a Panasonic CF-74 (Toughbook) instead of just its headphone jack. --kyler diff -Naur linux-2.6.24.1/sound/pci/hda/patch_sigmatel.c linux-2.6.24.1-ALSA_CF74/sound/pci/hda/patch_sigmatel.c --- linux-2.6.24.1/sound/pci/hda/patch_sigmatel.c 2008-02-08 14:55:30.000000000 -0500 +++ linux-2.6.24.1-ALSA_CF74/sound/pci/hda/patch_sigmatel.c 2008-02-11 12:05:11.824064617 -0500 @@ -2467,6 +2467,11 @@ spec->init = stac9200_core_init; spec->mixer = stac9200_mixer; + /* Kyler - fix for CF-74 speaker */ + spec->gpio_mask = 0x00000009; + spec->gpio_data = 0x00000000; + stac92xx_enable_gpio_mask(codec); + err = stac9200_parse_auto_config(codec); if (err < 0) { stac92xx_free(codec);

2 1

Re: [alsa-devel] How to set idle S/PDIF sample rate?
by Demian Martin 29 Feb '08

29 Feb '08

I noticed another big problem in my application relating to locking the system at 48 KHz in the background. If I set SPDIF to 44.1KHz on some playback software (Xine for example) between tracks the system briefly switches back to 48 KHz. This causes an audible pop as the external DAC tries to keep up with the rate change. I have not found a way to lock the system at a different rate (44100 for example) so this doesn't happen between tracks. This behavior is common to both the ICE1724 and the VT1708 drivers. -Demian Date: Thu, 28 Feb 2008 16:12:10 -0500 From: Matt Whitlock <matt(a)whitlock.name> Subject: Re: [alsa-devel] How to set idle S/PDIF sample rate? To: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)alsa-project.org Message-ID: <200802281612.11099.matt(a)whitlock.name> Content-Type: text/plain; charset="iso-8859-1" On Thursday, 28 February 2008 6:43:25 am Takashi Iwai wrote: > The driver code resets the format verb of the relevant widgets at > closing streams. This verb contains the sample rate, too. Maybe > keeping this would prevent the reset. > > The below is a test patch. Give it a try. Wow, fantastic. I will give this patch a try. I'll have to rebuild my kernel to disable the in-kernel ALSA code and build the ALSA module separately from the latest sources, but if this patch fixes things, that would be worth the effort. I'll get back to you. Thanks. -Matt

2 1

[alsa-devel] How to set idle S/PDIF sample rate?
by Matt Whitlock 28 Feb '08

28 Feb '08

When no programs have the sound hardware open, ALSA drives my Intel HDA's S/PDIF output with silence at 48000 Hz. How would I change this default so that the idle sample rate is 44100 Hz? The reason I ask is that my stereo receiver misses the first second or so of each song that I play as it switches from 48000 Hz to 44100 Hz. I understand that by switching the idle sample rate to 44100 Hz, I would have the same problem whenever playing a DVD, but I can much more happily accept the switching delay when starting DVDs than I can when starting music playback. I've tried everything, including replacing /usr/share/alsa/alsa.conf with a single PCM definition that outputs straight to hardware with "rate 44100", but still, whenever nothing is accessing the sound hardware, ALSA reverts to 48000-Hz silence. There must be a way to influence that, right? Alternatively, if ALSA would simply not output anything over S/PDIF when idle, my receiver could just stay at 44100 Hz, albeit unlocked since there would be no data stream at all. So this is also an acceptable solution to me, but I cannot find any way to make ALSA totally shut up when idle. It always wants to output silence. Interestingly, if I mute the IEC958 playback channel and then unmute it, my receiver reports no signal at all until I play a sound, and then after the sound finishes, my receiver reports that it is locked onto PCM at 48000 Hz. Seems kind of like a bug, doesn't it? Thanks to anyone who can lend some assistance.

3 10

[alsa-devel] [PATCH 0/2] Fixes to couple DAPM widget functions
by Jarkko Nikula 28 Feb '08

28 Feb '08

API change done by the commit 9af6d9562414568ecadf96aaef5b88e7e8b19821, "[ALSA] soc - Add support for passing kcontrols with events", doesn't change affected pxa machine and wm9712 drivers. These two patches are generated from master branch of linux-2.6-asoc tree but they apply to alsa git and alsa-kernel hg trees as well. I separated wm9712 to own patch since it is ok in asoc-v2-dev branch. There are other drivers as well with this error in asoc-v2-dev but I don't know are they already in progress? I can post a another patch to them if needed. -- Jarkko

3 6

[alsa-devel] Using ARRAY_SIZE macro when setting up ASoC audio map?
by Jarkko Nikula 28 Feb '08

28 Feb '08

Does an example patch to spitz below make any sense? Yep, noticed when forgot to add array terminator to own code :-) diff --git a/sound/soc/pxa/spitz.c b/sound/soc/pxa/spitz.c index d56709e..1cffcd3 100644 --- a/sound/soc/pxa/spitz.c +++ b/sound/soc/pxa/spitz.c @@ -268,8 +268,6 @@ static const char *audio_map[][3] = { /* line is connected to input 1 - no bias */ {"LINPUT1", NULL, "Line Jack"}, - - {NULL, NULL, NULL}, }; static const char *jack_function[] = {"Headphone", "Mic", "Line", "Headset", @@ -317,7 +315,7 @@ static int spitz_wm8750_init(struct snd_soc_codec *codec) } /* Set up spitz specific audio path audio_map */ - for (i = 0; audio_map[i][0] != NULL; i++) { + for (i = 0; i < ARRAY_SIZE(audio_map); i++) { snd_soc_dapm_connect_input(codec, audio_map[i][0], audio_map[i][1], audio_map[i][2]); }

3 5

Re: [alsa-devel] a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
by Robert Hancock 27 Feb '08

27 Feb '08

Avuton Olrich wrote: > With v2.6.24 my second ALSA sound device stopped working. > > After bisection it says this was the offending commit. > > a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit > commit a7839e960675b549f06209d18283d5cee2ce9261 > Author: Zhao Yakui <yakui.zhao(a)intel.com> > Date: Wed Nov 28 16:21:21 2007 -0800 > > PNP: increase the maximum number of resources > > On some systems the number of resources(IO,MEM) returnedy by PNP device is > greater than the PNP constant, for example motherboard devices. It brings > that some resources can't be reserved and resource confilicts. This will > cause PCI resources are assigned wrongly in some systems, and cause hang. > This is a regression since we deleted ACPI motherboard driver and use PNP > system driver. > > [akpm(a)linux-foundation.org: fix text and coding-style a bit] > Signed-off-by: Li Shaohua <shaohua.li(a)intel.com> > Signed-off-by: Zhao Yakui <yakui.zhao(a)intel.com> > Cc: Bjorn Helgaas <bjorn.helgaas(a)hp.com> > Cc: Thomas Renninger <trenn(a)suse.de> > Cc: <stable(a)kernel.org> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> > > The audio device is 00:1b.0 (see my lspci -vvv output), the other > audio device works fine. > > http://avuton.googlepages.com/v2.6-before (dmesg revision before) > http://avuton.googlepages.com/v2.6-after (dmesg broken revision) > http://avuton.googlepages.com/lspci-vvv > http://avuton.googlepages.com/config (from the broken revision) > http://avuton.googlepages.com/iomem > http://avuton.googlepages.com/ioports Here's why the driver fails to load: [ 31.133060] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 [ 31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0 [ 31.133197] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 31.133244] HDA Intel: probe of 0000:00:1b.0 failed with error -16 The iomem location of the HDA controller conflicts with this reservation by the BIOS: [ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved There was a patch floating around to ignore PnPACPI reservations which conflict with PCI BARs, which appears to be what's happening in this case. That patch originally worked for any board, but was later made specific to a certain Supermicro motherboard which had the sata_nv controller MMIO regions marked as reserved, preventing the driver from loading. We may need a more general solution. See: https://bugzilla.redhat.com/show_bug.cgi?id=313491

5 24

[alsa-devel] HDMI Multichannel LPCM/RAW Support/Status
by Dustin Kerstein 27 Feb '08

27 Feb '08

I was just curious if there is any planned support for multichannel LPCM/Raw audio for newer HDMI based chipsets. There are several matx boards with HDMI 1.1 and above compliance, which means they should be able to pass 8-channel LPCM audio. Also, in HDMI 1.3 and above, Bit Stream passing is supported, which actually should be easier, bandwidth wise, than LPCM. Multichannel PCM (above 2 channels) was never an issue because SPDIF lacked the bandwidth. After talking with some people in irc it seems as though the # of channels setting in Alsa is only one bit. Thanks. Dustin

2 2

Re: [alsa-devel] PATCH for alsa-info.sh - using mktemp for instead of hardcoded temp dir.
by Takashi Iwai 27 Feb '08

27 Feb '08

At Thu, 28 Feb 2008 02:42:20 +1000, Travis Place wrote: > > On Thu, 28 Feb 2008 2:39:16 am you wrote: > > At Thu, 28 Feb 2008 00:36:52 +1000, > > > > Travis Place wrote: > > > Email subject should explain well enough. > > > > I see some problems with this change: > > - it doesn't work if /tmp/alsainfo doesn't exist > > - temp directory isn't removed if --no-upload is given > > > > I think you should avoid --tempdir=xxx with mktemp. > > > > The output file name is another question. > > IMO, it'd be better to pass the output file name via a command line > > option, and put it on the home directory (e.g. ~/alsa-info.out) as > > default rather than /tmp. > > well, /tmp/alsainfo/ will exist, as we create it in the script.. its > $ALSAINFODIR .. the temp dir is then created inside that. It's created too late. And, if we create /tmp/alsainfo, there is little merit of mktemp as /tmp/alsainfo could be a symlink. Simply TEMPDIR should be what mktemp creates, and clean it up after quitting. > As for not being cleaned up, if --no-upload is specified, ill check that now.. > > Also, is outputting the resulting file to ~/ wise ? It's at least safer than the fixed filename on /tmp. I don't insist on this option, though. Anyway, --output-file=xxx would be a nice addition. > should this occur even if the result is uploaded, or only on > --no-upload ? I don't think it's needed when uploaded (except for any debugging reason). Just my $0.02. thanks, Takashi

2 1

[alsa-devel] PATCH for alsa-info.sh - using mktemp for instead of hardcoded temp dir.
by Travis Place 27 Feb '08

27 Feb '08

Email subject should explain well enough. -- Happiness is like peeing your pants. Everyone can see it, but only you can feel its warmth

2 2

[alsa-devel] new driver: channel alignment (was: 30mS interval problem)
by William Juul 27 Feb '08

27 Feb '08

Hello I am new to ALSA and trying to write a new driver for a ADC connected with PCM to an AVR32 on a NGW100 reference card provided by Atmel. I have the problem that different channels from the PCM stream comes in different positions in the WAV file. For example when I disable all but the first PCM channel on the ADC, I can see with an oscilloscope that there is only data in the first timeslot on the PCM data stream. But the data from this channel can occur in any of the 4 channels in the WAV file. This is consistent throughout the one capture/file, but in the next capture the data will occur in another channel in the WAV-file. How can I make sure that the data from one particular channel always occur in a fixed position in the WAV file? Best regards William Juul

1 0