[alsa-devel] Please help in adding ams-delta support to ASoC

Commit Message

Peter Ujfalusi June 10, 2009, 8:12 a.m. UTC

On Tuesday 09 June 2009 18:17:42 ext Janusz Krzysztofik wrote:
> Peter Ujfalusi wrote:
> > I'm kind of bad at visualizing things, is it possible to put somewhere
> > the screenshoot of the scope showing at least one sample?
>
> Good idea. I'll take some screenshots for future reference and let you
> know when available.
>
> > I have been looking for clues around the net, and it seams that the codec
> > in question has stereo 16 bit format.
>
>  From the very minimal mcbsp setup I get best audio experience with
> (using original omap-alsa based driver - see below), it looks like the
> codec speeks DSP (single phase), 16-bit mono @8kHz on output, but 8-bit
> stereo @8kHz on input. Capturing one channel only (the first one) I
> can't hear myself speaking, so audio from the microphone must be sent
> over the second input channel.
>
> +static struct omap_mcbsp_reg_cfg mcbsp_regs = {
> +       .spcr2 = FREE | XINTM(3) | XRST,
> +       .spcr1 = RINTM(3) | RRST,
> +       .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
> +       .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
> +};
>
>
> +static snd_pcm_hardware_t vc_snd_omap_alsa_playback = {
> +       .info = (SNDRV_PCM_INFO_INTERLEAVED |
> SNDRV_PCM_INFO_BLOCK_TRANSFER |
> +                SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
> +       .formats = (SNDRV_PCM_FMTBIT_S16_LE),
> +       .rates = (SNDRV_PCM_RATE_8000 |
> +                 SNDRV_PCM_RATE_KNOT),
> +       .rate_min = 8000,
> +       .rate_max = 8000,
> +       .channels_min = 1,
> +       .channels_max = 1,
> +       .buffer_bytes_max = 128 * 1024,
> +       .period_bytes_min = 32,
> +       .period_bytes_max = 8 * 1024,
> +       .periods_min = 16,
> +       .periods_max = 255,
> +       .fifo_size = 0,
> +};
> +
> +static snd_pcm_hardware_t vc_snd_omap_alsa_capture = {
> +       .info = (SNDRV_PCM_INFO_INTERLEAVED |
> SNDRV_PCM_INFO_BLOCK_TRANSFER |
> +                SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
> +       .formats = (SNDRV_PCM_FMTBIT_U8),
> +       .rates = (SNDRV_PCM_RATE_8000 |
> +                 SNDRV_PCM_RATE_KNOT),
> +       .rate_min = 8000,
> +       .rate_max = 8000,
> +       .channels_min = 2,
> +       .channels_max = 2,
> +       .buffer_bytes_max = 128 * 1024,
> +       .period_bytes_min = 32,
> +       .period_bytes_max = 8 * 1024,
> +       .periods_min = 16,
> +       .periods_max = 255,
> +       .fifo_size = 0,
> +};
>
> For other combinations of single/dual phase, sample size, mono/stereo,
> sound I get is much more distorted. Playing with polarisation and delays
> for getting still better experience remains on my todo list.
>
> BTW, I can't see any way of specifying a similiar mcbsp setup in new
> omap asoc framework.

Yeah, 8 bit is not supported - in fact only 16 bit is supported - with ASoC on 
OMAP.
But you should be able to use the playback with the current ASoC.

>
> --------------
>
> > --- a/sound/soc/omap/omap-pcm.c
> > +++ b/sound/soc/omap/omap-pcm.c
> > @@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct
> > snd_pcm_substream *substream, int cmd)
> >         case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> >                 prtd->period_index = 0;
> >                 omap_start_dma(prtd->dma_ch);
> > +               printk("omap_pcm_trigger START: DMA pointer at 0x%08x\n",
> > +                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
> >                 break;
> >
> >         case SNDRV_PCM_TRIGGER_STOP:
> >         case SNDRV_PCM_TRIGGER_SUSPEND:
> >         case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> > +               printk("omap_pcm_trigger STOP: DMA pointer at 0x%08x\n",
> > +                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
> >                 prtd->period_index = -1;
> >                 omap_stop_dma(prtd->dma_ch);
> >                 break;
> >
> >
> > Than start a playback, and stop it with CTRL+C, see if the two pointers
> > are different...
>
> Both playback and capture start with their own but always the same value
> (something like 0x1101a0d0 for playback, 0xe101a0d0 for capture), and
> always stop with this value unchanged.

Hmm, this means that the DMA was not running at all (since it has not been 
progressed). So you might have the missing DMA interrupt problem, but first we 
should get the DMA to actually run.
Looking at the dma code for clues...
Even bigger Hmmm...
For OMAP1 the DMA synchronization is not configured.
I just wonder how this supposed to be working on OMAP1 platforms.
Anyway, can you try the following patch (and please keep the previous printk 
in the omap-pcm.c):

                ccr = dma_read(CCR2(lch));

in the 	if (cpu_class_is_omap1()) { path...

The interesting thing is the following:
the old ALSA implementation configured the DMA in this way:
omap_set_dma_transfer_params(channel, dt, cen, cfn, 0x00, 0, 0);
Meaning, no DMA synchronization, which is fair, since the DMA code for OMAP1 
does not configured it anyway.


>
> > 2) I would I think try to port the 2.6.28 pure ALSA version to the head
> > of l- o, with minimal (only the needed) changes and see if it is still
> > working.
>
> Trying to use the new driver on the last l-o revision supporting both
> omap-alsa and omap asoc, I got a broken system that hanged up completely
> at sound device first access. The same for earlier and later l-o
> revisions I have ever tried, unlike mainline that at least does not
> hang. From all that I would conclude that porting the old driver could
> be just waste of time, as the problem is probably omap asoc related, not
> just omap, probably existed from the start of omap asoc life, and could
> be solved on any l-o or mainline revision, including those eariler l-o
> that supported both frameworks. But I can be wrong, of course.

There seams to be no major difference between the 2.6.28 and the latest 
arch/arm/plat-omap/dma.c and mcbsp.c
I would expected that by just copying (I know that there are other things 
involved) the old ALSA arm directory to the latest kernel and compiling it 
should be working... It seams I was wrong.

Comments

Janusz Krzysztofik June 10, 2009, 10:27 a.m. UTC | #1

Hi Peter,

Wednesday 10 June 2009 10:12:32 Peter Ujfalusi napisał(a):
> On Tuesday 09 June 2009 18:17:42 ext Janusz Krzysztofik wrote:
> > +static struct omap_mcbsp_reg_cfg mcbsp_regs = {
> > +       .spcr2 = FREE | XINTM(3) | XRST,
> > +       .spcr1 = RINTM(3) | RRST,
> > +       .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
> > +       .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
> > +};
> >
> > BTW, I can't see any way of specifying a similiar mcbsp setup in new
> > omap asoc framework.
>
> Yeah, 8 bit is not supported - in fact only 16 bit is supported - with ASoC
> on OMAP.

Not only this. AFAICS, there is no way of specifying single phase stereo (with 
XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)). Isn't this 
required for correct DSP_A/DSP_B support?

> But you should be able to use the playback with the current ASoC.

Definitelly yes. I am aware that the above limitations have nothing to do with 
the main problem, as with current mcbsp code I should always be able to get 
some kind of noise at least using one of supported formats, as far as 
clocking is set up correctly.

> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
> data_type, int elem_count,
>                 ccr &= ~(1 << 5);
>                 if (sync_mode == OMAP_DMA_SYNC_FRAME)
>                         ccr |= 1 << 5;
> +               if (dma_trigger)
> +                       ccr |= dma_trigger & 0x1f;
>                 dma_write(ccr, CCR(lch));
>
>                 ccr = dma_read(CCR2(lch));

Applied, sorry, did not help (with capture, unlike playback, set up for 
internal clocking for as much device isolation as possible).

# aplay -D hw:0,0 -f S16_LE /dev/urandom
Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 8000 Hz, 
Mono
omap_pcm_trigger START: DMA pointer at 0x11d4a0d0
omap_pcm_trigger STOP: DMA pointer at 0x11d4a0d0 error
# arecord -D hw:0,0 -f S16_LE -t raw /dev/null
Recording raw data '/dev/null' : Signed 16 bit Little Endian, Rate 8000 Hz, 
Mono
omap_pcm_trigger START: DMA pointer at 0xe101a0d0
arecord: pcm_read:1529: read error: Input/output error
omap_pcm_trigger STOP: DMA pointer at 0xe101a0d0
# cat /dev/urandom >/dev/dsp
omap_pcm_trigger START: DMA pointer at 0x11d4a0d0
cat: write error: Input/output error
omap_pcm_trigger STOP: DMA pointer at 0x11d4a0d0
# cat /dev/dsp >/dev/null
omap_pcm_trigger START: DMA pointer at 0xe101a0d0
cat: read error: Input/output eromap_pcm_trigger STOP: DMA pointer at 
0xe101a0d0
ror
#

BTW, I have found that, when invoked with those "-D hw:0,0 -f SE16_LE" 
options, aplay/arecord behave correctly, exactly as Mark has pointed out once 
at the beginning of this huge thread, stopping themselves after 10 seconds 
with an error message, without need for ^C.

> I would expected that by just copying (I know that there are other things
> involved) the old ALSA arm directory to the latest kernel and compiling it
> should be working... It seams I was wrong.

Anyway, if you find porting one or another framework, back or forward, 
helpfull in any way, just let me know, I can try.

Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -266,6 +266,8 @@  void omap_set_dma_transfer_params(int lch, int data_type, 
int elem_count,
                ccr &= ~(1 << 5);
                if (sync_mode == OMAP_DMA_SYNC_FRAME)
                        ccr |= 1 << 5;
+               if (dma_trigger)
+                       ccr |= dma_trigger & 0x1f;
                dma_write(ccr, CCR(lch));