On Wed, 2007-10-10 at 15:22 +0200, Takashi Iwai wrote: > > > At Fri, 05 Oct 2007 19:09:53 +0200, > > > Joachim Foerster wrote: > > > > > > > > Hi ALSA devs, > > > > > > > > meanwhile I tried to put a constraint on SNDRV_PCM_HW_PARAM_FRAME_BITS > > > > by the use of snd_pcm_hw_constraint_minmax() function with min=32 and > > > > max=32, but still no success - the ALSA Library still makes 16bit > > > > accesses, when playing mono (1 channel) files. > > > > > > > > Any ideas? > > > > > > Could you show the chain of plugins via aplay -v ? > > > I'm not sure which plugin requires S16. Possibly, the rate converter. > > > > bash-3.00# aplay -v -M ../Absage.wav > > Playing WAVE '../Absage.wav' : Signed 16 bit Little Endian, Rate 16000 > > Hz, Mono > > Well, the sample itself is 16bit format, and your hardware *does* > support 16bit format. Why to be 32bit? Well actually, we are on a embedded system here. The bus is 32bit wide (Xilinx ML403, PowerPC 405, OBP). So, why waste resources with two 16bit accesses? One sample is 16bits. But we have two channels (stereo only). Thus the controller expects a frame with 32bit data - two samples at the same time. Joachim PS: As soon as stereo .wav-files are used, there is no problem, because then the "conversion framework" and the Plug PCM are not used - just a plain memcpy which results in 32bit accesses. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
