[alsa-devel] SALSA and aplay

[Takashi Iwai]

At Wed, 18 Jul 2007 16:01:11 +0100,
Alan Horstmann wrote:
> 
> On Tuesday 17 July 2007 16:09, you wrote:
> > At Tue, 17 Jul 2007 15:38:00 +0100,
> >
> > Alan Horstmann wrote:
> > > On Tuesday 17 July 2007 12:58, you wrote:
> > > > At Tue, 17 Jul 2007 12:33:36 +0100,
> > > >
> > > > Alan Horstmann wrote:
> > > > > On Monday 16 July 2007 13:30, you wrote:
> > > > >
> > > > > I have very crudely hacked the aplay code and included it as a
> > > > > function in code to make a simple key-press play a set file.  Linking
> > > > > -lasound this seems to work fine.  However, linking -lsalsa results
> > > > > in the file playing too fast, but not as much as double.
> > > >
> > > > Probably you are playing the samples with the hardware parameters that
> > > > the hardware doesn't support.  alsa-lib has plugin layer which can
> > > > convert appropriatley on the fly.
> > > >
> > > > > As my experimental system has ice1712 card, I am having to use a 10
> > > > > track WAV file S32_LE as I think that is the only format supported,
> > > > > the card working with 24-bits loose fitted in 32-bits.
> > >
> > > Are you refering to parameters other than rate, format, channels?  I
> > > think those are correct now.  I have logged
> > > 	snd_pcm_hw_params_dump(params, log);
> > > 	snd_pcm_hw_params_dump(swparams, log);
> > > In salsa:-
> > > ACCESS:  RW_INTERLEAVED
> > > FORMAT:  S32_LE hebrew
> > > SUBFORMAT:  STD
> > > SAMPLE_BITS: 32
> > > FRAME_BITS: 320
> > > CHANNELS: 10
> > > RATE: 44100
> > > PERIOD_TIME: (37142 37143)
> > > PERIOD_SIZE: 1638
> > > PERIOD_BYTES: 65520
> > > PERIODS: (4 5)
> > > BUFFER_TIME: (148594 148595)
> > > BUFFER_SIZE: 6553
> > > BUFFER_BYTES: 262120
> > > TICK_TIME: 1000
> > > tstamp_mode: NONE
> > > period_step: 1
> > > sleep_min: 0
> > > avail_min: 1638
> > > xfer_align: 1638
> > > silence_threshold: 0
> > > silence_size: 0
> > > boundary: 1717829632
> > >
> > > In alsa:-
> > > ACCESS:  RW_INTERLEAVED
> > > FORMAT:  S32_LE
> > > SUBFORMAT:  STD
> > > SAMPLE_BITS: 32
> > > FRAME_BITS: 320
> > > CHANNELS: 10
> > > RATE: 44100
> > > PERIOD_TIME: (21333 21334)
> > > PERIOD_SIZE: (940 941)
> > > PERIOD_BYTES: (37600 37640)
> > > PERIODS: (5 7)
> > > BUFFER_TIME: (127981 127982)
> > > BUFFER_SIZE: 5644
> > > BUFFER_BYTES: 225760
> > > TICK_TIME: 0
> > > start_mode: DATA
> > > xrun_mode: STOP
> > > tstamp_mode: NONE
> > > period_step: 1
> > > sleep_min: 0
> > > avail_min: 940
> > > xfer_align: 940
> > > silence_threshold: 0
> > > silence_size: 0
> > > boundary: 1479540736
> > >
> > > Is there significance to 'hebrew' on the format line?  The other numbers
> > > mean little to me.  Sorry to trouble you.
> >
> > The string looks strange.  Could you try the patch below?
> 
> Patching file pcm.c using Plan A...
> Hunk #1 succeeded at 284.
> Hunk #2 succeeded at 292.
> Hunk #3 succeeded at 333.
> Hunk #4 succeeded at 345.
> patch unexpectedly ends in middle of line
> Hunk #5 succeeded at 418.
> done
> 
> With patch applied, the 'hebrew' is gone!

Thanks for confirmation.  The patch was included in 0.0.8 release.


Takashi