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

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