OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

[Steve Strobel]

I am developing an ALSA driver for the AD1938 codec on uClinux for 
Blackfin (I don't believe my problem is specific to that 
platform).  When I set up the snd_pcm_hardware_t structure with

   .formats =          SNDRV_PCM_FMTBIT_S32_LE,

I can run both "aplay < /dev/urandom" and an OSS test application 
("tone") that sends a sine wave, but the sine wave is "inside out" 
(see <http://www.link-comm.com/temp/inside_out.gif> for a screen 
shot) because the codec needs unsigned data.

If I set up the snd_pcm_hardware_t structure with

   .formats =          SNDRV_PCM_FMTBIT_U32_LE,

the OSS test application sends a nice sine wave, but aplay fails with 
the following messages:

root:~> aplay < /dev/urandom
ALSA sound/blackfin/ad1836.c:1050: snd_ad1836_playback_open
Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
snd_pcm_hw_refine()
ACCESS = 00000000ffffffffffffffff -> 0000000000000008
FORMAT = 0000000000000400 -> 0000000000000000
snd_pcm_hw_refine()
ACCESS = 333f8fc000a32c60c0333f8fc -> 333f8fc000a00000008
ALSA lib ALSA sound/blackfin/ad1836.c:1172: snd_ad1836_hw_free
../../../src/pcm/pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave 
PCM not usable
aplay: set_params:882: Broken configuration for this PCM: no 
configurations available

I am working my way through the ALSA source, but I have not yet 
figured out why aplay won't work with the unsigned codec 
configuration.  Any suggestions?

Steve

P.S.  A more complete log of the console output with both settings 
for those commands and most of the info from aadebug can be found at 
the following URLs:
<http://www.link-comm.com/temp/SNDRV_PCM_FMTBIT_S32_LE.txt>
<http://www.link-comm.com/temp/SNDRV_PCM_FMTBIT_U32_LE.txt>

---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com

Re: OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

[Clemens Ladisch]

Steve Strobel wrote:
> If I set up the snd_pcm_hardware_t structure with
> 
>    .formats =          SNDRV_PCM_FMTBIT_U32_LE,
> 
> the OSS test application sends a nice sine wave, but aplay fails with 
> the following messages:
> 
> root:~> aplay < /dev/urandom
> ALSA sound/blackfin/ad1836.c:1050: snd_ad1836_playback_open
> Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
> snd_pcm_hw_refine()
> ACCESS = 00000000ffffffffffffffff -> 0000000000000008
> FORMAT = 0000000000000400 -> 0000000000000000

aplay tries to set S32_LE, but the driver doesn't accept it.

Where does this S32_LE come from?  Did you set up some devices in
~/.asoundrc or /etc/asound.conf, or did you create a card-specific .conf
file for your controller?  (I would guess that the "default" device is
set up to use dmix.)


Regards,
Clemens

Re: OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

[Steve Strobel]

At 12:46 AM 9/19/2007, Clemens Ladisch wrote:
>Steve Strobel wrote:
> > If I set up the snd_pcm_hardware_t structure with
> >
> >    .formats =          SNDRV_PCM_FMTBIT_U32_LE,
> >
> > the OSS test application sends a nice sine wave, but aplay fails with
> > the following messages:
> >
> > root:~> aplay < /dev/urandom
> > ALSA sound/blackfin/ad1836.c:1050: snd_ad1836_playback_open
> > Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
> > snd_pcm_hw_refine()
> > ACCESS = 00000000ffffffffffffffff -> 0000000000000008
> > FORMAT = 0000000000000400 -> 0000000000000000
>
>aplay tries to set S32_LE, but the driver doesn't accept it.
>
>Where does this S32_LE come from?  Did you set up some devices in
>~/.asoundrc or /etc/asound.conf

I don't have either of those files.

>or did you create a card-specific .conf file for your controller?

Not intentionally, but there might be one left over from the AD1836 
driver I started with (I have just been modifying that driver, 
planning to rename it after I get it working).  Where would I look 
for such a file?

The only reference to "alsa" in my /etc directory is in modprobe.conf:

root:~> cat 
/etc/modprobe.conf
# ALSA native device 
support
alias char-major-116 
snd
options snd major=116 
cards_limit=1
alias snd-card-0 
snd-ad1836

#OSS/Free 
setup
alias char-major-14 
soundcore
alias sound-slot-0 
snd-ad1836
alias sound-service-0-0 
snd-mixer-oss
alias sound-service-0-3 
snd-pcm-oss

>(I would guess that the "default" device is set up to use dmix.)

How would I determine that?  Sorry for the elementary questions;  I 
am new to ALSA.  I don't know if this answers the question, but 
"aplay -L" includes the following line:  "default 'cards.pcm.default' 
".  Complete output shown below.

>Regards,
>Clemens

Thanks for your help,

Steve


root:/mnt/Blackfin/Sound Files> aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ad1836 [ADI ad1836], device 0: AD1836_PCM [AD1836_PCM]
   Subdevices: 1/1
   Subdevice #0: subdevice #0



root:/mnt/Blackfin/Sound Files> aplay -L
PCM list:
hw {
         @args.0 CARD
         @args.1 DEV
         @args.2 SUBDEV
         @args.CARD {
                 type string
                 default {
                         @func getenv
                         vars {
                                 0 ALSA_PCM_CARD
                                 1 ALSA_CARD
                         }
                         default {
                                 @func refer
                                 name 'defaults.pcm.card'
                         }
                 }
         }
         @args.DEV {
                 type integer
                 default {
                         @func igetenv
                         vars {
                                 0 ALSA_PCM_DEVICE
                         }
                         default {
                                 @func refer
                                 name 'defaults.pcm.device'
                         }
                 }
         }
         @args.SUBDEV {
                 type integer
                 default {
                         @func refer
                         name 'defaults.pcm.subdevice'
                 }
         }
         type hw
         card $CARD
         device $DEV
         subdevice $SUBDEV
}
plughw {
         @args.0 CARD
         @args.1 DEV
         @args.2 SUBDEV
         @args.CARD {
                 type string
                 default {
                         @func getenv
                         vars {
                                 0 ALSA_PCM_CARD
                                 1 ALSA_CARD
                         }
                         default {
                                 @func refer
                                 name 'defaults.pcm.card'
                         }
                 }
         }
         @args.DEV {
                 type integer
                 default {
                         @func igetenv
                         vars {
                                 0 ALSA_PCM_DEVICE
                         }
                         default {
                                 @func refer
                                 name 'defaults.pcm.device'
                         }
                 }
         }
         @args.SUBDEV {
                 type integer
                 default {
                         @func refer
                         name 'defaults.pcm.subdevice'
                 }
         }
         type plug
         slave.pcm {
                 type hw
                 card $CARD
                 device $DEV
                 subdevice $SUBDEV
         }
}
plug {
         @args.0 SLAVE
         @args.SLAVE {
                 type string
         }
         type plug
         slave.pcm $SLAVE
}
shm {
         @args.0 SOCKET
         @args.1 PCM
         @args.SOCKET {
                 type string
         }
         @args.PCM {
                 type string
         }
         type shm
         server $SOCKET
         pcm $PCM
}
tee {
         @args.0 SLAVE
         @args.1 FILE
         @args.2 FORMAT
         @args.SLAVE {
                 type string
         }
         @args.FILE {
                 type string
         }
         @args.FORMAT {
                 type string
                 default raw
         }
         type file
         slave.pcm $SLAVE
         file $FILE
         format $FORMAT
}
file {
         @args.0 FILE
         @args.1 FORMAT
         @args.FILE {
                 type string
         }
         @args.FORMAT {
                 type string
                 default raw
         }
         type file
         slave.pcm null
         file $FILE
         format $FORMAT
}
null {
         type null
}
cards 'cards.pcm'
front 'cards.pcm.front'
rear 'cards.pcm.rear'
center_lfe 'cards.pcm.center_lfe'
side 'cards.pcm.side'
surround40 'cards.pcm.surround40'
surround41 'cards.pcm.surround41'
surround50 'cards.pcm.surround50'
surround51 'cards.pcm.surround51'
surround71 'cards.pcm.surround71'
iec958 'cards.pcm.iec958'
spdif 'cards.pcm.iec958'
modem 'cards.pcm.modem'
phoneline 'cards.pcm.phoneline'
default 'cards.pcm.default'
dmix 'cards.pcm.dmix'
dsnoop 'cards.pcm.dsnoop'
root:/mnt/Blackfin/Sound Files>


---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com

Re: OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

[Clemens Ladisch]

Steve Strobel wrote:
> At 12:46 AM 9/19/2007, Clemens Ladisch wrote:
> > or did you create a card-specific .conf file for your controller?
> 
> Not intentionally, but there might be one left over from the AD1836 
> driver I started with (I have just been modifying that driver, 
> planning to rename it after I get it working).  Where would I look 
> for such a file?

In /usr/share/alsa/cards/, with the driver name.


Does it work when running aplay with the parameter "-D plughw"?


Regards,
Clemens

Re: OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

[Steve Strobel]

At 10:03 AM 9/19/2007, Clemens Ladisch wrote:
>Steve Strobel wrote:
> > At 12:46 AM 9/19/2007, Clemens Ladisch wrote:
> > > or did you create a card-specific .conf file for your controller?
> >
> > Not intentionally, but there might be one left over from the AD1836
> > driver I started with (I have just been modifying that driver,
> > planning to rename it after I get it working).  Where would I look
> > for such a file?
>
>In /usr/share/alsa/cards/, with the driver name.

I don't have a file there;  that directory doesn't even exist:

     root:/mnt/Blackfin/Sound Files> ls 
/usr/share
     sounds    terminfo

Should I have a configuration file in one of those places?  If I 
don't, where do the default values come from?  My version of ALSA:

     root:/mnt/Blackfin/Sound Files> cat /proc/asound/version
     Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu 
Jun 22 13:55:50 2006 UTC).

>Does it work when running aplay with the parameter "-D plughw"?

No.  It searches through more rules, but still says, "Sample format 
non available".  I put a log of the console output with and without 
"-D plughw" at <http://link-comm.com/temp/aplay-log.txt> to save bandwidth.

One thing I hadn't noticed before is the message:

     ALSA lib 
../../../src/pcm/pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave 
PCM not usable
   refine done - result = -22

Does a result code of -22 mean anything significant?

You wrote in an earlier message:> > snd_pcm_hw_refine()
 > > ACCESS = 00000000ffffffffffffffff -> 0000000000000008
 > > FORMAT = 0000000000000400 -> 0000000000000000
 >
 > aplay tries to set S32_LE, but the driver doesn't accept it.

I think I understand how the driver uses the snd_pcm_hardware_t 
structure to tell ALSA what it supports, but I don't understand how 
ALSA tries to set things in return.  I am surprised that it would try 
to set it to a data type that the driver never said it could 
support.  I suppose I could make the driver accept either S32 or U32, 
detect which mode ALSA is trying to use, and do the conversion in the 
driver, but I though that was what plughw was supposed to do.

>Regards,
>Clemens

Thanks,
Steve


---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com

Re: OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

[Timur Tabi]

Steve Strobel wrote:

> Does a result code of -22 mean anything significant?

-22 is EINVAL, which usually means an invalid parameter.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: OSS app works but aplay does not with SNDRV_PCM_FMTBIT_U32_LE

[Clemens Ladisch]

Steve Strobel wrote:
> At 10:03 AM 9/19/2007, Clemens Ladisch wrote:
> >Steve Strobel wrote:
> > > At 12:46 AM 9/19/2007, Clemens Ladisch wrote:
> > > > or did you create a card-specific .conf file for your controller?
> > >
> > > Not intentionally, but there might be one left over from the AD1836
> > > driver I started with (I have just been modifying that driver,
> > > planning to rename it after I get it working).  Where would I look
> > > for such a file?
> >
> >In /usr/share/alsa/cards/, with the driver name.
> 
> I don't have a file there;  that directory doesn't even exist:
> Should I have a configuration file in one of those places?  If I 
> don't, where do the default values come from?

Well, there is an alsa.conf somewhere, otherwise the utils wouldn't run.

> >Does it work when running aplay with the parameter "-D plughw"?
> 
> No.  It searches through more rules, but still says, "Sample format 
> non available".  I put a log of the console output with and without 
> "-D plughw" at <http://link-comm.com/temp/aplay-log.txt> to save
> bandwidth.

Now it says that access RW_INTERLEAVED doesn't work.
I'd really like to see the source code of the driver, especially the
snd_pcm_hardware structure.

> One thing I hadn't noticed before is the message:
> 
> ALSA lib ../../../src/pcm/pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not usable
> refine done - result = -22
> 
> Does a result code of -22 mean anything significant?

Nothing that hasn't been already been told in the error message.
-EINVAL is expected in this case.

> You wrote in an earlier message:> > snd_pcm_hw_refine()
>  > > ACCESS = 00000000ffffffffffffffff -> 0000000000000008
>  > > FORMAT = 0000000000000400 -> 0000000000000000
>  >
>  > aplay tries to set S32_LE, but the driver doesn't accept it.
> 
> I think I understand how the driver uses the snd_pcm_hardware_t 
> structure to tell ALSA what it supports, but I don't understand how 
> ALSA tries to set things in return.  I am surprised that it would try 
> to set it to a data type that the driver never said it could 
> support.

A configuration file can force a specific sample format.  Usually, only
dmix does that.


Regards,
Clemens