From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Revell Subject: Re: Couple of questions Date: Fri, 17 Mar 2006 19:17:03 -0500 Message-ID: <1142641024.25258.142.camel@mindpipe> References: <1142467271.9298.7.camel@localhost.localdomain> <1142552045.9236.9.camel@localhost.localdomain> <1142554597.9395.25.camel@mindpipe> <1142627252.9449.9.camel@localhost.localdomain> <1142638164.9449.16.camel@localhost.localdomain> <1142639182.25258.126.camel@mindpipe> <1142639470.9449.24.camel@localhost.localdomain> <1142639891.25258.134.camel@mindpipe> <1142640536.9449.29.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from viper.oldcity.dca.net (viper.oldcity.dca.net [216.158.38.4]) by alsa.jcu.cz (ALSA's E-mail Delivery System) with SMTP id 109041BF for ; Sat, 18 Mar 2006 01:17:06 +0100 (MET) In-Reply-To: <1142640536.9449.29.camel@localhost.localdomain> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Adrian McMenamin Cc: Takashi Iwai , alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org On Sat, 2006-03-18 at 00:08 +0000, Adrian McMenamin wrote: > On Fri, 2006-03-17 at 18:58 -0500, Lee Revell wrote: > > On Fri, 2006-03-17 at 23:51 +0000, Adrian McMenamin wrote: > > > On Fri, 2006-03-17 at 18:46 -0500, Lee Revell wrote: > > > > On Fri, 2006-03-17 at 23:29 +0000, Adrian McMenamin wrote: > > > > > > > > > > So, just to be clear. When I am transferring a "period" I should > > > > > actually stream half a period's worth of bytes into the channel > > > > > playing > > > > > the left and half a period into the right - and can advance each dma > > > > > transfer through the buffer by half a period length on both the left > > > > > and > > > > > the right side of the buffer > > > > > > > > No, one period. > > > > > > > > > > > > > How does that work? That would imply that there were half as many > > > periods in the DMA buffer as specified here... > > > > > > static snd_pcm_hardware_t snd_pcm_aica_playback_hw = { > > > > > > .info = (SNDRV_PCM_INFO_NONINTERLEAVED), > > > .formats = > > > (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | > > > SNDRV_PCM_FMTBIT_IMA_ADPCM), > > > .rates = SNDRV_PCM_RATE_8000_48000, > > > .rate_min = 8000, > > > .rate_max = 48000, > > > .channels_min = 2, > > > .channels_max = 2, > > > .buffer_bytes_max = AICA_BUFFER_SIZE, > > > .period_bytes_min = AICA_PERIOD_SIZE, > > > .period_bytes_max = AICA_PERIOD_SIZE, > > > .periods_min = AICA_PERIOD_NUMBER, > > > .periods_max = AICA_PERIOD_NUMBER, > > > }; > > > > > > > > > As the buffer and period (in bytes) size is constant. > > > > > > > > > > That's why the maximum buffer and period is in bytes not frames. Stereo > > has twice as many bytes per frame than mono. > > > > Err...yes :) > > I am still confused though. In mono, every time a period is played a new > period is loaded into the DMA buffer and then transferred into the > hardware's buffer. > > How does this work now - wait for one period to play on the left (or > right) channel and then transfer one period's worth on the left and > right channel (ie ALSA fills the buffer up with 2 periods at a go in > stereo) or transfer half a period's worth on each channel but move the > copy pointer on a full period (ie ALSA transfers just one period's worth > which translates as half a period in either channel) > > Maybe I'm misunderstanding but... You wait for one period to play in both channels then transfer one period for the left channel and one period for the right. So each DMA transfer moves twice as much data as the mono case. Lee ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642