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

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

Re: [alsa-devel] [PATCH] Fix request_irq error handling
by Ash Willis 16 Jul '07

16 Jul '07

Hah, um, ignore me. It seems that my c needs some work ;) In if(some_expression), I always though it is true if the expression is > 0, not != 0. If anything, that was a CodingStyle patch because it lets us see exactly what we're getting from request_irq but I can see that it is totally unnecessary :) > ----- Original Message ----- > From: "Ash Willis" <ashwillis(a)programmer.net> > To: alsa-devel(a)alsa-project.org > Subject: [alsa-devel] [PATCH] Fix request_irq error handling > Date: Sat, 14 Jul 2007 02:29:19 -0500 > > > request_irq returns 0 on success and a negative code on failure. > Many ALSA drivers incorrectly check for failure by testing for a > positive code instead of a negative one. > > Signed-Off-By: Ash Willis <ashwillis(a)programmer.net> > > > -- > We've Got Your Name at http://www.mail.com! > Get a FREE E-mail Account Today - Choose From 100+ Domains > << request_irq_error_handling.patch >> > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains

2 1

Re: [alsa-devel] No sound on Medion laptop (intel 82801G)
by albox＠free.fr 16 Jul '07

16 Jul '07

I have added a note for this bug on : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3160 I'm not really sure but it seems that the file /etc/modprobe.d/alsa-base is not loaded. http://ubuntuforums.org/showthread.php?p=3026300#post3026300 Any idea ? Thanks

1 0

[alsa-devel] Install of alsa 1.0.14.final on Fedora 7
by stan 15 Jul '07

15 Jul '07

On Fri, 13 Jul 2007 08:53:47 -0700 tdavis(a)dsl-only.net wrote: > For RPM based systems, I have a build environment for the drivers, > libs, and utils packages at > http://members.dsl-only.net/~tdavis/my-build.tar.bz2. You need to > be root to build them, but they won't interfere with your rpm > distribution. THe driver rpm will also make a backup of your > current drivers prior to installation. > > Tobin > Hi Tobin, I unpacked the archive and typed make. It created 4 RPMs. Two of them installed, alsa-lib and alsa-lib-devel. When I run a test on the drivers rpm, there are conflicts with the kernel headers already on the box. And I have no sound now, except in the audio configuration screen which is using the 14.rc3 packages. The packages are named with rh7 instead of fc7 as well. Do I have to run make install to get everything working, or is the header incompatability in the drivers a show stopper? Thanks.

2 5

[alsa-devel] MOTU PCI-424
by Per Eriksson 14 Jul '07

14 Jul '07

Hello, After talking to Jonathan Woithe about the development done to support MOTUs product families, Jonathan and I have reached the conclusion that ALSA support for the PCI-424 series of cards would mean a great benefit for Linux users to get high quality audio at a fair price. The PCI-424 card is used to drive the following products: MOTU 2408mk3 MOTU HD192 MOTU 24I/O The work will start this autumn, as soon as I get everything set-up, and the progress will be published on https://erinet.se/alsa/motu_pci_424/pci-424 specification.pdf The actual driver will for me be a later issue to solve, I hope to gather some understanding by reading the list and look through the releases. However, I would like some more information on how the Matrix is supposed to be used in the wiki system. Are the vendor pages only for supported devices, or also for devices concidered for being supported? Thanks, Per

1 0