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

[alsa-devel] SALSA-Lib versus C++
by J. Scott Merritt 02 Jul '07

02 Jul '07

Dear List, It -appears- to me that the source file headers generated by SALSA-Lib-0.0.5 (for example SALSA:asoundlib.h) are not generally usable from within a C++ program compiled with g++. The first problem that I encountered was a failure in IOC_TYPECHECK from asm-generic/ioctl.h. After much searching, I concluded that this is a component of continuing struggles related to "sanitized linux-kernel-headers". Some of the Debian folks have supplied patches to disable this particular check when the ioctl.h file is included from userland, but these patched headers are not present in my cross-compile environment. This behavior apparently is not a problem with gcc or g++ < 2.3.3 - but shows up in later versions of g++. ... a real mess as best I can tell ... The next problem is that when warnings are enabled, g++ complains vigorously about void pointers that are implicitly cast to typed pointers through-out all of the SALSA-Lib supplied header files. Perhaps SALSA-Lib was never intended from usable from C++ programs - and indeed it could argued that its intended application (embedded systems) should avoid the use of C++. If this is the case, perhaps a mention of this restriction might be appropriate on the SALSA-Lib Website and/or in its README file ? Thanks again for all of your help in trying to get this working. Best regards, Scott.

2 2

[alsa-devel] NVidia AC97 / CK804: arecord hangs in system call poll()
by Rainer Menzner 02 Jul '07

02 Jul '07

Hi, my soundcard is an onboard AC97 CK804 NVidia. I use snd-intel8x0 module. Everything works fine except recording sound. When calling arecord -f cd buffer.wav the program infinitely hangs, and an strace shows that it is a poll() call that does not return. After interrupting, a wave file of 44 bytes which is the header only is left. My setup is Kernel 2.6.21.3, all ALSA-software is updated to the latest version, that is 1.0.14(a). In a previous setup with an older ALSA version and kernel 2.6.16.11 recording did work with the same hardware. Now that I updated all ALSA software, even with that older kernel version the same recording problem came up. From that I concluded that it is somehow related to the ALSA-lib version. I have tried to downgrade ALSA-lib down to 1.0.0 to no avail. I have also made tests appropriate if this would be an interrupt problem (using pci=noroute et al) which also did not solve the problem. I have scrolled though the archives of alsa-user and there have been a few posts regarding the same problem (but with other chip sets). However, in those threads no definitive solution of the problem has been discussed. So I tried it again in alsa-user but did not get any feedback ... Now, I finally try this developer list. Your comments and help are much appreciated. Let me know if you need further info. I'm not a Linux system programmer or specialist, but I would be willing to do some debugging if somebody explains what to check. Thanks for any support, -Rainer

2 2

[alsa-devel] hda-Intel Realtek ALC883 chipset support
by Adriano Grassi 30 Jun '07

30 Jun '07

Hi guys I have sound on different linux distro's however only the spdif/headphone share output, no sound from the internal speakers I have been trying to get this work for the last 5 days no success. So i was wondering if the support for this chipset is in place. I even tried the lastest candidate release alsa files 14rc4 with no luck, this is a high definition audio card with multiple outputs analog and digital and i have tried everything i can think of with no success, I tried multiple distro's with the same result, I don't this it is a driver issue is probably more like a configuration issue. Can anyone help me figure this one out. Thanks. 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xd2300000 irq 98 2: : timer 3: [ 0- 2]: digital audio playback 4: [ 0- 1]: digital audio capture 5: [ 0- 0]: digital audio playback 6: [ 0- 0]: digital audio capture 7: [ 0] : control 8: : sequencer cat: /proc/asound/Intel: Is a directory 0 snd_hda_intel cat: /proc/asound/oss: Is a directory 00-02: ALC883 Digital : ALC883 Digital : playback 1 00-01: ALC883 Analog : ALC883 Analog : capture 2 00-00: ALC883 Analog : ALC883 Analog : playback 1 : capture 2 cat: /proc/asound/seq: Is a directory G0: system timer : 4000.000us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE P0-0-3: PCM capture 0-0-3 : SLAVE P0-1-1: PCM capture 0-1-1 : SLAVE P0-1-3: PCM capture 0-1-3 : SLAVE P0-2-0: PCM playback 0-2-0 : SLAVE Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).

1 0

[alsa-devel] Digigram VX source code
by Colin Stewart Campbell 30 Jun '07

30 Jun '07

About 5 years ago Digigram released their VX soundcard source for OSX through the alsa project. Is there somewhere I can still get a hold of it? I have in mind a legacy card coreaudio driver for Intel macs. Colin

2 1

[alsa-devel] helping debugging
by Thierry Vignaud 30 Jun '07

30 Jun '07

Hi Here's a suggestion from Dave Airlie: http://airlied.livejournal.com/46087.html "If you are going to have lots of unsigned int sized free running pointers called things like hw_ptr or hw.ptr or anything, for debugging it would be really cool if you started those counters at INT_MAX-100000 or something instead of at zero, 24 hours waiting for a bug to trip in the pcm rate conversion is not fun and I'm guessing it'll be some stupid interger overflow or dumb boundary condition hitting..."

2 1

Re: [alsa-devel] Fwd: Problems with hda_intel, Santa Rosa, and suspend
by albox＠free.fr 30 Jun '07

30 Jun '07

Could this issue be related to the other one with Medion laptops : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3160 Takashi, you said you were going to check the older patch that was working on ALSA 1.0.13, did you have a chance to do that ? Takashi Iwai wrote: > At Mon, 25 Jun 2007 15:16:41 -0500, > Matt Mullins wrote: >> On 6/25/07, Takashi Iwai <tiwai(a)suse.de> wrote: >>>> Yes, single_cmd mode is used always. >>> That's bad. >> I believe we have established that. What can I do about it? *Can* I >> do anything about it? What functions should I start debugging? Has >> this happened with other codecs before? What documentation will I >> need or want other than the Intel HDA and STAC9205 specifications? > > Similar problems have been seen in some laptops, too. I vaguely > remember that they need some ACPI-related boot options to fix it > somehow. I think it's likely irrelevant with the codec chip, but > rather a problem of the controller side. > >> I'm definitely willing to help work on this, as not many people have >> this hardware. I'm just new to the sound system, so I'm still trying >> to figure out what-calls-what. > > > Takashi > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > >

2 1

Re: [alsa-devel] Creative Soundblaster X-Fi
by Ash Willis 30 Jun '07

30 Jun '07

Hi all, Sorry for straying a little off topic, but talk of these couple of chips got me thinking about unsupported hardware in general. Does anyone know the legal implications of reverse engineering with regards to producing new drivers? I myself wouldn't mind reversing a certain chip or two but I'm not too aware of the legality of it all, particularly in the case where the vendor is hostile or unwilling to release chip information. In general, is it legally acceptable to reverse engineer for the purposes of interoperability? Are vendors likely to make a noise if their hardware gains support under Linux without or against their consent? or is it more a matter of protecting the original product specification than hiding details of the product's interface? Takashi, may I ask your thoughts on this? What's your position on accepting reverse engineered code? (Let's assume that the driver works as well as one written in a more correct manner ;)) I'm fully aware that uncooperative vendors don't deserve to have their hardware supported, but I think that Linux users and Linux itself deserves the support. Ash -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains

3 2

[alsa-devel] [1/2] 2.6.22-rc6: known regressions v2
by Michal Piotrowski 29 Jun '07

29 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc6. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Hugh Dickins 2 Andi Kleen 1 Björn Steinbrink 1 Bjorn Helgaas 1 Jean Delvare 1 Olaf Hering 1 Siddha, Suresh B 1 Trent Piepho 1 Ville Syrjälä 1 Unclassified Subject : Kernel hang on CMOS_READ References : http://lkml.org/lkml/2007/6/3/138 Submitter : Rodrigo Luiz <troops.of.doom(a)gmail.com> Status : Unknown ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Handled-By : Takashi Iwai <tiwai(a)suse.de> Status : Unknown FS Subject : 2.6.22-rc4-git5 reiserfs: null ptr deref. References : http://lkml.org/lkml/2007/6/13/322 Submitter : Randy Dunlap <randy.dunlap(a)oracle.com> Handled-By : Vladimir V. Saveliev <vs(a)namesys.com> Status : problem is being debugged IDE Subject : 2.6.22-rcX: hda: lost interrupt References : http://lkml.org/lkml/2007/6/29/121 Submitter : David Chinner <dgc(a)sgi.com> Status : unknown SATA/PATA Subject : libata IT821X driver still fails! Hard-freezes system References : http://lkml.org/lkml/2007/6/14/82 Submitter : Rodney Gordon II <meff(a)spherevision.org> Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/

4 7

[alsa-devel] Creative Soundblaster X-Fi
by Tim Laszlo 29 Jun '07

29 Jun '07

Has anyone worked on developing an open source driver for the sound blaster x-fi cards? I've been sitting on one for about a year (mental note check support *before* buying..) and would love to use it already... Creative has promised drivers but they seem to be in no rush to support Linux. I'd like to try my hand at working on a driver for this, but without any technical specs from creative I wouldn't really know where to begin. Anyone have any suggestions on how to start? Anyone worked on this yet? Am I nuts for even considering this?? Timl

2 2

[alsa-devel] SALSA-Lib: Playback overrun on initial PCM start
by J. Scott Merritt 29 Jun '07

29 Jun '07

Dear List, Using SALSA-Lib 0.0.3, I call: snd_pcm_open (&playback_handle, argv[1], SND_PCM_STREAM_PLAYBACK, 0); snd_pcm_hw_params_malloc (&hw_params); snd_pcm_hw_params_any (playback_handle, hw_params); snd_pcm_hw_params_set_access (playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED); snd_pcm_hw_params_set_format (playback_handle, hw_params, SND_PCM_FORMAT_S16_LE)); snd_pcm_hw_params_set_rate_near (playback_handle, hw_params, 44100, 0); snd_pcm_hw_params_set_channels (playback_handle, hw_params, 2); snd_pcm_hw_params_set_buffer_size_last (playback_handle, hw_params, &bfrsize); snd_pcm_hw_params_get_buffer_size (hw_params, &bfrsize); snd_pcm_hw_params (playback_handle, hw_params); snd_pcm_hw_params_free (hw_params); snd_pcm_sw_params_malloc (&sw_params); snd_pcm_sw_params_current (playback_handle, sw_params); snd_pcm_sw_params_set_avail_min (playback_handle, sw_params, 4096); snd_pcm_sw_params_set_start_threshold (playback_handle, sw_params, 10000U); snd_pcm_sw_params_set_xfer_align (playback_handle, sw_params, 1); snd_pcm_sw_params (playback_handle, sw_params); state = snd_pcm_state (playback_handle); frames_to_deliver = snd_pcm_avail_update (playback_handle); while ((frames_to_deliver = snd_pcm_avail_update (playback_handle)) > 4096) { snd_pcm_writei (playback_handle, &buf, 4096) } As soon as the buffer start threshold is reached, or alternatively if I manually start PCM stream, the PCM stream reports an overrun (i.e. "Broken Pipe"). If I then examine the PCM state, it is in the overrun (XRUN) state. The code is being cross-compiled and tested on an ARM processor (PXA270) which is running linux kernel 2.6.21. This same code sequence -does- operate properly (in the same ARM test environment) when compiled against AlsaLib 1.0.13. Another apparent (and perhaps relevent) difference between AlsaLib and SALSA-Lib is that if I open the PCM stream with O_NONBLOCK and then call snd_pcm_poll_descriptors, AlsaLib gives me a FD = 4, whereas SALSA-Lib reports an FD = 3; Thanks, Scott.

3 8