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

Re: [alsa-devel] No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)
by Andreas Nüßlein 06 Jul '09

06 Jul '09

On Monday 06 July 2009 15:39:09 you wrote: > At Mon, 6 Jul 2009 14:59:09 +0200, > > Andreas Nüßlein wrote: > > On Monday 06 July 2009 14:44:56 you wrote: > > > At Mon, 6 Jul 2009 12:19:11 +0200, > > > > > > Andreas Nüßlein wrote: > > > > On Monday 06 July 2009 12:08:11 you wrote: > > > > > At Mon, 6 Jul 2009 11:45:07 +0200, > > > > > > > > > > Andreas Nüßlein wrote: > > > > > > [1 <text/plain; iso-8859-1 (quoted-printable)>] > > > > > > > > > > > > On Monday 06 July 2009 09:23:07 you wrote: > > > > > > > At Sun, 5 Jul 2009 12:30:52 +0200, > > > > > > > > > > > > > > > however i was able to reproduce the "bad kfree", by changing > > > > > > > > the volumes in alsamixer. it always gave me the same "called > > > > > > > > from ID" so i tried "while (true) do cat /proc/kallsyms | > > > > > > > > grep ffffffffa001b08b; done" and then changed the volume, but > > > > > > > > the grep never returned anything, dmesg of course got more > > > > > > > > and more of those kfree-errors. > > > > > > > > > > > > > > The address won't match exactly in /proc/kasllsyms. > > > > > > > But you can guess which function by address. First sort > > > > > > > /proc/kallsyms then check the position that fits with the given > > > > > > > address. > > > > > > > > > > > > > > > > > > > > > Takashi > > > > > > > > > > > > well i'm not really sure _I_ can guess ;) i guess it's either > > > > > > "t snd_ctl_ioctl [snd]" or "t snd_ctl_ioctl_compat > > > > > > [snd]". > > > > > > > > > > > > here are the greps, "snd: bad kfree (called from > > > > > > ffffffffa001b08b)" being the error: > > > > > > > > > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001a > > > > > > ffffffffa001a045 t snd_ctl_elem_info [snd] > > > > > > ffffffffa001a17a t copy_ctl_value_from_user [snd] > > > > > > ffffffffa001a34f t snd_ctl_elem_read [snd] > > > > > > ffffffffa001a413 t snd_ctl_elem_write [snd] > > > > > > ffffffffa001a515 T snd_ctl_rename_id [snd] > > > > > > ffffffffa001a5b5 T snd_ctl_activate_id [snd] > > > > > > ffffffffa001a66e T snd_ctl_remove_id [snd] > > > > > > ffffffffa001a6ed T snd_ctl_add [snd] > > > > > > ffffffffa001a6ed u snd_ctl_add [snd_hda_codec] > > > > > > ffffffffa001a947 t snd_ctl_elem_add [snd] > > > > > > ffffffffa001abd3 t snd_ctl_elem_add_compat [snd] > > > > > > ffffffffa001ad37 t snd_ctl_elem_add_user [snd] > > > > > > ffffffffa001ada6 t snd_ctl_ioctl [snd] > > > > > > > > > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001b > > > > > > ffffffffa001b4c4 t snd_ctl_ioctl_compat [snd] > > > > > > ffffffffa001b9ba T snd_ctl_new1 [snd] > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec] > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec_cirrus] > > > > > > ffffffffa001bb30 T snd_pci_quirk_lookup [snd] > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_codec] > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_intel] > > > > > > ffffffffa001bb93 T snd_verbose_printk [snd] > > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_hda_codec] > > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_hda_intel] > > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_hwdep] > > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_pcm] > > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_timer] > > > > > > ffffffffa001bc7b T release_and_free_resource [snd] > > > > > > ffffffffa001bcd4 t snd_device_register_all [snd] > > > > > > ffffffffa001bd76 T snd_device_register [snd] > > > > > > ffffffffa001bd76 u snd_device_register [snd_pcm] > > > > > > ffffffffa001be67 t snd_device_disconnect [snd] > > > > > > ffffffffa001bf5d t snd_device_disconnect_all [snd] > > > > > > > > > > > > > > > > > > hope that helps =) > > > > > > > > > > Maybe the patch below can give a better clue. > > > > > This will spew stack traces when this error is triggered. Don't be > > > > > surprised. > > > > > > > > oki - new output =) > > > > > > > > > > > > [16306.365597] snd: bad kfree (called from ffffffffa001b08f) > > > > [16306.365604] Pid: 26533, comm: alsamixer Tainted: P W > > > > 2.6.30.1 #2 [16306.365610] Call Trace: > > > > [16306.365632] [<ffffffffa001b08f>] ? snd_ctl_ioctl+0x2e5/0x71e > > > > [snd] [16306.365645] [<ffffffff802b8bf9>] ? > > > > __inc_zone_state+0x20/0x9b [16306.365655] [<ffffffff802cfffc>] ? > > > > alloc_page_vma+0x197/0x1e1 [16306.365666] [<ffffffff802afb63>] ? > > > > __lru_cache_add+0x93/0xdd [16306.365676] [<ffffffff802ea651>] ? > > > > vfs_ioctl+0x35/0x97 > > > > [16306.365686] [<ffffffff802eaae5>] ? do_vfs_ioctl+0x432/0x482 > > > > [16306.365696] [<ffffffff806336bf>] ? _spin_lock_irqsave+0x28/0x5c > > > > [16306.365705] [<ffffffff80247e22>] ? do_page_fault+0x272/0x29e > > > > [16306.365715] [<ffffffff802eab82>] ? sys_ioctl+0x4d/0x81 > > > > [16306.365726] [<ffffffff8022af2b>] ? system_call_fastpath+0x16/0x1b > > > > > > Try the very latest alsa-driver-unstable snapshot. > > > This bug should have been fixed, also possibly with CS420x parser > > > bug, too. > > > > > > > > > Takashi > > > > so dmesg knows the following: > > > > [18042.848549] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 23 > > (level, low) -> IRQ 23 [18042.848623] HDA Intel 0000:00:08.0: setting > > latency timer to 64 [18043.007568] ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd > >a/hda_codec.c:3851: autoconfig: line_outs=1 (0xa/0x0/0x0/0x0/0x0) > > [18043.007584] ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd > >a/hda_codec.c:3855: speaker_outs=1 (0xb/0x0/0x0/0x0/0x0) [18043.007596] > > ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd > >a/hda_codec.c:3859: hp_outs=1 (0x9/0x0/0x0/0x0/0x0) [18043.007608] ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd > >a/hda_codec.c:3860: mono: mono_out=0x0 [18043.007618] ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd > >a/hda_codec.c:3863: dig-out=0x10/0x15 [18043.007628] ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd > >a/hda_codec.c:3871: inputs: mic=0xd, fmic=0x0, line=0xc, fline=0x0, > > cd=0x0, aux=0x0 > > [18043.007642] ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd > >a/hda_codec.c:3873: dig-in=0x12 [18043.121187] ALSA > > /home/nutz/tmp/alsa/alsa-driver-unstable/acore/control.c:337: control > > 2:0:0:IEC958 Capture Switch:0 is already present [18043.121204] > > hda_codec: cannot build controlsfor #0 (error -16) > > > > > > and i don't have a mixer anymore ;) > > It's because your chip was uninitialized by BIOS or whatever, the > another state you got sometimes. > > Now fixed in the driver to force to initialize pins. > Try the latest tarball again. > > > Takashi TAKASHIIIIIIIIIIIII =) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! digital out is working... i tried the new snapshot (eventhough, as you said my subsystem is now again uninitialized) and i got back the alsamixer- capabilities; i ran mplayer test.wav and started playing around with the mixer-controls. when i reached IEC958 and turned it on, my out-jack began to glow red =) so that works. i rushed over to my dorm-partners speakersystem and plugged it in - voila that actually works! (i tried a DTS video with mplayer -vc hwdts ) that is SO cool =) however as you might've figured out, analog out is not working, yet ;( i tried the built-in speakers as well as the headphones (and of course all the devices from aplay -L again) aplay -l shows 2 devices now though: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: Cirrus Analog [Cirrus Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 1: Cirrus Digital [Cirrus Digital] Subdevices: 1/1 Subdevice #0: subdevice #1 should i try to reboot the machine to get back the other subsystem id? or is that irrelevant now? thanks so much =) andy

2 1

[alsa-devel] snd_pcm_info_alloca ( ptr) allocate an INVALID snd_pcm_info_t
by Guilherme Longo 06 Jul '09

06 Jul '09

Hi all! Mates, I was looking for a reasonable explanation on why the functions *_alloca as snd_pcm_info_alloca allocates an INVALID snd_pcm_info_t?? At my point of view this function reserves memory for the allocation of snd_pcm_info_t and so it is a real space reservation. I don't want get a wrong understanding and as long as there is no information regarding this, I am here asking! Thanks in advanced!

2 1

[alsa-devel] [RFC] Alsa mixer over serial port
by Janusz Krzysztofik 05 Jul '09

05 Jul '09

Hi, I'm currently working on ASoC driver for a voice modem codec chip (Conexant CX20442) available on ARM OMAP amsdelta board. The driver should provide some controls for switching audio path from handset to speakerphone and back, changing volume etc. The only way of controlling some aspects of the codec that I know of is over an acompanying voice modem chip (CX81801) with AT voice commands. The modem can be accessed over a platform serial device. I can see two ways of getting this working: 1) add a new line discipline that would take control over the serial line and convert it to an alsa mixer, 2) create a low level driver that would replace standard serial stuff completely (like snd-serial-u16550 does, for example). Please advise which one is better. Thanks, Janusz

2 2

[alsa-devel] [PATCH] ASoC: Remove use of hw_read from TLV320AIC3x driver
by Mark Brown 05 Jul '09

05 Jul '09

The TLV320AIC3x driver is currently the only user of the CODEC hw_read operation and is jumping through some hoops in order to do so. In order to support future refactoring to make the hw_read operation more usable unwrap the usage in this driver to avoid its use. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- I don't have any hardware I can test this on so it'd be good if someone with suitable hardware could give it a spin. Daniel, you wrote the code that does the readbacks so I guess you're most likely to have a good test setup for this? sound/soc/codecs/tlv320aic3x.c | 11 ++--------- 1 files changed, 2 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index ab099f4..0cf401f 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -145,8 +145,8 @@ static int aic3x_read(struct snd_soc_codec *codec, unsigned int reg, u8 *value) { *value = reg & 0xff; - if (codec->hw_read(codec->control_data, value, 1) != 1) - return -EIO; + + value[0] = i2c_smbus_read_byte_data(codec->control_data, value[0]); aic3x_write_reg_cache(codec, reg, *value); return 0; @@ -1316,12 +1316,6 @@ static struct i2c_driver aic3x_i2c_driver = { .id_table = aic3x_i2c_id, }; -static int aic3x_i2c_read(struct i2c_client *client, u8 *value, int len) -{ - value[0] = i2c_smbus_read_byte_data(client, value[0]); - return (len == 1); -} - static int aic3x_add_i2c_device(struct platform_device *pdev, const struct aic3x_setup_data *setup) { @@ -1394,7 +1388,6 @@ static int aic3x_probe(struct platform_device *pdev) #if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) if (setup->i2c_address) { codec->hw_write = (hw_write_t) i2c_master_send; - codec->hw_read = (hw_read_t) aic3x_i2c_read; ret = aic3x_add_i2c_device(pdev, setup); } #else -- 1.6.3.3

1 0

[alsa-devel] pulseaudio complains of bad pcm delay values
by Karl Kleinpaste 05 Jul '09

05 Jul '09

I'm sending this somewhat blindly, due to messages from the nightly log summary. I'm just cut/pasting what is there. It says "report this to alsa developers," but it would have been kinda cool if somebody would have included a definite address to which such a report should be sent. (First try, I sent this to alsa-devel@sourceforge. Got a bounce about the list having moved. Resending as indicated. No, I'm not subscribing to the list. Sorry, but I'm offering a bug report per request, not trying to engage in general devel conversation on this topic.) Hardware is a Toshiba Satellite P205 series, with this sound hardware: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) Subsystem: Toshiba America Info Systems Device ff00 Flags: bus master, fast devsel, latency 0, IRQ 22 Memory at f8500000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Mask- 64bit+ Count=1/1 Enable- Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [100] Virtual Channel <?> Capabilities: [130] Root Complex Link <?> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel This is Fedora11, 2.6.29.5-191.fc11.i686.PAE (32-bit, obviously). Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: 1480877280 bytes (8394995 ms). Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: snd_pcm_dump(): Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: Soft volume PCM Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: Control: PCM Playback Volume Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: min_dB: -51 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: max_dB: 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: resolution: 256 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: Its setup is: Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: stream : CAPTURE Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: access : MMAP_INTERLEAVED Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: format : S16_LE Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: subformat : STD Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: channels : 2 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: rate : 44100 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: exact rate : 44100 (44100/1) Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: msbits : 16 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: buffer_size : 88192 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_size : 44096 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_time : 999909 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: tstamp_mode : ENABLE Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_step : 1 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: avail_min : 87310 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_event : 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: start_threshold : -1 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: stop_threshold : 1444937728 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: silence_threshold: 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: silence_size : 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: boundary : 1444937728 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: Slave: Hardware PCM card 0 'HDA Intel' device 0 subdevice 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: Its setup is: Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: stream : CAPTURE Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: access : MMAP_INTERLEAVED Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: format : S16_LE Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: subformat : STD Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: channels : 2 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: rate : 44100 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: exact rate : 44100 (44100/1) Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: msbits : 16 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: buffer_size : 88192 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_size : 44096 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_time : 999909 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: tstamp_mode : ENABLE Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_step : 1 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: avail_min : 87310 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: period_event : 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: start_threshold : -1 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: stop_threshold : 1444937728 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: silence_threshold: 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: silence_size : 0 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: boundary : 1444937728 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: appl_ptr : 932488 Jul 4 09:20:35 awol pulseaudio[2835]: alsa-util.c: hw_ptr : 1444893632 Jul 4 09:20:40 awol pulseaudio[2835]: ratelimit.c: 1106 events suppressed Jul 4 09:20:45 awol pulseaudio[2835]: cpulimit.c: Received request to terminate due to CPU overload. Jul 4 09:20:47 awol pulseaudio[2835]: memblock.c: Memory pool destroyed but not all memory blocks freed! 236 remain. Jul 4 09:26:13 awol pulseaudio[17025]: alsa-sink.c: Increasing minimal latency to 1.00 ms Jul 4 09:26:13 awol pulseaudio[17025]: alsa-sink.c: Increasing minimal latency to 2.00 ms Jul 4 09:36:02 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 1.00 ms Jul 4 09:36:02 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 2.00 ms Jul 4 09:36:03 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 4.00 ms Jul 4 09:36:08 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 8.00 ms Jul 4 09:36:09 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 16.00 ms Jul 4 09:36:11 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 26.00 ms Jul 4 09:36:12 awol pulseaudio[17025]: alsa-source.c: Increasing wakeup watermark to 15.99 ms Jul 4 09:36:14 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 36.00 ms Jul 4 09:36:26 awol pulseaudio[17025]: alsa-source.c: Increasing wakeup watermark to 25.99 ms Jul 4 09:36:33 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 46.00 ms Jul 4 09:36:44 awol pulseaudio[17025]: alsa-source.c: Increasing wakeup watermark to 35.99 ms Jul 4 09:38:48 awol pulseaudio[17025]: alsa-source.c: Increasing minimal latency to 56.00 ms

1 0

[alsa-devel] VIA 82C686B AC'97 controller initialization
by Gerhard Pircher 05 Jul '09

05 Jul '09

Hi, I'm trying to get AC'97 sound working on my AmigaOne PowerPC machine with a VIA 82C686B southbridge and a SigmaTel STAC9752 codec. The firmware doesn't initialize the AC'97 controller at all. Thus I had to implement some PCI quirks, which first setup the I/O BARs of the AC'97 PCI device and secondly power up the AC'97 controller by triggering a soft resume event through the southbridge's ACPI controller. This seems to work fine so far, but playback works in slow motion when I first power up the machine. After a warm reset audio playback sounds normal. Does somebody know how to fix this problem or were the problem could be? BTW can the snd-via82xx and snd-via82xx-modem drivers be used at the same time? Thanks Gerhard p.s.: Please put me on CC:, as I'm not subscribed to this mailing list. -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

1 0

[alsa-devel] [RFC] cmi8330: Add basic CMI8329 support
by Ondrej Zary 05 Jul '09

05 Jul '09

Add basic support for CMI8329 cards. It seems to be very similar to CMI8330, but the PnP devices are different: - AD1848 (WSS) and SB16 device IDs are swapped - the OPL3 port is contained in SB16 device, not AD1848 (WSS) - there is A@@0001 device (looks like some control interface - it has only one 8-bit I/O address) Is my detection code correct, shouldn't the struct pnp_dev returned pnp_request_card_device() be released somehow? Also the mixer seems to be a bit different - master volume does not work currently. My card includes wavetable MIDI - it works in Windows when MPU-401 is selected. It does not work with this driver - pmidi plays but no sound comes out. OPL3 works. My card has also an IDE interface but it's not visible as PnP device and it does not work even in Windows (and I'm unable to find any driver for it for any OS). Here's a scan of the card: http://www.rainbow-software.org/images/hardware/cmi8329a_.jpg The main chip is labelled AD Chips CMI8329A. --- linux-test/sound/isa/cmi8330.c 2009-06-27 16:32:13.000000000 +0200 +++ linux-2.6.30-pentium/sound/isa/cmi8330.c 2009-06-27 16:33:25.000000000 +0200 @@ -156,6 +156,11 @@ typedef int (*snd_pcm_open_callback_t)(struct snd_pcm_substream *); +enum card_type { + CMI8329, + CMI8330 +}; + struct snd_cmi8330 { #ifdef CONFIG_PNP struct pnp_dev *cap; @@ -172,6 +177,8 @@ snd_pcm_open_callback_t open; void *private_data; /* sb or wss */ } streams[2]; + + enum card_type type; }; #ifdef CONFIG_PNP @@ -328,12 +335,26 @@ { struct pnp_dev *pdev; int err; + const char *sb16_id, *wss_id; + + /* CMI8329 has a device with ID A@@0001, CMI8330 does not */ + pdev = pnp_request_card_device(card, "A@@0001", NULL); + if (pdev) { + acard->type = CMI8329; + pnp_release_card_device(pdev); + sb16_id = id->devs[0].id; + wss_id = id->devs[1].id; + } else { + acard->type = CMI8330; + sb16_id = id->devs[1].id; + wss_id = id->devs[0].id; + } - acard->cap = pnp_request_card_device(card, id->devs[0].id, NULL); + acard->cap = pnp_request_card_device(card, wss_id, NULL); if (acard->cap == NULL) return -EBUSY; - acard->play = pnp_request_card_device(card, id->devs[1].id, NULL); + acard->play = pnp_request_card_device(card, sb16_id, NULL); if (acard->play == NULL) return -EBUSY; @@ -351,7 +372,8 @@ wssport[dev] = pnp_port_start(pdev, 0); wssdma[dev] = pnp_dma(pdev, 0); wssirq[dev] = pnp_irq(pdev, 0); - fmport[dev] = pnp_port_start(pdev, 1); + if (acard->type == CMI8330) + fmport[dev] = pnp_port_start(pdev, 1); /* allocate SB16 resources */ pdev = acard->play; @@ -365,6 +387,8 @@ sbdma8[dev] = pnp_dma(pdev, 0); sbdma16[dev] = pnp_dma(pdev, 1); sbirq[dev] = pnp_irq(pdev, 0); + if (acard->type == CMI8329) + fmport[dev] = pnp_port_start(pdev, 1); /* allocate MPU-401 resources */ pdev = acard->mpu; -- Ondrej Zary

2 3

Re: [alsa-devel] Laptop speakers nonfunctional, jacks functional
by Takashi Iwai 05 Jul '09

05 Jul '09

At Sat, 4 Jul 2009 22:16:18 +0200, Ludwig Maes wrote: > > but then, how come I have audio on line out and headphones? No idea. But this implies that you have very strange setup. Takashi > > thanks, > Ludwig > > 2009/7/4 Takashi Iwai <tiwai(a)suse.de> > > At Sat, 4 Jul 2009 19:15:23 +0200, > Ludwig Maes wrote: > > > > Thanks for your attention, > > I dont have /dev/snd/hwC0D0 > > but I do have > > /dev/snd/seq > > /dev/snd/timer > > /dev/sndstat > > I guess I should try it on seq, but I'll await your advice > > No, don't, that's wrong! > > It's an odd situation. I guess you didn't install the driver properly. > Otherwise you must have /dev/snd/control*, PCM, else. > > How to install the alsa-driver externally depends on the distro. > I'd advise you to ask on a distro forum about it at first. > The rest debugging starts after you can install the sound drivers > properly. > > thanks, > > Takashi > > > friendly greetings > > Ludwig > > > > 2009/6/30 Takashi Iwai <tiwai(a)suse.de> > > > > At Mon, 29 Jun 2009 20:06:47 +0200, > > Ludwig Maes wrote: > > > > > > Tried the snapshot, > > > still the same, alsa-info.txt attached > > > > Hm, just through a quick look at the output, there is no obvious > > problem. It's only the problem from speaker, not about the > headphone, > > right? > > > > If so, the problem is likely the missing amplifier setup, which is > > usually powered up via COEF verbs or GPIO verbs (ALC888/1200 have no > > EAPD verbs). > > > > Try to install hda-verb program and check the command below. > > > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0 > > > > Which value do you get? What happens if you set > > > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3060 > > or > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3070 > > or > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0830 > > or so? > > > > Takashi > > > > > >

1 0

Re: [alsa-devel] Laptop speakers nonfunctional, jacks functional
by Takashi Iwai 04 Jul '09

04 Jul '09

At Sat, 4 Jul 2009 19:15:23 +0200, Ludwig Maes wrote: > > Thanks for your attention, > I dont have /dev/snd/hwC0D0 > but I do have > /dev/snd/seq > /dev/snd/timer > /dev/sndstat > I guess I should try it on seq, but I'll await your advice No, don't, that's wrong! It's an odd situation. I guess you didn't install the driver properly. Otherwise you must have /dev/snd/control*, PCM, else. How to install the alsa-driver externally depends on the distro. I'd advise you to ask on a distro forum about it at first. The rest debugging starts after you can install the sound drivers properly. thanks, Takashi > friendly greetings > Ludwig > > 2009/6/30 Takashi Iwai <tiwai(a)suse.de> > > At Mon, 29 Jun 2009 20:06:47 +0200, > Ludwig Maes wrote: > > > > Tried the snapshot, > > still the same, alsa-info.txt attached > > Hm, just through a quick look at the output, there is no obvious > problem. It's only the problem from speaker, not about the headphone, > right? > > If so, the problem is likely the missing amplifier setup, which is > usually powered up via COEF verbs or GPIO verbs (ALC888/1200 have no > EAPD verbs). > > Try to install hda-verb program and check the command below. > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0 > > Which value do you get? What happens if you set > > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3060 > or > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3070 > or > # hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 7 > # hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0830 > or so? > > Takashi > >

1 0

[alsa-devel] Help required with debugging
by Harsha, Priya 04 Jul '09

04 Jul '09

Hi, I see the following behavior and have a couple of questions that would help me debug my new driver/hardware. snd_pcm_lib_read1() - > snd_pcm_update_hw_ptr() ->ops->ack() This enables the driver to send data to hardware for capture snd_pcm_period_elapsed() -> hw_ptr_interrupt This updates the runtime->hw_ptr_jiffies. The jdelta calculated is proper and I find no issues with this. snd_pcm_lib_read1() is returned back Alsa calls driver's ack inbetween here snd_pcm_period_elapsed() -> snd_pcm_update_ hw_ptr_interrupt This updates the runtime->hw_ptr_jiffies. The jdelta calculated is proper and I find no issues with this. snd_pcm_lib_read1() - > snd_pcm_update_ hw_ptr() Here the runtime->hw_ptr_jiffies is updated and this causes my next jdelta to be very less in snd_pcm_period_elapsed() -> snd_pcm_update_hw_ptr_interrupt. Why is runtime->hw_ptr_jiffies updated in hw_ptr()? This should be only updated in the interrupt context right? Without this statement, my driver/hardware works fine. Or is there any constraint I can set somehow such that the hw_ptr_jiffies is only updated in the hw_ptr_interrupt function? Thanks, Harsha

2 2