Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Liam Girdwood <liam.r.girdwood@linux.intel.com>]

On Mon, 2015-10-19 at 14:46 -0600, Shuah Khan wrote:
> On Mon, Oct 19, 2015 at 1:34 PM, Mauro Carvalho Chehab
> <mchehab@osg.samsung.com> wrote:
> > Hi Mark/Liam,
> >
> > Em Mon, 19 Oct 2015 17:27:56 +0100
> > Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:
> >
> >> On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
> >> > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
> >> >
> >> > > We did a Media Controller Summit in July. During the summit, it was
> >> > > pointed that other subsystems like IIO (Linux Industrial I/O) have
> >> > > similar needs and also need to track complex pipelines.
> >> >
> >> > > The goal of this tech topic is to present the MC next generation
> >> > > concepts and how the patches to support MC was written, showing some
> >> > > pipeline examples.
> >> >
> >> > > The next gen support patches were written in August, with some
> >> > > additional patches written after that, and it has support for DVB
> >> > > and for one ALSA driver (snd-usb-audio).
> >> >
> >> > > The patches are not merged yet at the media development tree and
> >> > > at -next, as one of the core developers of the media controller
> >> > > is missing time to review patches. So, while it was originally
> >> > > targeted to be merged on Kernel 4.4, it is likely that this will be
> >> > > merged only for Kernel 4.5, in order to give him more time to
> >> > > review the patchset.
> >> >
> >> > One fun thing on this that came up at the audio meeting we had in Dublin
> >> > after ELC-E is that there is some desire to export the internal topology
> >> > of audio devices to userspace using the same format that we're using to
> >> > load topology information for DSP firmwares (see include/sound/soc-topoloy.h).
> >> > If we go ahead with that it'd create an alternative topology ABI, it
> >> > seems like we should at least consider if it's worth trying to share
> >> > things here.
> >
> > Thanks for the feedback. I was wanting to go to ELC-E this year due to
> > ALSA summit, but, unfortunately, I had 3 other trips happening on a one
> > month interval (two of them are 28+28 hours of trip). So, I had to give
> > up going to ELC-E.
> >
> >> >
> >> > I've not had a chance to look at the new media controller work yet, I've
> >> > CCed Lars and Liam who have more knowledge in this area.  Unfortunately
> >> > I don't think any of the people working directly on this will be at KS
> >> > this year.
> >>
> >> Just to give a little more background (for any non audio folks), there
> >> are many audio DSPs today that can load their topology and other
> >> capabilities at runtime depending on the target device (phone, laptop,
> >> PC, etc) and the audio use cases.
> >>
> >> Our intention is to also have a single audio driver per DSP family (i.e.
> >> single skylake audio DSP driver to cover all skylake based devices). The
> >> DSP driver would load it's topology data alongside the DSP firmware so
> >> that the driver topology (i.e. graph, controls, capabilities) would be
> >> aligned with the DSP firmware topology.
> >>
> >> The process for creating the topology data involves either compiling a
> >> text topology file to the binary topology file (used by the kernel) or
> >> using a new ALSA C API to generate the binary topology file (as part of
> >> a firmware toolchain). The topology text compiler and C API are both
> >> upstream.
> >>
> >> We are currently implementing de-compiler support to the userspace
> >> compiler in order to convert the binary topology files into text files
> >> for debug and development purposes.
> >>
> >> Ideally I'd like to be able to dump the topology data using the same
> >> format that it used for topology loading. That way we could easily feed
> >> them into the de-compiler for development/debug.
> >>
> >> Having a simple mechanism for dumping topology data is important as we
> >> will need to be able to easily dump this data on Android and Chrome
> >> alongside regular Linux for development and debug purposes. i.e.
> >> cat /sys/some/dump/file > audio_topology
> >
> > Well, it is not hard to get the topology using the media controller.
> > I wrote a testing program using it at:
> >         http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c
> >
> 
> Adding to what Mauro said, I have a patch series out that updates
> ASLA and AU0828 drivers (Hauppauge Win TV HVR 950Q Hybrid
> USB TV Stick) to share tuner. I am speaking about this work at the
> KLF on Oct 26th.
> 
> http://korealinuxforum2015.sched.org/event/f59175cc49f866dbc9bebc36f86fe663#.ViVWjGwVhBd
> 
> You can find the media graph that includes ALSA Mixer Function and
> Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
> Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
> at:
> 
> https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0

Looks nice. Fwiw, the graph will probably get a lot bigger when we show
the audio DSP and codec paths (as DSPs and codecs have multiple muxes
and mixers). It may be good to have a cmd line option to stop at certain
nodes on the graph to avoid over populated/complex graphs ?

Liam

> 
> thanks,
> -- Shuah