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

Re: [alsa-devel] ALC268 auto-parsing
by Jonathan Woithe 17 Jan '08

17 Jan '08

Marco Schuster wrote: > I am a bit interested in how the Realtek Windows driver gets its pin > config. There IMO are two options: > a) it uses the bios autoconfig - as parsing this doesn't work in alsa > here, there must be something special in it > b) it uses a config file - it should be easy to get out the pin config. I have no concrete evidence for this but my feeling based on a poke around the windoze drivers a few years ago is that they were configured for the particular laptop by the manufacturer. This configuration information is not in an obvious location though - if they go this way it's either embedded within the driver itself or located in a binary format file somewhere. In both cases this makes it almost impossible to utilise. Regards jonathan

1 0

[alsa-devel] SNDRV_PCM_INFO_MMAP - what do I need for it?
by Timur Tabi 16 Jan '08

16 Jan '08

My 8610 ASoC driver has this: static const struct snd_pcm_hardware fsl_dma_hardware = { .info = SNDRV_PCM_INFO_INTERLEAVED, This means that MMAP is not enabled. I understand what MMAP is, but not from an ALSA driver perspective. If I change the above line to this: .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID, what does ALSA do differently? Do I need to define any new functions? From an application perspective, what is different? Also, does DMIX need MMAP support? -- Timur Tabi Linux kernel developer at Freescale

3 4

[alsa-devel] ALC268 auto-parsing
by Marco Schuster 16 Jan '08

16 Jan '08

Hi all, I am a bit interested in how the Realtek Windows driver gets its pin config. There IMO are two options: a) it uses the bios autoconfig - as parsing this doesn't work in alsa here, there must be something special in it b) it uses a config file - it should be easy to get out the pin config. Any opinions what is correct way? Marco

2 1

[alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
by Ondrej Zary 16 Jan '08

16 Jan '08

Hello, as hibernation (swsusp) started to work with my CPU, I found that my Turtle Beach Malibu stops working after resume from hibernation. It's caused by fact that the card is not enabled on the pnp layer during resume - and thus card registers are inaccessible (reads return FFs, writes go nowhere). During resume, pnp_bus_resume() in drivers/pnp/driver.c is called for each pnp device. This function calls pnp_start_dev() only when the PNP_DRIVER_RES_DO_NOT_CHANGE bit is NOT seting pnp_drv->flags. But the cs4236 driver in sound/isa/cs423x/cs4236.c explicitly sets the .flags to PNP_DRIVER_RES_DISABLE - it's value is 3 and that includes PNP_DRIVER_RES_DO_NOT_CHANGE bit. The same .flags value is present in many of the ALSA ISA sound drivers. Removing that .flags line caused this to appear inlog when loading snd_cs4236 module: CS4236+ WSS PnP manual resources are invalid, using auto config CS4236+ CTRL PnP manual resources are invalid, using auto config CS4236+ MPU401 PnP manual resources are invalid, using auto config and the sound now works after resume! So the question is: why is this line present? Is this a bug? What's the correct fix? -- Ondrej Zary

6 23

[alsa-devel] TLV support for PCM (in driver)
by Jaroslav Kysela 16 Jan '08

16 Jan '08

Hi, I am actually thinking to add TLV support to each PCM stream. The reason is to obtain various "static" information from the driver without even opening the PCM stream. The current API lack: a) get channel info / name / position (e.g. Front Left Speaker) - not sure how to handle multichannel cards - I'm sure that this is something to be user configurable b) get possible channels c) get possible formats d) various inter-PCM-device constraint description (e.g. if S/PDIF PCM stream can be used with analog etc.) e) eventually more information for device name hinting for userspace (current problems for HDA, AC97, USB devices are that we have only one .conf file per driver covering all hardware - we need to detect real device capabilities and show only devices which can be really used) Opinions? Jaroslav ----- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.

2 3

[alsa-devel] hdsp driver broken for Multiface II Rev 35
by Andreas Degert 16 Jan '08

16 Jan '08

Hi folks, changeset 5326 from 2007/08/31 broke the driver for this card revision. There was an older thread about this problem which didn't seem to come to a conclusion. ioctl SNDRV_HDSP_IOCTL_GET_VERSION returns io_type = 1 (Multiface) firmware_rev = 0x35 which is correct. The old code for hdsp_playback_to_output_key looks like this: static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->firmware_rev) { case 0xa: return (64 * out) + (32 + (in)); case 0x96: case 0x97: return (32 * out) + (16 + (in)); default: return (52 * out) + (26 + (in)); } } For my card the result is "(52 * out) + (26 + (in))". The new code looks like this: static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->io_type) { case Multiface: case Digiface: default: return (64 * out) + (32 + (in)); case H9632: return (32 * out) + (16 + (in)); case H9652: return (52 * out) + (26 + (in)); } } which gives the wrong result "(64 * out) + (32 + (in))". The old code returns this when firmware_rev == 0xa, which might be the revision of the older Multiface (not Multiface II). I changed the code to static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->io_type) { case Multiface: case Digiface: default: if (hdsp->firmware_rev == 0xa) return (64 * out) + (32 + (in)); else return (52 * out) + (26 + (in)); case H9632: return (32 * out) + (16 + (in)); case H9652: return (52 * out) + (26 + (in)); } } Another possibility would be to go back to the old version of the code and only make changes for io_type H9632/H9652 with new firmware revisions: static int hdsp_playback_to_output_key (struct hdsp *hdsp, int in, int out) { switch (hdsp->firmware_rev) { case 0xa: return (64 * out) + (32 + (in)); case 0x96: case 0x97: return (32 * out) + (16 + (in)); } switch (hdsp->io_type) { case H9632: return (32 * out) + (16 + (in)); case Multiface: case H9652: return (52 * out) + (26 + (in)); case Digiface: ??? is there a Digiface with revision != 0xa ??? default: ??? HDSP_IO_Type Undefined ??? } } Similar changes must be made to hdsp_input_to_output_key. Does anyone know which firmware revision exist for which card (io_type) ? thank you Andreas Degert

3 4

Re: [alsa-devel] Bug#436723: Playing sound hands on powerbook3, 5 with 2.6.21-2 kernel
by maximilian attems 16 Jan '08

16 Jan '08

[ adding alsa upstream on cc ] On Mon, Jan 14, 2008 at 12:21:11AM +0100, th.huth(a)googlemail.com wrote: > > Please have a look at > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/87652/co… > and the corresponding patch to see wether this patch solves this sound > issue. woow, i thought to fire up "try newer kernel", but your patch still applies to current linus git: ~/src/linux-2.6$ patch -p0 --dry-run < ~/pmac.c.diff patching file sound/ppc/pmac.c Hunk #5 succeeded at 868 (offset -24 lines). Hunk #6 succeeded at 1207 (offset -47 lines). so bringing that to upstream alsa radar. -- maks

3 3

[alsa-devel] I/O possible
by Mihaela Vitalariu 16 Jan '08

16 Jan '08

Hello everyone! I am coding a Linux sound application using the PCM interface. It plays fine but at unexpected intervals i sometimes get a SIGIO directly in my program, which exits printing the message "I/O possible". What can be happening? Any help would be greatly appreciated. Simbasaurus.

1 0

[alsa-devel] hda_intel messages showing up in dmesg
by Andrew Paprocki 16 Jan '08

16 Jan '08

I'm seeing these messages show up in dmesg every once in a while. If anyone has ideas as to why I'd be seeing these, I can help track down any potential problems. I am having problems where ALSA playback stutters while using the OSS-compatibility layer for ALSA works fine with no stuttering. After inserting the module w/ model=6stack-dig: ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16 hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x225f0d00 hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x225f0d00 ACPI: PCI Interrupt 0000:01:05.2[B] -> GSI 19 (level, low) -> IRQ 18 hda-intel: Invalid position buffer, using LPIB read method instead. After inserting the module w/ no model defined: ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16 hda_codec: Unknown model for ALC883, trying auto-probe from BIOS... ACPI: PCI Interrupt 0000:01:05.2[B] -> GSI 19 (level, low) -> IRQ 18 hda-intel: Invalid position buffer, using LPIB read method instead. I've only seen the azx_get_response messages print out once. I see the LPIB message print out every once in a while. Thanks, -Andrew

2 1

[alsa-devel] [PATCH] remove 11c1:1040 from patch_si3054.c id list
by Vasily Khoruzhick 16 Jan '08

16 Jan '08

Codec with id 11c1:1040 sitting on hda bus isn't si3054-compatible. It should be removed from patch_si3054.c id list

2 1