On Thu, 2007-10-11 at 10:50 +0200, Takashi Iwai wrote:
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?
Because you programmed in such a way :)
Ok, then I have to change the code ... but where? ;-)
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.
The problem is that the driver still accepts the 16bit format mono stream. That's what I pointed in my previous post. There is no format conversion in alsa-lib at all. It's only channel expansion
from mono to stereo. The hardware accepts 16bit stereo. So, there is
nothing wrong from this viewpoint.
By "conversion framework" I actually meant the channel expansion - code which somehow "works in the data" before sending it to the hardware.
And yes, 16 bit samples are the only sample format supported by the hardware. But "by design of the hardware" the smallest write access has to be 32 bit wide (2 samples, stereo only)
Maybe it's not about plugin but a problem of mmap with your device?
Well, as I said before, as soon as I use a stereo .wav-file a simple call to memcpy() is used by alsa-lib to transfer the data to the hardware (snd_pcm_area_copy(), pcm.c, ca. line 2551, alsa-lib 1.0.14a). In this case the PCM Plugin isn't used at all - the output of aplay -v looks like:
Playing WAVE 'music.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'Lorenz' AC97 Digital Controller' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 4096 period_size : 1024 period_time : 23219 tick_time : 4000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1024 xfer_align : 1024 start_threshold : 4096 stop_threshold : 4096 silence_threshold: 0 silence_size : 0 boundary : 1073741824
So mmap on the controller's memory works - using 32 bit accesses only. And at that place in alsa-lib, I never saw an amount of data which is _not_ a multiple of 32 bits - or this just a coincidence?
So, do I understand you right, when I say: an ALSA driver does _not_ hav ethe possibility to force alsa-lib to write 32 bit entities, only?
I guess, we have to change the hardware here - it's an FPGA, so that's not a problem in principle - but it complicates the hardware, making it accept 16bit accesses.
Joachim