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

[alsa-devel] Re-uploaded patch for bug #2708
by Nicola Fagnani 19 Jul '07

19 Jul '07

I re-uploaded the patch with the requested changes some time ago, and I was wondering if there is still something wrong with it. Thanks Nicola Fagnani

2 1

[alsa-devel] underrun observed when aplay is used with mmap
by Pharaoh . 19 Jul '07

19 Jul '07

Hi , Finally I have got my driver working and now testing it using aplay. I am able to play a song without getting any underruns when I use read/write mode but when I use mmapped mode I get underrun warnings. After this if I use read/write mode again then I observe 1 warning of underrun. Any idea what could be wrong? I know why underruns occur etc. Does it have to do with mmapped mode? I dont think so... Here is the log. # aplay -Dplughw:0,0 --rate=44100 --format=s16 --channels=2 --mmap 44.wav Playing WAVE '44.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least 0.384 ms long) underrun!!! (at least 0.118 ms long) underrun!!! (at least 0.124 ms long) underrun!!! (at least 0.117 ms long) underrun!!! (at least 0.121 ms long) underrun!!! (at least 0.128 ms long) underrun!!! (at least 0.116 ms long) underrun!!! (at least 0.121 ms long) underrun!!! (at least 0.121 ms long) underrun!!! (at least 0.125 ms long) ....... and it goes on till the song finishes. And after this I play without using mmap and log says.. # aplay -Dplughw:0,0 --rate=44100 --format=s16 --channels=2 44.wav Playing WAVE '44.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least 516.424 ms long) and then the song plays without any underrun. -pharaoh.

2 1

[alsa-devel] cs46xx thinkpad resume fix - #bug1946
by Pavel Kysilka 19 Jul '07

19 Jul '07

Hi, attached patch fix resume on thinkpad notebooks with cs46xx chip. Tested with Thinkpad A21m. Patch is opposite latest linus git 2.6.22. Bug #1946 may be closed. Signed-off-by: Pavel Kysilka <pavelk(a)bsys.cz> Pavel Kysilka ________ Information from NOD32 ________ This message was checked by NOD32 Antivirus System for Linux Mail Servers. http://www.eset.com

3 6

[alsa-devel] PS3 - Surround sound on SPDIF set-up
by gt bradley 19 Jul '07

19 Jul '07

Hi, I've been beating my had against this for several weeks now. (started with fedora 6, tried adding in the plugings etc (version 1.0.12) -- also tried upgrading to the current 1.0.14 version, without success (couldn't produce surround-sound on teh spdif output). I have now switched to fedorea 7 and was able to have rythmbox play surround sound via spdif, but have since lost that ability. (but I'm convinced the hardware and low-level drivers support it). In order to limit the number of moving parts, I have reduced to just trying to get speaker-test to play on all 6 speakers. from pirut & I have alsa-lib 1.0.14-0.4.rc3.fc7.ppc(64) and alsa-utils 1.0.14-0.7.rc2.fc7.ppc The default install has no asound.conf file. (attempts to create a "better" one didn't improve the situation). I do not see a file matching the ps3 device in etc/alsa/cards nor etc/alsa/pcm, but I have not found any documentation on adding entries to the above directories. [root@ps3 pcm0p]# cat /proc/asound/card0/pcm0p/info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: SPDIF name: SPDIF subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 [root@ps3 ~]# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PS3 [PS3], device 0: SPDIF [SPDIF] Subdevices: 1/1 Subdevice #0: subdevice #0 [root@ps3 ~]# aplay -L null Discard all samples (playback) or generate zero samples (capture) [root@ps3 ~]# amixer [root@ps3 ~]# amixer scontrols [root@ps3 ~]# speaker-test -c 6 speaker-test 1.0.14rc2 Playback device is default Stream parameters are 48000Hz, S16_BE, 6 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 4096 to 8192 Period size range from 256 to 256 Using max buffer size 8192 Periods = 4 was set period_size = 256 was set buffer_size = 8192 0 - Front Left 4 - Center 1 - Front Right 3 - Rear Right 2 - Rear Left 5 - LFE Time per period = 17.821324 * above test only produces sound on channels 0 & 1. xmms produces no sound and emits the following: ** WARNING **: alsa_setup_mixer(): Failed to find mixer element: PCM Is it possible to get some help/pointers in the right direction? thanks GT* *

4 7

Re: [alsa-devel] ALSA driver for RealTek ALC268 chip
by Jonathan Woithe 18 Jul '07

18 Jul '07

Hi Amitay Amitay Isaacs (A.Isaacs(a)adfa.edu.au) wrote: > I found your names from the ALSA RealTek driver available for download > on the realtek website. Unfortunately the driver package does not have > support for the ALC268 chip. > > I have an ACER laptop with ALC268 HDA sound and would like to run linux > on it. > > Is the ALC268 chip driver available yet? Even the alpha/test version? Firstly, please submit queries like this to the ALSA development list. While I'm not fussed, other developers may not respond to emails sent only to their private addresses. It also means you don't have to guess who would be the most appropriate person to ask. Consequently I have added alsa-devel to the CC of this email. It would probably not take a lot of effort to add support for the ALC268 chip given that the ALC260 and ALC262 are supported. Furthermore, it seems that some work has already gone into this - see for example https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104 So I would say that ALC268 support is being worked on. Pshou can probably give more details or provide further assistance. Note that my involvement in the ALSA RealTek driver was limited to the extended ALC260 support I added to take full advantage of this chip in my laptop. I don't have access to machines with other Realtek chips in them and so I'm not in the best position to provide direct assistance for other chips. Regards jonathan

1 0

[alsa-devel] Cirrus Logic CS4270 support coming soon
by Timur Tabi 18 Jul '07

18 Jul '07

Hi Everyone, I just wanted to let everyone know that I will soon be submitting an ASoC driver for the Cirrus Logic CS4270 codec. I have the driver working in-house on an older version of ALSA. As soon as I finish work on my current project, I will clean up the driver, update to the latest code, and submit it. If anyone is using this codec on their hardware, please let me know. The CS4270 supports many different configurations, but my board only enables some of them.

1 0

[alsa-devel] substream->private_data == NULL in hw_params
by Florian Demski 17 Jul '07

17 Jul '07

Hi there, after many reboots I finally fixed an error in a driver but I am not sure if there ain't an underlying problem which causes this error. The initialization is done with struct snd_pcm *pcm; int err; if((err = snd_pcm_new(chip->pod->line6.card, (char *)chip->pod->line6.devname, 0, 1, 1, &pcm)) < 0) return err; pcm->private_data = chip; pcm->private_free = pod_cleanup_pcm; chip->pcm = pcm; However in hw_param, substream->private_data is NULL and I have to get the right value with this construct: static int snd_pod_capture_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *hw_params) { int ret; struct snd_pod_pcm *chip = snd_pcm_substream_chip(substream); /* -- Florian Demski [FD] */ /* don't ask me why, but this fixes the bug on my machine */ if ( chip == NULL ) { if ( substream->pcm == NULL ) return -ENOMEM; if ( substream->pcm->private_data == NULL ) return -ENOMEM; substream->private_data = substream->pcm->private_data; chip = snd_pcm_substream_chip( substream ); } /* -- [FD] end */ Somehow only my machine produces this error, I tried switching off SMP and PREEMPT, but with no other result. Or is this possibly an (undocumented) feature in alsa? I'd be happy if actually some of you experienced guys might take a look at that driver: SVN https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/trunk Browse https://line6linux.svn.sourceforge.net/viewvc/line6linux/driver/trunk/ Thanks in advance, Florian

2 1

[alsa-devel] [PATCH] hda: Enable SPDIF in/out on some stac9205 boards
by Matthew Ranostay 17 Jul '07

17 Jul '07

Added support for some boards with SPDIF in/out, and cleaned up the GPIO enable function. --- Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> diff -r 631a50e624df pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Mon Jul 16 11:01:30 2007 +0200 +++ b/pci/hda/patch_sigmatel.c Mon Jul 16 16:34:46 2007 -0400 @@ -44,6 +44,7 @@ enum { enum { STAC_9205_REF, + STAC_M43xx, STAC_9205_MODELS }; @@ -218,7 +219,6 @@ static hda_nid_t stac9205_pin_nids[12] = 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x14, 0x16, 0x17, 0x18, 0x21, 0x22, - }; static int stac92xx_dmux_enum_info(struct snd_kcontrol *kcontrol, @@ -773,7 +773,8 @@ static unsigned int ref9205_pin_configs[ }; static unsigned int *stac9205_brd_tbl[STAC_9205_MODELS] = { - ref9205_pin_configs, + [STAC_REF] = ref9205_pin_configs, + [STAC_M43xx] = NULL, }; static const char *stac9205_models[STAC_9205_MODELS] = { @@ -784,6 +785,10 @@ static struct snd_pci_quirk stac9205_cfg /* SigmaTel reference board */ SND_PCI_QUIRK(PCI_VENDOR_ID_INTEL, 0x2668, "DFI LanParty", STAC_9205_REF), + SND_PCI_QUIRK(PCI_VENDOR_ID_INTEL, 0x01f8, + "Dell Precision", STAC_M43xx), + SND_PCI_QUIRK(PCI_VENDOR_ID_INTEL, 0x01ff, + "Dell Precision", STAC_M43xx), {} /* terminator */ }; @@ -813,48 +818,52 @@ static int stac92xx_save_bios_config_reg return 0; } +static void stac92xx_set_config_reg(struct hda_codec *codec, hda_nid_t pin_nid, unsigned int pin_config) +{ + int i; + snd_hda_codec_write(codec, pin_nid, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_0, + pin_config & 0x000000ff); + snd_hda_codec_write(codec, pin_nid, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_1, + (pin_config & 0x0000ff00) >> 8); + snd_hda_codec_write(codec, pin_nid, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_2, + (pin_config & 0x00ff0000) >> 16); + snd_hda_codec_write(codec, pin_nid, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, + pin_config >> 24); + i = snd_hda_codec_read(codec, pin_nid, 0, + AC_VERB_GET_CONFIG_DEFAULT, + 0x00); + snd_printdd(KERN_INFO "hda_codec: pin nid %2.2x pin config %8.8x\n", pin_nid, i); +} + static void stac92xx_set_config_regs(struct hda_codec *codec) { int i; struct sigmatel_spec *spec = codec->spec; - unsigned int pin_cfg; - - if (! spec->pin_nids || ! spec->pin_configs) - return; - - for (i = 0; i < spec->num_pins; i++) { - snd_hda_codec_write(codec, spec->pin_nids[i], 0, - AC_VERB_SET_CONFIG_DEFAULT_BYTES_0, - spec->pin_configs[i] & 0x000000ff); - snd_hda_codec_write(codec, spec->pin_nids[i], 0, - AC_VERB_SET_CONFIG_DEFAULT_BYTES_1, - (spec->pin_configs[i] & 0x0000ff00) >> 8); - snd_hda_codec_write(codec, spec->pin_nids[i], 0, - AC_VERB_SET_CONFIG_DEFAULT_BYTES_2, - (spec->pin_configs[i] & 0x00ff0000) >> 16); - snd_hda_codec_write(codec, spec->pin_nids[i], 0, - AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, - spec->pin_configs[i] >> 24); - pin_cfg = snd_hda_codec_read(codec, spec->pin_nids[i], 0, - AC_VERB_GET_CONFIG_DEFAULT, - 0x00); - snd_printdd(KERN_INFO "hda_codec: pin nid %2.2x pin config %8.8x\n", spec->pin_nids[i], pin_cfg); - } -} - -static void stac92xx_enable_eapd(struct hda_codec *codec) -{ - /* Configure GPIO0 as output */ + if (!spec->pin_configs) + return; + + for (i=0; i < spec->num_pins; i++) + stac92xx_set_config_reg(codec, spec->pin_nids[i], + spec->pin_configs[i]); +} + +static void stac92xx_enable_gpio_mask(struct hda_codec *codec,int gpio_mask,int gpio_data) +{ + /* Configure GPIOx as output */ snd_hda_codec_write(codec, codec->afg, 0, - AC_VERB_SET_GPIO_DIRECTION, 0x00000001); - /* Configure GPIO0 as CMOS */ + AC_VERB_SET_GPIO_DIRECTION, gpio_mask); + /* Configure GPIOx as CMOS */ snd_hda_codec_write(codec, codec->afg, 0, 0x7e7, 0x00000000); - /* Assert GPIO0 high */ + /* Assert GPIOx */ snd_hda_codec_write(codec, codec->afg, 0, - AC_VERB_SET_GPIO_DATA, 0x00000001); - /* Enable GPIO0 */ + AC_VERB_SET_GPIO_DATA, gpio_data); + /* Enable GPIOx */ snd_hda_codec_write(codec, codec->afg, 0, - AC_VERB_SET_GPIO_MASK, 0x00000001); + AC_VERB_SET_GPIO_MASK, gpio_mask); } /* @@ -2233,7 +2242,7 @@ static int patch_stac927x(struct hda_cod } spec->multiout.dac_nids = spec->dac_nids; - stac92xx_enable_eapd(codec); + stac92xx_enable_gpio_mask(codec, 0x00000001, 0x00000001); /* GPIO0 High = Enable EAPD */ err = stac92xx_parse_auto_config(codec, 0x1e, 0x20); if (!err) { @@ -2258,7 +2267,7 @@ static int patch_stac9205(struct hda_cod static int patch_stac9205(struct hda_codec *codec) { struct sigmatel_spec *spec; - int err; + int err, gpio_mask, gpio_data; spec = kzalloc(sizeof(*spec), GFP_KERNEL); if (spec == NULL) @@ -2295,8 +2304,19 @@ static int patch_stac9205(struct hda_cod spec->mixer = stac9205_mixer; spec->multiout.dac_nids = spec->dac_nids; - stac92xx_enable_eapd(codec); - + + if (spec->board_config == STAC_M43xx) { + /* Enable SPDIF in/out */ + stac92xx_set_config_reg(codec, 0x1f, 0x01441030); + stac92xx_set_config_reg(codec, 0x20, 0x1c410030); + + gpio_mask = 0x00000007; /* GPIO0-2 */ + gpio_data = 0x00000005; /* GPIO0 High = EAPD, GPIO1 Low = DRM, GPIO2 High = Headphone Mute */ + } + else + gpio_mask = gpio_data = 0x00000001; /* GPIO0 High = EAPD */ + + stac92xx_enable_gpio_mask(codec, gpio_mask, gpio_data); err = stac92xx_parse_auto_config(codec, 0x1f, 0x20); if (!err) { if (spec->board_config < 0) {

2 1

[alsa-devel] Input/output error - Confusion regarding period size and interrupts
by Pharaoh . 16 Jul '07

16 Jul '07

Hi The hardware I am working on expects 8K bytes to be DMAed before giving an interrupt. Only after a block of 8K bytes is DMAed, I get an end of the block interrupt and I enqueue next 8K bytes for processing. The params look like these: static snd_pcm_hardware_t snd_omap_alsa_playback = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_MMAP), .formats = (SNDRV_PCM_FMTBIT_S16_LE), .rates = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 ), .rate_min = 44100, .rate_max = 48000, .channels_min = 2, .channels_max = 2, .buffer_bytes_max = 8192*8, .period_bytes_min = 32, .period_bytes_max = 8 * 1024, .periods_min = 2, //ping pong buffer .periods_max = 128, .fifo_size = 0, }; I just copied it from another driver ;-). But now I am getting an input/output error after first block of data i.e. 8K bytes are DMAed. Does it have anything to do with the above struct? I have discussed this earlier too, but now attacking it once again after long gap. -pharaoh.

1 1

[alsa-devel] [Alsa-devel] xrun problem
by Gao, Jonathan 16 Jul '07

16 Jul '07

Hi, I am writing a PCM driver on a Soc for 2.6.10 kernel. The test code I'm using is from alsa-lib-1.0.6rc1/test/pcm.c. The runtime log gives me like this... ----------------------------------------------------------------- open callback: hw params callback: alloc result = 1, buffer bytes = 4608 /* --------- HW params ------------- */ format = 2, rate = 44100, channels= 2, period_size = 288, periods = 4, buffer_size = 1152 prepare callback /* --------- Runtime Info ---------- */ state = 1 (SNDRV_PCM_STATE_SETUP), hw_ptr = 0, appl_ptr = 0, avail_min = 288 avail_max = 0, hw_ptr_base = 0, hw_ptr_interrupt = 0 trigger callback: START Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 0, appl_ptr = 1152, avail_min = 288 avail_max = 0, hw_ptr_base = 0, hw_ptr_interrupt = 0 pointer callback: hw pointer: 288 (return value of pointer callback) Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 288, appl_ptr = 1152, avail_min = 288 avail_max = 288, hw_ptr_base = 0, hw_ptr_interrupt = 288 pointer callback: hw pointer: 576 (return value of pointer callback) Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 576, appl_ptr = 1152, avail_min = 288 avail_max = 576, hw_ptr_base = 0, hw_ptr_interrupt = 576 pointer callback: hw pointer: 864 (return value of pointer callback) Codec Do Copy: /* --------- Runtime Info ---------- */ state = 3 (SNDRV_PCM_STATE_RUNNING), hw_ptr = 864, appl_ptr = 1152, avail_min = 288 avail_max = 864, hw_ptr_base = 0, hw_ptr_interrupt = 864 pointer callback: hw pointer: 0 (return value of pointer callback) trigger callback: STOP prepare callback /* --------- Runtime Info ---------- */ state = 4 (SNDRV_PCM_STATE_XRUN), hw_ptr = 1152, appl_ptr = 1152, avail_min = 288 avail_max = 1152, hw_ptr_base = 1152, hw_ptr_interrupt = 1152 ----------------------------------------------------------------- The kernel hangs after prepare callback, from strace, I can see a endless ioctl(4, ..., ...) repeated. Does anyone have a few pointers on what is going wrong? Best Regards, Jonathan

2 1