How to enforce 32bit access?

How to enforce 32bit access?

[Joachim Foerster]

Hi ALSA devs,

(based on a Xilinx ML403, PPC405, OPB bus)
I have a custom sound controller, which allows 32bit write accesses to
its IO memory, only. The controller supports S16_LE, S16_BE, U16_LE,
U16_BE with min. and max. 2 channels (stereo), only! => So a frame has
to be 32bits wide and one frame has to be written at one point of time
(= one 32bit bus access).

Now, playing a 16kHz, S16_LE, Mono .wav-file with aplay invokes the
conversion framework of the alsa-lib. The following line of code (of
pcm_plugin.h) is executed:

conv_xx12_xx12: as_u16(dst) = as_u16c(src);

This is a 16bit access and thus fails with a Bus error/Kernel Oops.

Therefore my question is:

In my driver for the controller, how do I tell ALSA, that it is only
allowed to write in 32bit quantities?
Is this possible at all?
Or do I have to use a special .asoundrc file?

Thanks,
 Joachim

PS: 16bit, signed/unsigned, LE/BE, stereo (!) .wav files can be played
without any problem.

Re: How to enforce 32bit access?

[Joachim Foerster]

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?

On Tue, 2007-10-02 at 17:34 +0200, Joachim Foerster wrote:
> [...]
> 
> Therefore my question is:
> 
> In my driver for the controller, how do I tell ALSA, that it is only
> allowed to write in 32bit quantities?
> Is this possible at all?
> Or do I have to use a special .asoundrc file?

Thanks,
 Joachim

Re: How to enforce 32bit access?

[Takashi Iwai]

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.


Takashi

> On Tue, 2007-10-02 at 17:34 +0200, Joachim Foerster wrote:
> > [...]
> > 
> > Therefore my question is:
> > 
> > In my driver for the controller, how do I tell ALSA, that it is only
> > allowed to write in 32bit quantities?
> > Is this possible at all?
> > Or do I have to use a special .asoundrc file?
> 
> Thanks,
>  Joachim
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: How to enforce 32bit access?

[Joachim Foerster]

Hi Takashi,

On Tue, 2007-10-09 at 11:08 +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
Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 16000
  exact rate   : 16000 (16000/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 64000
  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
Slave: 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         : 16000
  exact rate   : 16000 (16000/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 64000
  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
Bus error

The kernel messages because of the bus error are:
[22592.313922] Data machine check in kernel mode.
[22592.318321] Oops: machine check, sig: 7 [#1]
[22592.322552] NIP: c0003478 LR: c0003304 CTR: 0ff6c988
[22592.327482] REGS: c0230f50 TRAP: 0202   Not tainted
(2.6.23-rc2-g2f9f7e35-dirty)
[22592.334901] MSR: 00029030 <EE,ME,IR,DR>  CR: 22008084  XER: 00000000
[22592.341213] TASK = c3d82420[1049] 'aplay' THREAD: c2354000
[22592.346476] GPR00: 00000000 c2355f40 c3d82420 00004000 c2355e28
00000000 00000000 00030002
[22592.354769] GPR08: c3d82764 00000002 00029032 00000000 10020000
100254ac 00000000 10020000
[22592.363063] GPR16: 7fa4c480 7fa4c58c 00000001 7fa4c4a0 00000400
7fa4c460 00000001 00000000
[22592.371357] GPR24: 00000000 0ff6c988 00000002 00000004 000003fc
1002c6d0 0ffe6b1c 3001e010
[22592.379823] NIP [c0003478] do_user_signal+0x8/0xc4
[22592.384576] LR [c0003304] ret_from_crit_exc+0x0/0xf8
[22592.389498] Call Trace:
[22592.391922] [c2355f40] [c0003304] ret_from_crit_exc+0x0/0xf8
(unreliable)
[22592.398655] Instruction dump:
[22592.401595] 4819ae75 3d400002 614a1032 7d400124 54290024 81290028
71200004 40a2ffdc
[22592.409282] 71200002 4182fe14 614a8000 7d400124 <806100b0> 70600001
41820058 91a10044

But don't think that they are very useful. They occur as soon as the
alsa-lib reaches the line I described in my first mail.

 Joachim

Re: How to enforce 32bit access?

[Takashi Iwai]

At Wed, 10 Oct 2007 15:19:42 +0200,
Joachim Foerster wrote:
> 
> Hi Takashi,
> 
> On Tue, 2007-10-09 at 11:08 +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?


Takashi

Re: How to enforce 32bit access?

[Joachim Foerster]

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.

Re: How to enforce 32bit access?

[Takashi Iwai]

At Wed, 10 Oct 2007 17:40:08 +0200,
Joachim Foerster wrote:
> 
> 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?

Because you programmed in such a way :)

> 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.

Maybe it's not about plugin but a problem of mmap with your device?


Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 16000
  exact rate   : 16000 (16000/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 64000
  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
Slave: 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         : 16000
  exact rate   : 16000 (16000/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 64000
  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


Takashi

Re: How to enforce 32bit access?

[Joachim Foerster]

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

Re: How to enforce 32bit access?

[Trent Piepho]

On Thu, 11 Oct 2007, Joachim Foerster wrote:
> On Thu, 2007-10-11 at 10:50 +0200, Takashi Iwai wrote:
> > 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)
[...]
> 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?

Joachim, it sounds like your alsa driver memory maps your device's memory
buffer?  And since this buffer is not normal system memory, it cannot be
necessarily be accessed the same way.  In this case, it only supports 32-bit
accesses.

ALSA doesn't put any requirements on a mmaped sound buffer.  I think most
hardware has the buffer in system memory and uses DMA, so there aren't any
requirements about how to access it.

Even if alsa-lib only did 32-bit accesses, any random userspace program using
mmap mode might do 16 or 8 or un-aligned or whatever.

One could add a flag to ALSA for this, SNDRV_PCM_INFO_MMAP_32BIT, that means
the mmap area must be accessed with aligned 32-bit (or more?) operations.  But
no software knows about this (yet), and it sounds like you've got the only
hardware that needs it.

You could modify your driver so that it no longer supports mmap.  You would
need to create a bounce buffer in system memory (ALSA has code for this) and
then your driver will copy from the bounce buffer into your device memory.  Of
course, this is less efficient and will have more latency.

It sounds like when alsa-lib does mono to stereo conversion, it does two 16
bit writes instead of one 32 bit.  Duplicating the 16-bit data in a register
and doing one 32 bit write should be faster.  Regardless of your deivce, this
seems like a good optimization to make.  I know modern x86 processors don't
like combining 16 and 32 bit access to the same memory; it causes partial
memory stalls.

Maybe you could make this optimization to alsa-lib, and then your device would
work well enough for your needs?