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! > 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. Yes and yes. Using "hw" gives the same wrong speed with -lasound, and standard command-line aplay does also. Evidently I understand even less than I thought. I had expected that with the card hardware set to 44100Hz and locked, that playing a 44100Hz file would be straightforward. Maybe the file is not right. I may have to pause testing for a few days now. Thanks again Alan _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
