[alsa-devel] [PATCH 1/4] ASoC: pxa-ssp: enhance I2S and add Left_J support
philipp.zabel at gmail.com
Mon Jun 8 17:58:54 CEST 2009
On Mon, Jun 8, 2009 at 2:40 PM, Mark
Brown<broonie at opensource.wolfsonmicro.com> wrote:
> On Mon, Jun 08, 2009 at 02:12:03PM +0200, pHilipp Zabel wrote:
>> On Sat, Jun 6, 2009 at 10:12 PM, Mark
>> Brown<broonie at opensource.wolfsonmicro.com> wrote:
> OOI which MUA are you using? I've noticed several people with this very
> odd word wrapping the past day.
This mail was sent with the Google Mail web interface.
>> > of in tree users it'd cause little disruption. ?A set_sample_width()
>> > operation could also be added.
>> set_sample_width or set_frame_width?
> I'm inclined to go with sample here since it seems harder for the
> machine drivers to get wrong but I've not really thought it through yet?
I thought sample width is determined by the snd_pcm_hw_params. But
maybe I'm mixing up alsa sample width vs sample width on the wire?
I'm leaning towards set_frame_width because that's directly what I
want to do: override pxa_ssp_hw_params' standard decision to use
32-bit frames for S16_LE stereo and set 16-bit frames instead.
>> I'd prefer a separate operation over a parameter to set_tdm_slot because
>> in my setup I just need to force the (SSP) frame width to 16 bits.
>> Enabling network mode and calling set_tdm_slot(..,1,1) wouldn't be
>> necessary at all, then.
> OTOH I don't really see much difference between the two cases - it's
> just an extra couple of parameters on the end of the call.
Technically there isn't. It just seems much more obvious to me to
write something like:
/* nonstandard: 16-bit frames, even for 2x 16-bit stereo */
if (params_format(params) == ..._S16_LE)
in the machine driver instead of:
/* nonstandard: 16-bit frames, even for 2x 16-bit stereo
* pxa_ssp_hw_params will check for TTSA==1
* and then set the frame size accordingly
especially as I don't really need network mode at all.
> That said,
> it'd be much nicer if the driver were able to just do the right thing
> for DSP mode unless explicitly configured, there's not the issue you
> have with I2S where extra clocks would change the offset of the second
> channel within a stereo frame so it's much easier.
Yes. Only for strange nonstandard setups like a flip-flop in the LRCLK
line even DSP mode has to be told that we need two frame clock pulses
per stereo sample.
More information about the Alsa-devel