[alsa-devel] SALSA and aplay
Takashi Iwai
tiwai at suse.de
Tue Jul 17 17:09:36 CEST 2007
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?
Anyway, I still don't think it's a bug of salsa-lib.
Looking the prameters above, it seems you're using "default" PCM,
right? If so, try to use "hw" instead. This should make the
parameters identical.
Takashi
diff -r 3d5552e4594a src/pcm.c
--- a/src/pcm.c Tue Jul 10 14:10:37 2007 +0200
+++ b/src/pcm.c Tue Jul 17 17:04:47 2007 +0200
@@ -284,7 +284,7 @@ const char *_snd_pcm_state_names[] = {
STATE(DISCONNECTED),
};
-const char *_snd_pcm_access_names[] = {
+const char *_snd_pcm_access_names[SND_MASK_MAX + 1] = {
ACCESS(MMAP_INTERLEAVED),
ACCESS(MMAP_NONINTERLEAVED),
ACCESS(MMAP_COMPLEX),
@@ -292,7 +292,7 @@ const char *_snd_pcm_access_names[] = {
ACCESS(RW_NONINTERLEAVED),
};
-const char *_snd_pcm_format_names[] = {
+const char *_snd_pcm_format_names[SND_MASK_MAX + 1] = {
FORMAT(S8),
FORMAT(U8),
FORMAT(S16_LE),
@@ -333,7 +333,7 @@ const char *_snd_pcm_format_names[] = {
FORMAT(U18_3BE),
};
-static const char *_snd_pcm_format_aliases[SND_PCM_FORMAT_LAST+1] = {
+static const char *_snd_pcm_format_aliases[SND_MASK_MAX + 1] = {
FORMAT(S16),
FORMAT(U16),
FORMAT(S24),
@@ -345,7 +345,7 @@ static const char *_snd_pcm_format_alias
FORMAT(IEC958_SUBFRAME),
};
-const char *_snd_pcm_format_descriptions[] = {
+const char *_snd_pcm_format_descriptions[SND_MASK_MAX + 1] = {
FORMATD(S8, "Signed 8 bit"),
FORMATD(U8, "Unsigned 8 bit"),
FORMATD(S16_LE, "Signed 16 bit Little Endian"),
@@ -418,11 +418,11 @@ const char *_snd_pcm_type_names[] = {
PCMTYPE(EXTPLUG),
};
-const char *_snd_pcm_subformat_names[] = {
+const char *_snd_pcm_subformat_names[SND_MASK_MAX + 1] = {
SUBFORMAT(STD),
};
-const char *_snd_pcm_subformat_descriptions[] = {
+const char *_snd_pcm_subformat_descriptions[SND_MASK_MAX + 1] = {
SUBFORMATD(STD, "Standard"),
};
More information about the Alsa-devel
mailing list