[alsa-devel] How to enforce 32bit access?
mls.JOFT at gmx.de
Thu Oct 11 15:30:51 CEST 2007
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
Playing WAVE 'music.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Plug PCM: Hardware PCM card 0 'Lorenz' AC97 Digital Controller' device 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_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.
More information about the Alsa-devel