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

Re: [alsa-devel] [Pkg-alsa-devel] Bug#430833: libasound2: PCM plugin `lfloat' not built
by Elimar Riesebieter 28 Jun '07

28 Jun '07

forwarded 430833 alsa-devel(a)alsa-project.org -- On Wed, 27 Jun 2007 the mental interface of Mark Wooding told: > Package: libasound2 > Version: 1.0.14a-1 > Severity: normal > Tags: patch > > The PCM plugin `lfloat' isn't compiled into libasound. In particular, > this prevents the `plug' plugin from doing linear<->float conversion, > and in turn this means that hardly any ALSA clients can use the JACK > plugin from libasound2-plugins, because JACK uses FLOAT_LE format > throughout. > > The reason for this is quite simple: the configure script is broken! In > particular, the sense of the `softfloat' check used to decide whether to > disable the plugin is wrong! (That's aside from the question of whether > it's sensible to fail to build the thing just because it might be slow.) > We should solve this in general. It's not a Debian specific wish so forwarded upstream. > > Index: alsa-lib-1.0.14a/configure.in > =================================================================== > --- alsa-lib-1.0.14a.orig/configure.in 2007-06-27 16:24:58.000000000 > +0100 > +++ alsa-lib-1.0.14a/configure.in 2007-06-27 16:25:19.000000000 > +0100 > @@ -416,7 +416,7 @@ > build_pcm_share="no" > fi > > -if test "$softfloat" != "yes"; then > +if test "$softfloat" = "yes"; then > build_pcm_lfloat="no" > fi > > Index: alsa-lib-1.0.14a/configure > =================================================================== > --- alsa-lib-1.0.14a.orig/configure 2007-06-27 16:25:23.000000000 > +0100 > +++ alsa-lib-1.0.14a/configure 2007-06-27 16:25:38.000000000 +0100 > @@ -20946,7 +20946,7 @@ > build_pcm_share="no" > fi > > -if test "$softfloat" != "yes"; then > +if test "$softfloat" = "yes"; then > build_pcm_lfloat="no" > fi > > Elimar -- Experience is something you don't get until just after you need it!

2 1

[alsa-devel] Sound disappears after a long run, pcm_rate plugin maybe
by Dave Airlie 28 Jun '07

28 Jun '07

Hi, I've been debugging this bug which I first noticed close to a year ago but worked around by disabling dmix. Now I've had to enable dmix and try and fix it. My system is SDL on alsa-lib-1.0.13 on 2.6.21 on intel 810 with a Realtek ALC655. I'm using SDL to open a 22050 16-bit stereo stream, and dmix is set to 48000. When I run sound in my single app (only one app running for testing purposes) around 20-24 hours later (I haven't got exact timings as I can't sit in front of the pc for so long) the sound stop s happening just in that app. I can run aplay separately and it plays fine. If I stop my app (ctrl-C and cont in gdb) or attach/detach strace, I get an XRUN and my SDL code calls snd_pcm_prepare and the sounds comes back. Now I can't tell you how much it sucks to only get a single debugging run every 24 hours for 1 break point and if gdb stuffs it up you lose big time. I think I've tracked it down to pcm_rate.c as in if I open the sound card at 48000 instead of 22050 it doesn't happen and I've added a lot of printfs to the rate code in 1.0.13 and gotten huge log file traces of it.. In a normal rate trace when things are working I get traces like this: snd_pcm_rate_sync_playback_area: 442023720 442023720 525 986185728 snd_pcm_rate_sync_playback_area: 442023720 442023720 1549 986185728 snd_pcm_rate_sync_playback_area: 442023720 442023720 1549 986185728 snd_pcm_rate_sync_playback_area: 442024660 442023720 1549 986185728 snd_pcm_rate_commit_area: 6 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442023720 1881 snd_pcm_rate_sync_playback_area: 442024660 442024660 525 986185728 snd_pcm_rate_sync_playback_area: 442024660 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442024660 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442025595 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442025600 442024660 1549 986185728 snd_pcm_rate_commit_area: 946 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442024660 1881 snd_pcm_rate_sync_playback_area: 442025600 442025600 525 986185728 snd_pcm_rate_sync_playback_area: 442025600 442025600 1549 986185728 snd_pcm_rate_sync_playback_area: 442025600 442025600 1549 986185728 snd_pcm_rate_sync_playback_area: 442026540 442025600 1549 986185728 snd_pcm_rate_commit_area: 5 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442025600 1881 snd_pcm_rate_sync_playback_area: 442026540 442026540 525 986185728 snd_pcm_rate_sync_playback_area: 442026540 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442026540 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442027476 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442027480 442026540 1549 986185728 playback are debug code slave_size = snd_pcm_avail_update(slave); if (slave_size < 0) return slave_size; fprintf(stderr,"%s: %u %d %u %u\n", __func__, appl_ptr, rate->last_commit_ptr, slave_size, pcm->boundary); if (appl_ptr < rate->last_commit_ptr) xfer = appl_ptr - rate->last_commit_ptr + pcm->boundary; else xfer = appl_ptr - rate->last_commit_ptr; while (xfer >= pcm->period_size && (snd_pcm_uframes_t)slave_size >= rate->gen.slave->period_size) { err = snd_pcm_rate_commit_next_period(pcm, rate->last_commit_ptr % pcm->buffer_size); fprintf(stderr, "%s: %u %u %u\n", __func__, xfer, rate->last_commit_ptr, pcm->buffer_size); if (err == 0) commit area debug fprintf(stderr,"%s: %u %u %u %u\n", __func__, appl_offset, size, slave_size, pcm->buffer_size); areas = snd_pcm_mmap_areas(pcm); if (cont >= size) { In the not so good case (with different debug - two sites and I hadn't access to my debug code from one so I wrote it again) you get large numbers of snd_pcm_rate_sync_playback_area: 152605942 912 152385750 snd_pcm_rate_sync_playback_area: 152605942 912 152385750 snd_pcm_rate_sync_playback_area: 152606412 912 152385750 snd_pcm_rate_sync_playback_area: 152606412 912 152385750 snd_pcm_rate_sync_playback_area: 152606705 912 152385750 snd_pcm_rate_sync_playback_area: 152606882 912 152385750 snd_pcm_rate_sync_playback_area: 152606882 912 152385750 snd_pcm_rate_sync_playback_area: 152607352 912 152385750 snd_pcm_rate_sync_playback_area: 152607352 912 152385750 ...... snd_pcm_rate_sync_playback_area: 152769972 912 152385750 snd_pcm_rate_sync_playback_area: 152770381 1936 152385750 snd_pcm_rate_commit_area: 1411 572 470 snd_pcm_rate_sync_playback_area: 384631 1 1936 152385750 739770368 snd_pcm_rate_sync_playback_area: 152770442 912 152386220 .... more of these.... snd_pcm_rate_sync_playback_area: 152910502 912 152386220 snd_pcm_rate_sync_playback_area: 152910502 912 152386220 snd_pcm_rate_sync_playback_area: 152910972 912 152386220 snd_pcm_rate_sync_playback_area: 152910972 912 152386220 appl ptr is 152910972 recalc: 3022344724 1411 3072 470 1024 snd_pcm_rate_sync_playback_area: 152910972 1936 152386220 snd_pcm_rate_commit_area: 1411 1042 470 snd_pcm_rate_sync_playback_area: 524752 1 1936 152386220 739770368 snd_pcm_rate_sync_playback_area: 152910972 1936 152386690 snd_pcm_rate_commit_area: 1411 101 470 snd_pcm_rate_sync_playback_area: 524282 1 1936 152386690 739770368 snd_pcm_rate_sync_playback_area: 152910972 1936 152387160 ... this pattern repeats one commit per two playbacks until it goes back in the top... the debug code for these are recalc: fprintf(stderr,"%s: %lu %lu %lu %lu %lu\n", __func__, val, pcm->buffer_size, slave->buffer_size, pcm->period_size, slave->period_size); commit area areas = snd_pcm_mmap_areas(pcm); fprintf(stderr,"%s: %u %u %u\n", __func__, pcm->buffer_size, appl_offset, size); if (cont >= size) { playback area: fprintf(stderr,"%s: %u %d %d\n", __func__, appl_ptr, slave_size, rate->last_commit_ptr); if (appl_ptr < rate->last_commit_ptr) xfer = appl_ptr - rate->last_commit_ptr + pcm->boundary; else xfer = appl_ptr - rate->last_commit_ptr; while (xfer >= pcm->period_size && (snd_pcm_uframes_t)slave_size >= rate->gen.slave->period_size) { err = snd_pcm_rate_commit_next_period(pcm, rate->last_commit_ptr % pcm->buffer_size); fprintf(stderr,"%s: %u %d %d %u %u\n", __func__, xfer, err, slave_size, rate->last_commit_ptr, pcm->boundary); I'm hoping it is just some calculation in the rate plugin overflowing and I was blaming SDL but I've fixed up the codepaths to look like aplay and it still happened.. any hints would be appreciated on a) what that rate code is actually doing in the fail case, b) what the rate code is doing in the non-fail case :-) Dave.

2 1

[alsa-devel] SoC multiple streams
by Steve Longerbeam 28 Jun '07

28 Jun '07

Hi all, I'm developing an SoC driver for a sound engine that supports playing up to 64 simultaneous substreams, all mixed in h/w to a stereo DAC. But it doesn't appear that the SoC framework supports multiple substreams, according to soc_new_pcm(). Am I missing something, or is this on the asoc development roadmap? Thanks, Steve

3 3

[alsa-devel] SoC Machine Code Suggestions
by Paul Kavan 27 Jun '07

27 Jun '07

First, thanks to all for helping me get the at91 soc stuff working with my board and codec. It now plays telecom quality audio using aplay and records it as well using arecord. For those who were following my trials and did not hear what the solution was, essentially, when the at91-ssc code goes into playback mode, it only activates the TX side of the SSC (PCM) bus. Similarly, when it is in capture mode, it only activates the RX side of the bus. This certainly makes sense and works in most situations I am sure. However, I needed both the RX and TX frames operating in both playback and capture. As such, I had to modify at91-ssc slightly to accomplish this. Now that I have decent audio, I want to clean up around the edges of the audio and determine the best way to proceed with my application code. First. when the pcm interface starts/stops, I get a pop that comes from the codec analog output transitioning some. Now, there may be some hardware fixes to this, but what I would like to do it mute the amp until the last possible second before audio is played. I can accomplish this with a simple gpio call, but am not sure where best to turn the mute on and off. Any suggestions with that would be appreciated. Also, my next phase of development is to determine whether I need to write my own application to accomplish what I want to do, or if there is an application out there that will do the trick--and that I can cross-compile to an ARM. What I would like is an application I will stream audio (half-duplex) between two ARM boards connected via ethernet. I would need to be able to control the start/stop of the audio. Sometimes this control will depend on the state of the machine and other times it will be activate with a button press by the user. I hope that makes sense. Obviously it would have to seamlessly stream to the codec via ALSA. Also, there may be times when it streams to a pc. Now, the codec uses 8-bit ulaw, so this code if it were on a pc, would need to be able to play that on the pc in its native state or some type of conversion on the fly. I guess you can think of the application as similar to voip, but half duplex instead of full duplex. Does anyone know if something like this exists that I might use. If not, how hard would it be to code this for ALSA? Thanks again and I look forward to your responses. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

2 2

Re: [alsa-devel] SALSA-Lib version 0.0.1 release
by Takashi Iwai 27 Jun '07

27 Jun '07

At Mon, 25 Jun 2007 23:32:39 +0100, Adrian McMenamin wrote: > > > You can check ldd to the app which shlib it's linked with. > > It should be linked with libsalsa, not libasound. > > > > > > Takashi > > > > I expect I am being a bit thick here but what app? I use mpg123 and > it's not linked with any alsa libs. > > / # ldd ./mpg123 > libm.so.0 => /lib/libm.so.0 (0x2956d000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2958b000) > libc.so.0 => /lib/libc.so.0 (0x295aa000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x29558000) mpg123 is an OSS app. > / # ldd aplay > libasound.so.2 => /usr/lib/libasound.so.2 (0x2956d000) > libm.so.0 => /lib/libm.so.0 (0x29652000) > libdl.so.0 => /lib/libdl.so.0 (0x29670000) > libpthread.so.0 => /lib/libpthread.so.0 (0x29683000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x296a4000) > libc.so.0 => /lib/libc.so.0 (0x296c3000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x29558000) It's liekly linked with the old libasound. SALSA-lib is a source-level compatible library and it's _not_ binary-level compatible. Thus, it's no drop-in replacement. After installing salsa-lib (better use --enable-everything option to make a libasound symlink), then you'll have to rebuild the other apps linked with alsa-lib again. Takashi

1 0

Re: [alsa-devel] ALSA always writes _whole_ periods, right?
by Takashi Iwai 27 Jun '07

27 Jun '07

At Sun, 24 Jun 2007 11:34:56 +0200, Joachim Förster wrote: > > Hi Takashi, > > thanks for your answer. > > On Wed, 2007-06-20 at 12:45 +0200, Takashi Iwai wrote: > > > Ok, ahm, I think my question was not about what I really wanted to know > > > - sorry. I have to reformulate it: In fact I would like to know, how the > > > ALSA-library mmap code behaves regarding the last chunk of samples, for > > > example: Consider aplay, playing a wav file and the wav file's > > > size/number of samples does _not_ fit to a multiple of a period's size. > > > Then, does the mmap code copy these last samples as is _or_ does it copy > > > one whole last period (which is filled with zeros)? > > > > No, you have to fill silence by yourself before committing the mmap > > chunk. The mmap code itself doesn't care about it. > > By "fill silence by yourself", you mean the application (user-space) > which is using ALSA library (with mmap), right? So this is not in the > responsibility of the sound driver, right? Right. The driver has some functionality to fill silence automatically, but it's better to avoid to play with it :) > Hmmm, so if an application does _not_ transfer sound data in a multiple > of period size, the _last_ "period" will be "incomplete". Then, my > question is: Does ALSA expect to receive a call of snd_period_elapsed() > after these last samples are played, although the it was _not_ a > complete period? I think it might depend on the hardware. Some hardwares are available to stop at the exact position, but most hardware are not. So, it's _safer_ to send always the data in the period size. And, yes, for the last period with less data, the app should fill the data to align to the period size. Takashi

1 0

[alsa-devel] Getting physical address of the DMA buffer
by Pharaoh . 27 Jun '07

27 Jun '07

Hi I have allocated the DMA buffer using snd_pcm_lib_malloc_pages() and it was preallocated as: snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS, snd_dma_continuous_data (GFP_KERNEL), 128 * 1024, 128 * 1024); and then, snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params)); None of these calls fail. The physical address of the allocated buffer is shown as 0 in my case since according to 'Writing an ALSA driver' the physical address of the DMA buffer will not be accessble from the main CPU. Is that why the physical address is shown as 0? Also, in my pointer function, I need the DMA buffers physical address to calculate the position in buffer etc. How can do that since runtime->dma_addr is 0 for me? Apologies for longish mail but I have to paste the actual paragraphs here to clear my understanding in less number of emails by avoiding further emails. In chapter 5, in DMA buffer information, it is said that, 1. The dma_area holds the buffer pointer (the logical address). You can call memcpy from/to this pointer. Meanwhile, dma_addr holds the physical address of the buffer. This ﬁeld is speciﬁed only when the buffer is a linear buffer. and in descrition of prepare callback it says, 2. The physical address of the allocated buffer is set to runtime->dma_area. Statements 1 and 2 contradict each other or I am mis reading them? How should I get the physical address in pointer callbacks? As runtime->dma_area or runtime->dma_addr which is 0? -pharaoh.

2 4

[alsa-devel] Input/output error while playing a file using aplay
by Pharaoh . 26 Jun '07

26 Jun '07

Hi I am testing my audio driver using aplay. I trying to play an audio file using: #aplay -Dplughw:0,0 --rate=44100 --format=S16 --channels=2 test.wav The log is as follows, snd_card_omap_alsa_open start snd_card_omap_alsa_open end Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo snd_omap_alsa_hw_params start snd_omap_alsa_prepare start snd_omap_alsa_prepare end snd_omap_alsa_trigger start audio_start_dma_chain start audio_start_dma_chain end omap_start_alsa_sound_dma end snd_omap_alsa_trigger end snd_omap_alsa_pointer start audio_get_dma_pos start audio_get_dma_pos end It waits here for sometime and then I get snd_omap_alsa_trigger starte error: Input/output error Then the things are wound up as: audio_stop_dma start omap_stop_alsa_sound_dma start omap_stop_alsa_sound_dma end omap_clear_alsa_sound_dma start omap_clear_alsa_sound_dma end snd_omap_alsa_trigger end snd_omap_alsa_hw_free start snd_omap_alsa_hw_free end snd_card_omap_alsa_close start snd_card_omap_alsa_close end So basically the problem is in trigger where it waits for something and then winds up things. Any idea, what could be the reason. I am thinking it has to do something with DMA interrupts etc.

2 14

[alsa-devel] at91 SoC Modifications
by Paul Kavan 26 Jun '07

26 Jun '07

Hello: Okay, so after probing the various pcm lines, I think I see that the format used for the pcm is a little bit off of what my codec likes to play nice. In my machine/codec driver, I see that I have some lines: /* set cpu DAI configuration */ ret = cpu_dai->dai_ops.set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS); I believe this is where it is selecting the format. In at91-ssc.c, I see that this format is given as: case SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_CBS_CFS: /* * DSP/PCM Mode A format, SSC provides BCLK and LRC clocks. * * The SSC transmit and receive clocks are generated from the * MCK divider, and the BCLK signal is output on the SSC TK line. */ rcmr = (( ssc_p->rcmr_period << 24) & AT91_SSC_PERIOD) | (( 1 << 16) & AT91_SSC_STTDLY) | (( AT91_SSC_START_RISING_RF ) & AT91_SSC_START) | (( AT91_SSC_CK_RISING ) & AT91_SSC_CKI) | (( AT91_SSC_CKO_NONE ) & AT91_SSC_CKO) | (( AT91_SSC_CKS_DIV ) & AT91_SSC_CKS); rfmr = (( AT91_SSC_FSEDGE_POSITIVE ) & AT91_SSC_FSEDGE) | (( AT91_SSC_FSOS_POSITIVE ) & AT91_SSC_FSOS) | (( 0 << 16) & AT91_SSC_FSLEN) | (((channels - 1) << 8) & AT91_SSC_DATNB) | (( 1 << 7) & AT91_SSC_MSBF) | (( 0 << 5) & AT91_SSC_LOOP) | (((bits - 1) << 0) & AT91_SSC_DATALEN); tcmr = (( ssc_p->tcmr_period << 24) & AT91_SSC_PERIOD) | (( 1 << 16) & AT91_SSC_STTDLY) | (( AT91_SSC_START_RISING_RF ) & AT91_SSC_START) | (( AT91_SSC_CK_RISING ) & AT91_SSC_CKI) | (( AT91_SSC_CKO_CONTINUOUS ) & AT91_SSC_CKO) | (( AT91_SSC_CKS_DIV ) & AT91_SSC_CKS); tfmr = (( AT91_SSC_FSEDGE_POSITIVE ) & AT91_SSC_FSEDGE) | (( 0 << 23) & AT91_SSC_FSDEN) | (( AT91_SSC_FSOS_POSITIVE ) & AT91_SSC_FSOS) | (( 0 << 16) & AT91_SSC_FSLEN) | (((channels - 1) << 8) & AT91_SSC_DATNB) | (( 1 << 7) & AT91_SSC_MSBF) | (( 0 << 5) & AT91_SSC_DATDEF) | (((bits - 1) << 0) & AT91_SSC_DATALEN); break; I should have caught this before--I spent enough time dealing with the HW registers. The simple ssc pcm driver I wrote sets the regs a little differently to get the peak performance out of the codec, e.g. In RCMR, I have STTDLY=0, AT91_SSC_CKI_FALLING, AT91_SSC_CKS_PIN. In RFMR everything looks okay except that I have FSOS_NONE as I borrow it from TF0 In TCMR the STTDLY=0 in mine In TFMR I do nothing with the FSEDGE and FSDEN and I have FSLEN=7 and DATADEF=1. So, I left with a decision. Do I add a mode or do I modify DSP A to fit my needs? I am not sure how much coding it would take to add a mode--I *do* know it would take little time to modify DSP A, but I am reluctant to make a change to something that is probably 'standard'. Any thoughts on this? Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

3 17

[alsa-devel] Fwd: Fwd: Problems with hda_intel, Santa Rosa, and suspend
by Matt Mullins 25 Jun '07

25 Jun '07

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? 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. - Matt

1 0

[alsa-devel] Intel Realtek ALC268 don't sound
by antoniorc＠4lineas.net 25 Jun '07

25 Jun '07

Hi, I tried latest HG driver version of Alsa, with patch included for ALC268. Apparently card is detected and mixer show correctly volumes bars, but don't sound. I tried option 3stack and auto in /etc/modprobe.d/alsa-base but nothing difference. I've a HP Pavilion dv6528 with Santa Rosa. Please tell me that I can do? Thanks

1 0

[alsa-devel] problem with audigy2 ZS remote
by Stefano Radaelli 25 Jun '07

25 Jun '07

Hi all! Sorry for my bad english. I have a problem with the livedrive of an audigy2 ZS. After some upgrades (on a gentoo linux system) the eternal panel seems to stop working. Even after the "initialization" (with echo on the midi device), the IR led not blink on remote action. This worked correctly in the past but after some upgrade (i don't know exactly what) it stoipped working. I don't known where i have to look (logs?) or what type of debugging it's necessary. Help me please

1 0

[alsa-devel] ARM in embedded audio
by Alan Horstmann 25 Jun '07

25 Jun '07

Hi, Can anyone help point me to info on using ARM in embedded audio systems? Does anyone use a low-cost chip with I2S interface? Thanks Alan

3 5

Re: [alsa-devel] [alsa-cvslog] alsa-lib: Add struct timeval and timespec definition when _POSIX_C_SOURCE is not defined
by Sergey Vlasov 25 Jun '07

25 Jun '07

On Fri, Oct 06, 2006 at 11:01:44AM +0200, Jaroslav Kysela wrote: > changeset: 2218:603411fd0c77712cab43cdd5afcf0ff4ebe51a7f > tag: tip > user: perex > date: Fri Oct 06 11:01:40 2006 +0200 > files: include/global.h > description: > Add struct timeval and timespec definition when _POSIX_C_SOURCE is not defined > > FIXME: It might cause problems on some platforms when tv_usec is not long type. And now it also breaks compilation of the following code (at least with glibc 2.5): #include <sys/select.h> #include <alsa/global.h> $ gcc -c --std=c99 x.c In file included from x.c:2: /usr/include/alsa/global.h:134: error: redefinition of 'struct timeval' /usr/include/alsa/global.h:139: error: redefinition of 'struct timespec' (Without #include <sys/select.h> only 'struct timespec' is redefined.) IMHO attempts to define structures which should be defined by system headers are too dangerous - if someone is using preprocessor flags which hide required parts of system headers, it is their problem, and the risk of mismatch is too high. BTW, <time.h> does not provide 'struct timeval' at all, even with _GNU_SOURCE - it defines only 'struct timespec'; however, this does not cause problems, because ALSA headers currently use only pointers to snd_timestamp_t, which works even without a complete definition of 'struct timeval'. We can try to include <sys/time.h> to get 'struct timeval', or even <sys/select.h> (which currently seems to provide both 'struct timeval' and 'struct timespec' even with -ansi, and http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/select.h.html tells that it should always provide their definitions). > > > diff -r 7bc021fb4bf1027b23aa5429ceda1e1e35c7d126 -r 603411fd0c77712cab43cdd5afcf0ff4ebe51a7f include/global.h > --- a/include/global.h Fri Oct 06 10:38:39 2006 +0200 > +++ b/include/global.h Fri Oct 06 11:01:40 2006 +0200 > @@ -130,6 +130,18 @@ int snd_shm_area_destroy(struct snd_shm_ > > int snd_user_file(const char *file, char **result); > > +#ifndef _POSIC_C_SOURCE > +struct timeval { > + time_t tv_sec; /* seconds */ > + long tv_usec; /* microseconds */ > +}; > + > +struct timespec { > + time_t tv_sec; /* seconds */ > + long tv_nsec; /* nanoseconds */ > +}; > +#endif > + > /** Timestamp */ > typedef struct timeval snd_timestamp_t; > /** Hi-res timestamp */

2 3

[alsa-devel] SALSA library in ARM platform
by Nobin Mathew 25 Jun '07

25 Jun '07

Hi, I tried compiling SALSA for ARM. I got few errors. CC=arm-none-linux-gnueabi-gcc ./configure --target=arm-linux --host=i386 --prefix=/usr make Then I am getting following errors See the bottom part /bin/bash ../libtool --tag=CC --mode=compile arm-none-linux-gnueabi-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"salsa-lib\" -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -Wall -g -g -O2 -MT mixer.lo -MD -MP -MF .deps/mixer.Tpo -c -o mixer.lo mixer.c arm-none-linux-gnueabi-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"salsa-lib\" -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I. -Wall -g -g -O2 -MT mixer.lo -MD -MP -MF .deps/mixer.Tpo -c mixer.c -o mixer.o In file included from hcontrol.h:36, from mixer.h:25, from mixer.c:30: hctl_macros.h: In function 'snd_hctl_elem_tlv_read': hctl_macros.h:136: warning: 'snd_ctl_elem_tlv_read' is deprecated (declared at ctl_macros.h:1131) hctl_macros.h: In function 'snd_hctl_elem_tlv_write': hctl_macros.h:142: warning: 'snd_ctl_elem_tlv_write' is deprecated (declared at ctl_macros.h:1138) hctl_macros.h: In function 'snd_hctl_elem_tlv_command': hctl_macros.h:148: warning: 'snd_ctl_elem_tlv_command' is deprecated (declared at ctl_macros.h:1145) mv -f .deps/mixer.Tpo .deps/mixer.Plo /bin/bash ../libtool --tag=CC --mode=link arm-none-linux-gnueabi-gcc -Wall -g -g -O2 -version-number 0:0:1 -o libsalsa.la -rpath /usr/lib control.lo cards.lo pcm.lo pcm_params.lo pcm_misc.lo hcontrol.lo mixer.lo mkdir .libs libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `0:0:1' is not valid version information make[1]: *** [libsalsa.la] Error 1 make[1]: Leaving directory `/home/nmathew/Desktop/salsa-lib-0.0.1/src' make: *** [all-recursive] Error 1

2 3

[alsa-devel] [PATCH] hda: support for S/PDIF out on ASUS M2V
by Mike Crash 25 Jun '07

25 Jun '07

Added support for S/PDIF digital output on ASUS M2V motheboard - added new model "3stack-660-digout" and ALC660VD_3ST_DIG Apply to 1.0.14 driver file patch_realtek.c Signed-off-by: Mike Crash <mike(a)mikecrash.com> *** patch_realtek.c 2007-06-04 09:28:54.000000000 +0200 --- patch_realtek2.c 2007-06-16 21:46:14.000000000 +0200 *************** enum { *** 117,118 **** --- 117,119 ---- ALC660VD_3ST, + ALC660VD_3ST_DIG, ALC861VD_3ST, *************** static const char *alc861vd_models[ALC86 *** 9466,9467 **** --- 9467,9469 ---- [ALC660VD_3ST] = "3stack-660", + [ALC660VD_3ST_DIG]= "3stack-660-digout", [ALC861VD_3ST] = "3stack", *************** static struct snd_pci_quirk alc861vd_cfg *** 9477,9479 **** SND_PCI_QUIRK(0x1043, 0x1339, "Asus G1", ALC660VD_3ST), ! SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST), SND_PCI_QUIRK(0x10de, 0x03f0, "Realtek ALC660 demo", ALC660VD_3ST), --- 9479,9481 ---- SND_PCI_QUIRK(0x1043, 0x1339, "Asus G1", ALC660VD_3ST), ! SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST_DIG), SND_PCI_QUIRK(0x10de, 0x03f0, "Realtek ALC660 demo", ALC660VD_3ST), *************** static struct alc_config_preset alc861vd *** 9501,9502 **** --- 9503,9517 ---- }, + [ALC660VD_3ST_DIG] = { + .mixers = { alc861vd_3st_mixer }, + .init_verbs = { alc861vd_volume_init_verbs, + alc861vd_3stack_init_verbs }, + .num_dacs = ARRAY_SIZE(alc660vd_dac_nids), + .dac_nids = alc660vd_dac_nids, + .dig_out_nid = ALC861VD_DIGOUT_NID, + .num_adc_nids = ARRAY_SIZE(alc861vd_adc_nids), + .adc_nids = alc861vd_adc_nids, + .num_channel_mode = ARRAY_SIZE(alc861vd_3stack_2ch_modes), + .channel_mode = alc861vd_3stack_2ch_modes, + .input_mux = &alc861vd_capture_source, + }, [ALC861VD_3ST] = {

2 1

[alsa-devel] [PATCH] MPU401 lockups
by Serge Nikolaenko 25 Jun '07

25 Jun '07

Hello, The attachement is the fix for mpu to prevent lockups/freezes. Added mutexes with down_trylock() calls, to prevent blocking. Midi in/out not tested - I don't have no midi devices at the moment. My soundcard is ESI Juli@. MB integrated midi is disabled in bios. Last system messages after system freeze when running wine/jackd: kernel: cmd: 0xff failed at 0xac0c (status = 0xb, data = 0x0) ... kernel: BUG: soft lockup detected on CPU#0! kernel: kernel: Call Trace: kernel: <IRQ> [<ffffffff802b0bdb>] softlockup_tick+0xdb/0xf6 kernel: [<ffffffff8028f5d0>] update_process_times+0x42/0x68 kernel: [<ffffffff80271f0c>] smp_local_timer_interrupt+0x34/0x55 kernel: [<ffffffff802725e8>] smp_apic_timer_interrupt+0x51/0x69 kernel: [<ffffffff8025ace6>] apic_timer_interrupt+0x66/0x70 kernel: [<ffffffff889c600d>] :snd_mpu401_uart:mpu401_read_port+0x4/0x8 kernel: [<ffffffff889c62f0>] :snd_mpu401_uart:_snd_mpu401_uart_interrupt+0x4c/0x70 kernel: [<ffffffff889c6391>] :snd_mpu401_uart:snd_mpu401_uart_interrupt+0x13/0x1a kernel: [<ffffffff88a1f34b>] :snd_ice1724:snd_vt1724_interrupt+0x4e/0x13a kernel: [<ffffffff80210b93>] handle_IRQ_event+0x25/0x53 kernel: [<ffffffff802b202a>] handle_fasteoi_irq+0x92/0xd1 kernel: [<ffffffff8026862a>] do_IRQ+0xff/0x16d kernel: [<ffffffff8025a631>] ret_from_intr+0x0/0xa kernel: <EOI> [<ffffffff802f5df7>] proc_info_read+0x0/0xb9 kernel: [<ffffffff802f5df9>] proc_info_read+0x2/0xb9 kernel: [<ffffffff8020b14e>] vfs_read+0xcb/0x173 kernel: [<ffffffff80211847>] sys_read+0x45/0x6e kernel: [<ffffffff8025a11e>] system_call+0x7e/0x83

2 1

Re: [alsa-devel] Fwd: Problems with hda_intel, Santa Rosa, and suspend
by Takashi Iwai 25 Jun '07

25 Jun '07

[Please don't strip Cc to ML!] At Tue, 19 Jun 2007 15:54:42 -0500, Matt Mullins wrote: > > I played around with probe_mask, and found that probe_mask=0x1 causes > the error, but probe_mask=0x2 does not cause the timeout. Codec 1 is > my Sigmatel STAC9205, which is what plays sound on my laptop, and > codec 2 is my Conexant modem. The modem isn't the codec causing > problems; the audio codec is! OK, good to know. Does this problem occur with S2D? What is the very first command that triggers this timeout error? I'm wondering what is the difference between them -- according to your report, reloading the module fixes the problem. But, the resume callback is almost identical with the re-initiailzation. Perhaps it's something to do with the power-state management. What about the patch below? Takashi diff -r c531d63e820b sound/pci/hda/hda_intel.c --- a/sound/pci/hda/hda_intel.c Wed Jun 20 12:03:09 2007 +0200 +++ b/sound/pci/hda/hda_intel.c Wed Jun 20 12:09:40 2007 +0200 @@ -1450,7 +1450,7 @@ static int azx_suspend(struct pci_dev *p pci_disable_msi(chip->pci); pci_disable_device(pci); pci_save_state(pci); - pci_set_power_state(pci, pci_choose_state(pci, state)); + /* pci_set_power_state(pci, pci_choose_state(pci, state)); */ return 0; }

2 4

[alsa-devel] hda-intel without headphone output
by Robert Lemmen 25 Jun '07

25 Jun '07

hi everyone, i have a fujitsu siemens amilo pro v3515 notebook, with a via VT8251/ VT8237A chipset. sound works fine through the speakers, but i don't get anything through the headphones, no headphone channel shows up in the mixer, and the headphone jack switch doesn't mute the speakers. i have alsa 1.0.13, and a 2.6.18 kernel. i tried all "model" settings that i could find in ALSA-Configuration in the kernel tree. lspci -nv gives 04:01.0 0403: 1106:3288 (rev 10) Subsystem: 1734:10cb Flags: bus master, fast devsel, latency 0, IRQ 58 Memory at c9100000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 (only the stanza for the sound card, yell if you need more), and /proc/asound/card0/codec#0 gives: Codec: Generic 14f1 ID 5045 Address: 0 Vendor Id: 0x14f15045 Subsystem Id: 0x173410cb Revision Id: 0x100100 Default PCM: rates 0x140, bits 0x0e, types 0x1 Default Amp-In caps: N/A Default Amp-Out caps: N/A Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x2b, nsteps=0x2b, stepsize=0x05, mute=1 Amp-Out vals: [0x28 0x28] Pincap 0x0810014: OUT EAPD Detect Pin Default 0x92170110: [Fixed] Speaker at Int Front Conn = Analog, Color = Unknown Pin-ctls: 0x40: OUT Power: 0x0 Connection: 2 0x19* 0x17 Node 0x11 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x2b, nsteps=0x2b, stepsize=0x05, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x08113c: IN OUT HP Detect Pin Default 0x0121401f: [Jack] HP Out at Ext Rear Conn = 1/8, Color = Green Pin-ctls: 0xc0: OUT HP Power: 0x0 Connection: 2 0x19* 0x17 Node 0x12 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x2b, nsteps=0x2b, stepsize=0x05, mute=1 Amp-Out vals: [0xab 0xab] Pincap 0x08113c: IN OUT HP Detect Pin Default 0x01a19020: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink Pin-ctls: 0x20: IN Power: 0x0 Connection: 2 0x19* 0x17 Node 0x13 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x214571f0: [Jack] SPDIF Out at Sep Rear Conn = Optical, Color = Yellow Pin-ctls: 0x00: Connection: 1 0x18 Node 0x14 [Pin Complex] wcaps 0x400081: Stereo Pincap 0x081124: IN Detect Pin Default 0x97a7012e: [Fixed] Mic at Int Riser Conn = Analog, Color = Unknown Pin-ctls: 0x20: IN Node 0x15 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x400001f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Node 0x16 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out Amp-Out caps: ofs=0x07, nsteps=0x07, stepsize=0x0b, mute=1 Amp-Out vals: [0x06] Node 0x17 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x14, nsteps=0x2b, stepsize=0x05, mute=1 Amp-In vals: [0x94 0x94] [0x17 0x17] [0x94 0x94] [0x94 0x94] [0x94 0x94] Power: 0x0 Connection: 5 0x19 0x14 0x12 0x11 0x15 Node 0x18 [Audio Output] wcaps 0x211: Stereo Digital PCM: rates 0x040, bits 0x06, types 0x5 Node 0x19 [Audio Output] wcaps 0xc11: Stereo PCM: rates 0x540, bits 0x0e, types 0x1 Power: 0x0 Node 0x1a [Audio Input] wcaps 0x100d0b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x17, stepsize=0x05, mute=1 Amp-In vals: [0x17 0x17] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] Power: 0x0 Connection: 5 0x17 0x14 0x12 0x11 0x15* Node 0x1b [Vendor Defined Widget] wcaps 0xf00000: Mono please tell me if there is anything i can do, any additional information you need, or any general tipps. thanks robert -- Robert Lemmen http://www.semistable.com

3 13

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

25 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 *STATISTICS* (a.k.a. list of aces) Name Regressions fixed since 21-Jun-2007 Andi Kleen 1 Hugh Dickins 1 Jean Delvare 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 Memory management Subject : 2.6.22-rc5-yesterdaygit with VM debug: BUG in mm/rmap.c:66: anon_vma_link ? References : http://lkml.org/lkml/2007/6/25/45 Submitter : Petr Vandrovec <petr(a)vmware.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/

1 0

[alsa-devel] alsa-lib: pcm_softvol.c: attenuation curve - it seems to be too quiet at full volume
by John L. Utz III 25 Jun '07

25 Jun '07

Hello All; I am in release testing with a fix to our product to use 4 channels on a CMEDIA 8738-MC6 (previously we only used 2 channels on the CMEDIA and a separate soundcard for the 2 back channels). The 8738 is a pretty funny old duck of a chip and i am trying to work around a subset of it's many idiosyncracies. :-) The most glaring defect is the absence of hard volume on the back channels *and* that the back channel is louder than the front channel. Obviously, this is a great candidate for softvol! Softvol works quite well *except* that the max volume for the rear channel is now much quieter than it is without softvol. :-( Is there anything i can do to alter this behavior? I notice that there is an initial minimal DB in the file: #define PRESET_MIN_DB -51.0 is this where everything starts from? if i bump this up, will i get a higher max volume? tnx! johnu

2 1

[alsa-devel] Query regarding pointer callback
by Pharaoh . 25 Jun '07

25 Jun '07

Hi In Writing an ALSA driver, it is said that pointer callback is called usually from the buffer-update routine in the pcm middle layer, which is invoked when snd_pcm_period_elapsed() is called in the interrupt routine. Then the pcm middle layer updates the position and calculates the available space, and wakes up the sleeping poll threads, etc What are the other places from where pointer callback is called? If it is not called from any other routine then does it mean that interrupts are occuring?

2 2

[alsa-devel] Intel Realtek ALC268 don't sound
by Antonio Rguez. Capita 25 Jun '07

25 Jun '07

Hi, I tried lastest HG driver version of Alsa, with patch included for ALC268. Apparently card is detected and mixer show correctly volumes bars, but don't sound. I tried option 3stack and auto in /etc/modprobe.d/alsa-base but nothing difference. I've a HP Pavilion dv6528 with Santa Rosa. Please tell me that I can do? Thanks

1 0

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

25 Jun '07

Here is the result : $ sudo dmesg -c $ sudo rmmod snd-hda-intel && sudo modprobe snd-hda-intel probe_mask=1 $ dmesg [ 638.324000] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 638.368000] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 [ 638.368000] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 638.400000] ALSA /home/alboot/Sources/alsa1.0.14rc4/alsa-driver-1.0.14rc4/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:698: codec_mask = 0x3 [ 638.576000] ALSA /home/alboot/Sources/alsa1.0.14rc4/alsa-driver-1.0.14rc4/pci/hda/hda_codec.c:1820: hda_codec: model 'medion' is selected for config 161f:2054 (Medion laptop) I can hear a quick sound (like a "bip") when I enter the command but after that, the sound doesn't work.

1 0

[alsa-devel] No sound on Medion laptop (intel 82801G)
by albox＠free.fr 25 Jun '07

25 Jun '07

Hi, I reported a bug about medion laptops having an intel 82801G sound card that doesn't work with ALSA 1.0.14rc4 on Kubuntu : https://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_i… I didn't get any news yet. As I said, I'm willing to help. Any ideas about what I should check ? Is there any web page that could help me to detect the problem ? Thanks

2 1