On Sun, Aug 9, 2009 at 10:37 AM, Mark Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Aug 09, 2009 at 09:32:22AM -0400, Jon Smirl wrote: > >> I agree with you, but I think the second form better indicates the >> wildcard than the first form. It makes it look like endianess is not a >> factor. > > You need to specify both - the controller may be able to handle data in > either endianness, not just the native format. I thought endianess was fixed in the wire protocol standard. It's the host AC97 controller that is converting the endianess. I struggled with this when first writing the host driver for my BE powerpc chip. I kept trying to encode the AC97 wire protocol definition into the AC97 codec. The trick is that you don't want to encode it since it is fixed by the standard. If we declared the AC97 codecs like this, which they really are: .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE, Then I would need a way to say my powerpc host AC97 controller needs BE on the input and that it converts it to LE on the output. ALSA doesn't have a way to say that. Leaving the endianess off from the AC97 codec definition makes it implicit. .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16 | SNDRV_PCM_FMTBIT_S24 | SNDRV_PCM_FMTBIT_S32, We don't need to declare an endianess because it is fixed in the standard. Now the ifdefs in the h file make this work for both BE and LE. This also hides another implicit conversion. The AC97 codecs only take 24b. Again it is the host controller that is converting 8/16/32 to 24b. -- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
