2014-09-24, 16:31
Yes, only one channel of real data (it's a mono mic), other channel all zeros.
That is an interesting result. In a post in RaspberryPi forum, I noted that the i2s hardware was capable of doing sign extension for non-16/32 bit capture, and was a trivial change. (Edit one line in i2s driver - nobody commented) But since (by definition, as I understand it) the contents of the high byte should be immaterial I didn't pursue it.
Where do you want to go from here? My interest was in establishing whether there was a bug in the driver(s) and/or hardware, which I'd say the aplay test answered (no), and whether an alsa config file might offer an alternative to killing support in the drivers for problematic software (awaiting boberze). You are obviously more knowledgeable about the higher level audio paths. Is there anything else I can contribute to the problem analysis at this point?
That is an interesting result. In a post in RaspberryPi forum, I noted that the i2s hardware was capable of doing sign extension for non-16/32 bit capture, and was a trivial change. (Edit one line in i2s driver - nobody commented) But since (by definition, as I understand it) the contents of the high byte should be immaterial I didn't pursue it.
Where do you want to go from here? My interest was in establishing whether there was a bug in the driver(s) and/or hardware, which I'd say the aplay test answered (no), and whether an alsa config file might offer an alternative to killing support in the drivers for problematic software (awaiting boberze). You are obviously more knowledgeable about the higher level audio paths. Is there anything else I can contribute to the problem analysis at this point?
