On 02/05/16 08:13, Rick Mann wrote:
I agree. I've been trying to get a simple audio codec to work for over a year.
It worked in 3.1.x, but now in 4.4.x it's marginal, at best (one channel works,
not the other). I've been a bit lazy to see what the working 3.1.x version had
different.
But, it's really complicated, very poorly documented, and the people would be
able to clear it up either aren't on the lists (beaglebone and alsa), or don't
care to answer.
On May 2, 2016, at 00:05 , J dog <[email protected]> wrote:
Many including myself don't understand all the complexity's of the way the
alsa-soc is developed. And only a few engineers really have the grasp of it.
Its so complex that T.I. themselves said mixing I2C and I2S into the same code
bundle makes it unnecessarily hard to develop a routine for each soc board and
each codec. Here I will state some of the things as I understand happen in
alsa-soc.
Alsa states, there should a definition for each platform, a definition for
each codec, and oddly something called the machine which is how they
intercommunicate I believe.
What this means is for each platform, such as A beaglebone black and a
beaglebone xm, the code could be different. On top of that you then have to
have definitions for each codec. So just because you have definitions for a
codec from a codec maker, it doesn't mean your gonna compile that into the
kernel and walla! your platform is now talking to the codec, its just not that
simple. All this was done to combine i2c and i2s specifics for each codec /
platform to work from one package.
But after looking at this and realizing I was on the short end of a long stick
and finding a programmer that could even understand this stuff, It became
evident that I2C was the villain like T.I. said. Looking at the disadvantages
besides the complexity, what happens in this prescribed platform, codec,
machine we find....
I2C being a timed command and response protocol uses wires completely different
than i2s, and even a different clock.
I2S is only audio, it knows nothing but sending and receiving audio packets, it
doesn't care to whom and whatever codec is on the other end and as long as it
works with the same timings should work just fine. What happens if a I2C
command hangs in the middle of the routine to send I2S signals?. audio drops
and possibly worse. A badly coded alsa-soc package can play hell not only on
audio, but may cause kernel dumps and who knows what else.
I2S routines should be free from any hindrance, let the kernel handle this
because its a very timing critical task.
I2C commands though should occur from user space, they aren't so timing
critical and if from user space an i2c send / response sequence hangs, the
kernel / i2s routines probably wont even care.
I2C from user space has the advantage of enhanced command error checking and
being able to be written in many languages that have access to i2c calls, such
as python, c++, nodejs and golang.
In this regard, an i2s driver with configurable parameters could be written for
every soc platform, and only once! And an i2c routine can be universal on all
soc-platforms if the hooks to the actual pins are abstracted. I will be
presenting this thesis to the ALSA consortium at a future date.
Jay Steele
8< snip
I managed to get the simple card working without issue on mainline a few
months ago, the final DTS snippet I came up with was as follows:
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "ClipAise Audio Cape";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Line", "Line In";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+ simple-audio-card,format = "dsp_b";
+ simple-audio-card,bitclock-master = <&sound_master>;
+ simple-audio-card,frame-master = <&sound_master>;
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <&mcasp0>;
+ };
+
+ sound_master: simple-audio-card,codec {
+ sound-dai = <&tlv320aic3106>;
+ system-clock-frequency = <12000000>;
+ };
+ };
Hope it helps with what you're trying to achieve.
Regards,
Jack
-------------------
Jack Mitchell, Embedded Linux Consultant
Tuxable Ltd, www.tuxable.co.uk
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/d78df8ba-5775-c82c-9787-4d0c5633642d%40embed.me.uk.
For more options, visit https://groups.google.com/d/optout.
