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

[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